Course outline · 0% complete

0/27 lessons0%

Course overview →

URLs, domains, and DNS

lesson 7-3 · ~10 min · 24/27

The address on every request

Every request from lesson 7-1 needs an address saying which server to ask and what to ask it for. That address is the URL, short for uniform resource locator, the text in your browser's address bar. Engineers read URLs constantly, in bug reports, in logs, and in links that mysteriously 404, so knowing the parts pays off immediately.

Take https://hackuniversity.dev/courses:

  • https:// is the scheme, saying which set of communication rules to use. HTTPS is the web's standard, and the S means the traffic is encrypted so others on the network cannot read it
  • hackuniversity.dev is the domain name, saying which server to contact, as a human-readable name
  • /courses is the path, saying which page or resource on that server you want

One catch: the internet's machinery does not deliver to names. Each machine is reached by a numeric IP address, like 76.76.21.21, which are the network's real house numbers.

Names exist because humans are bad at memorizing numbers, so a lookup system called DNS, the domain name system, translates a domain name into its current IP address. Before your browser can send the request, it quietly asks DNS what number hackuniversity.dev is, and then connects to that number.

https://hackuniversity.dev/coursesschemedomain → DNS → IP addresspathone URL: how to talk, whom to ask, what to ask for
A URL in three parts: the scheme picks the rules, the domain (translated by DNS to an IP address) picks the server, the path picks the resource.

Which part of a URL names the page

The path, /dashboard, tells the server which page you want.

The three parts divide the work cleanly. The scheme picks the communication rules, the domain picks which server to contact by way of a DNS lookup for its IP address, and the path names the resource on that server.

The path is also the part that server code branches on, which is exactly what the pretend server compared in lesson 7-2. GET /about and GET /home differ only in their paths.

That division explains a common confusion. Two URLs with the same domain and different paths reach the same machine and get different answers, and two different domains can resolve to the same IP address and still be told apart, because the domain travels with the request as well.

A pretend DNS lookup

Name in, address out, using lesson 4-2's if/else.

domain = input()
if domain == "hackuniversity.dev":
    print("76.76.21.21")
else:
    print("unknown domain")

Input

hackuniversity.dev

Output

76.76.21.21

Any other domain fails the comparison and prints unknown domain, which is this miniature's version of a lookup failure.

Real DNS is a worldwide distributed lookup service rather than one if statement, but the job is identical: a name goes in and an IP address comes out. The scale is what differs, since no single computer could hold a branch for every domain on the internet.

The system that translates names to addresses

It is DNS, the domain name system.

It is a global lookup service. Give it a domain name and it returns the IP address currently assigned to that server, and it runs quietly before nearly every request your browser sends.

The word "currently" is carrying weight there. A site can move to a new machine with a new IP address and keep the same domain name, and every link to it keeps working because the lookup happens fresh rather than being baked into the link.

When DNS breaks, the internet appears down even though the servers are fine. That is a classic outage shape, and it is why an engineer investigating "the site is unreachable" checks name resolution before assuming the server has crashed.