DNS: Turning Names into Addresses

Every machine on the internet is found by a number called an IP address, for example 203.0.113.7. It is like the address of a building: precise, but hopeless to remember. Nobody types a string of digits to visit a website; they type a name like scaledojo.dev. Something has to turn that name into the number before a single request can be sent, and that something is the Domain Name System, or DNS. It runs before everything else in this course: before the connection, before the encryption, before the request itself.

Imagine you need the phone number of a company, and all you know is its name. You ask the shopkeeper on your street. He does not know it, but he knows how to find out. He phones the national directory, which does not hold company numbers either, but tells him: for anything ending in .com, call the .com directory. The .com directory tells him: for this particular company, call its own switchboard. The switchboard gives him the number. He tells you, and he writes it on a note by his till, so the next customer who asks gets the answer instantly.

• -You are the browser. The shopkeeper is the recursive resolver: a server run by your internet provider, or by a public service such as 1.1.1.1 or 8.8.8.8, whose whole job is to chase answers on your behalf.
• -The national directory is a root server. It does not know the answer, only who to ask next. There are 13 named groups of root servers, spread across hundreds of machines worldwide.
• -The .com directory is a TLD server (top-level domain). It knows which name servers are responsible for each domain that ends in .com.
• -The company's own switchboard is the authoritative name server: the one place that holds the real record for that domain, and the only one whose answer is final.
• -The note by the till is the cache. Each answer carries a time limit, called its TTL, after which the note is thrown away and the question is asked again.

Here is what happens the first time someone looks up shop.example.com (a made-up name, with an address from a range reserved for documentation):

• -The browser checks its own cache, then the operating system's cache. If either has a fresh answer, the lookup ends here, in well under a millisecond.
• -Otherwise it asks the recursive resolver. If the resolver has the answer cached from an earlier customer, it replies at once. This is by far the most common case.
• -If not, the resolver asks a root server, which replies: ask the .com servers.
• -The resolver asks a .com server, which replies: ask the name server that owns example.com.
• -The resolver asks that authoritative name server, which replies with the record: shop.example.com is at 203.0.113.7.
• -The resolver stores the answer for its TTL and passes it back. The browser connects to 203.0.113.7.

That sounds like a lot of conversations, but caching makes it cheap. Popular names are almost always sitting in a cache close to you, so the full six-step journey is the exception rather than the rule. The numbers below show how small the typical cost is.

Every DNS answer comes with a TTL, short for time to live: the number of seconds anyone is allowed to cache it. It is a dial with a real trade-off. A long TTL (say a day) means most lookups are answered from a nearby cache, which is fast and puts little load on your name servers. A short TTL (say 60 seconds) means changes spread quickly, at the cost of more lookups reaching your name servers.

A worked example shows why teams care. Suppose your site's address has a TTL of 24 hours, and at 2pm you move the site to a new server with a new address. A resolver that cached the old address at 1:59pm will keep handing it out until 1:59pm tomorrow. For almost a day, some users go to the old server and some to the new one, and there is nothing you can do to recall the notes already written. Now suppose that a week earlier you had lowered the TTL to 60 seconds. By about 2:01pm every cache has expired and everyone reaches the new server. That is why careful teams lower the TTL before a risky migration or a big launch, and raise it again afterwards.

Because every user's first step goes through DNS, it is also a steering wheel for traffic:

• -Failover: if a server dies, change the record (or let a health check change it) so the name points at a healthy one. A short TTL decides how quickly users follow.
• -Geo-routing: the same name can return different addresses depending on where the question comes from, so users in Tokyo reach a Tokyo server and users in London reach a London one.
• -Filtering: providers such as Cloudflare sit in front of your name and can drop malicious traffic before it ever reaches your servers.
• -A limit to remember: DNS only answers where this name is. It does not know whether the server at that address is overloaded, which is the load balancer's job in the next module.

In the lab's component palette, DNS appears as a single box on the canvas. The card below is the reference for what that box stands for: