DNS resolution

A ski resort sells lift tickets at tickets.snowpeak.example. When a skier's phone opens the site, it needs the server's IP address, and it asks in layers, stopping at the first one that knows:

• The browser and the operating system keep recent answers. The part of the operating system that asks is the stub resolver: it doesn't search, it only forwards the question.
• A recursive resolver, run by the internet provider or a public service such as 1.1.1.1 or 8.8.8.8, does the searching. It is shared by thousands or millions of users, so it has usually seen the name already.
• Authoritative servers hold the real records. Only they can answer without asking anyone else.

When the resolver has nothing cached, it walks down the name from the right:

The root is not one machine. There are 13 named root server identities, run by 12 independent organizations, and over 2,000 copies of them around the world. All that caching is why a lookup usually costs one short round trip to the resolver, or nothing at all when the device already has the answer, and why the cold walk above is rare.

Snowpeak's authoritative servers hold a zone: the records for snowpeak.example and every name under it. Each record has a name, a type, a value and a TTL:

One rule trips up nearly everyone. A name that has a CNAME may have no other records. The bare domain, snowpeak.example, is the top of the zone, called the zone apex, and it must carry NS records (and the zone's start-of-authority record). So the apex can't be a CNAME, and you can't point snowpeak.example at a hosting provider's name that way. DNS providers work around it with alias or flattening records: the provider looks up the target itself and answers with plain addresses.

Two weeks before opening day, Snowpeak moves the ticket site to a new hosting provider. The A record has a TTL of one day, so a resolver that fetched it this morning will keep handing out the old address until tomorrow morning, whatever the authoritative servers now say. Change the record at 9:00, and this is the share of busy resolvers still sending skiers to the old server:

The trap is to lower the TTL at the same moment as the change. Resolvers already hold the old record with the old one-day TTL, and they won't ask again until it runs out. The order that works:

Missing names are cached too. If someone looks up lifts.snowpeak.example before it exists, the "no such name" answer is cached for a time set in the zone's start-of-authority record; one to three hours is the recommended range. Create the name a minute later, and those users keep seeing "not found" until that runs out. This is negative caching: create names before anyone, including your own tests, asks for them.

Because the authoritative server chooses each answer, it can answer differently for different askers. Managed DNS services offer several policies:

The limits come from DNS's own design:

• Caching slows every change. Failover takes the health checks' detection time plus up to one TTL, and longer for clients that hold answers.
• The server sees the resolver, not the user. A skier in Austria using a resolver in another country may get that country's region. An extension called EDNS Client Subnet lets resolvers pass along part of the user's address (the first 24 bits of an IPv4 one) to fix this.
• DNS knows nothing about load. It can't tell that the server it named is overloaded.

So DNS chooses the region or the load balancer, and a load balancer chooses the server (Load balancing).

A different trick avoids the caching problem altogether. With anycast, the same IP address is announced from many locations, and internet routing delivers each packet to the nearest one in network terms. The address never changes, so nothing needs to expire. The root servers, large public resolvers and CDNs all use it (Content delivery networks (CDNs)).

If a name can't be resolved, it doesn't matter how healthy the servers behind it are: no one can find them. Two well-known outages:

In the first case the sites' own servers were fine; they shared a single DNS provider. In the second, a safety mechanism meant to take one unhealthy DNS location out of service took all of them out at once.

Ways to make DNS less of a single point of failure:

Classic DNS sends small, unencrypted messages over UDP on port 53. An answer too large for one UDP message comes back marked as cut short, and the asker retries over TCP; every DNS implementation must support both. Two weaknesses follow from the plain format:

A forged answer needs the attacker's reply to match the question, come from the right server's address, and carry the right query ID and port. With a 16-bit ID alone, about 32,768 guesses succeed on average; randomizing the port as well multiplies the work by up to tens of thousands. DNSSEC removes the guessing game entirely for signed zones, because a forged record has no valid signature.

What to remember when DNS is part of your design:

A checklist:

• Know your TTLs, and lower them a full TTL before any planned change.
• Use DNS for coarse steering, between regions and load balancers, and load balancers for servers.
• Treat DNS as part of your availability: two providers, sensible TTLs, monitoring from outside.
• Sign your zone with DNSSEC if your provider supports it, and protect the account that controls your domain: whoever can change your records can redirect all of your traffic.