Design a caching DNS resolver

All the work happens in our recursive resolver. A recursive resolver starts from a built-in list of root server addresses and follows referrals.

• The root servers do not know example.com, but they know who runs .com. The reply carries NS records, which name the .com servers, and glue records, which give those servers' addresses.
• A .com server does the same one level down, and names the servers for example.com.
• A zone server finally answers with the record itself, and the TTL the owner chose.

Glue exists to break a loop. If the servers for example.com are called ns1.example.com, nobody could find their address without already knowing the address of example.com. So the parent zone hands out the address along with the referral.

Every reply is cached under its own TTL. The NS records for .com are usually cached for a day or two, so after the first lookup the root is skipped for every .com name. The NS records for a busy zone are cached too, so a miss on a popular site is often a single query to its own server. That is why we assumed 1.5 upstream queries per miss and not 3.

Aliases. A CNAME says that one name is another name. The resolver caches the alias and then resolves the target. Cap the chain at about 8 steps, and the whole query at about 20 upstream queries, so that a loop or a hostile chain of delegations cannot make one question cost a thousand.

Transport. Queries use UDP, with a few tries on different servers, preferring the one with the lowest measured round trip. When an answer is too large, the server sets a truncated flag, and the resolver repeats the question over TCP. Advertising a modest buffer size, around 1,232 bytes, avoids fragmented packets. Query minimisation helps privacy: ask the root only for the top-level label (com), not the whole name, since it only needs to refer us.

Store an absolute expiry time, and when answering return the remaining TTL, not the original. A record that has 240 seconds left should be passed on with 240. Otherwise each layer would restart the clock, and a 300 second record could live far longer than its owner intended. Clamp extremes: raise very low TTLs to about 30 seconds, so a zone cannot force a lookup for every query, and cut very high ones to a day, so a mistake cannot be stuck in our cache for a month.

Negative caching. A name that does not exist (NXDOMAIN) or a type that has no data is an answer too. Cache it, for the lower of the TTL on the zone's SOA record and the SOA's minimum field. Without this, a mistyped name or a dead tracking domain is looked up again on every request. The cost is that a name just created stays missing until the negative entry expires, which is why owners add records before they announce them.

Prefetch. A popular name's entry expires every few minutes, and the next user to ask pays a full lookup. Instead, when a name has been hit several times and has under 10% of its life left, refresh it in the background. Do it only for names that have earned it, or you will refresh thousands of names nobody wants. This trades some extra upstream traffic for steady latency on the names that matter most.

Serve-stale. When every attempt to reach a zone's servers fails, an expired answer is usually still correct. Keep expired records for up to a day, and return one with a short TTL of about 30 seconds while retrying in the background. An outage at one site's DNS provider then breaks far fewer pages. The cost is that a record changed during the outage may be wrong for a while.

Changing a record safely. Owners who plan a move lower the TTL a day ahead, since resolvers only see the new TTL when the old entry expires. They change the record, wait, and raise the TTL again.

An attacker who does not control the path can race: send many forged replies while the real one is on its way. A false address that lands in the cache is served to every subscriber until it expires. That is cache poisoning.

The forger must guess what the resolver is waiting for. So make it hard to guess:

• A random 16-bit query ID. A guess has a chance of 1 in 65,536.
• A random source port for each query, from about 60,000 ports. Together with the ID that is about 4 billion combinations, not 65,000.
• Random letter case in the question (such as wWw.ExAmPlE.com). A real server copies the case back, and a forger must guess it too.
• Match everything. The reply must come from the server we asked, to the right port, with the same question section. Ignore unsolicited replies.
• Accept only data the server may speak for. A server for example.com may not tell us about the address of another domain. Discard those extra records.

DNSSEC adds proof, not just luck. Zone owners sign their records, and each parent zone vouches for its child's key, forming a chain up to the root key we already hold. The resolver checks the signatures and rejects a failure with a server error, never an unsigned guess. It is optional because it costs extra queries and CPU, and a zone with a broken signature becomes unreachable for validating resolvers. Turn it on, monitor the failure rate, and have a way to relax it for a single broken zone.

Reflection and amplification. A UDP source address can be forged. If we answer anyone, an attacker can send a 60 byte question with a victim's address and make us send a 3,000 byte answer there, 50 times larger. So answer only our own ranges, rate limit each client and each destination, and cap the size of responses to unverified sources. A response rate limit that slows identical answers to one address is the standard guard.

Keep the cache small enough to fill from memory, cap entries per name, and limit work per client, so that one subscriber who asks for a million random names cannot push out everyone's useful records.