DNS resolution simulator

Pick a device, type a name or press one under Try, and press Look up. The diagram shows every message for that lookup: grey arrows are questions, blue arrows are replies. The numbered list explains each one, and the tables on the right show what the resolver and each device now have cached and how many seconds each entry has left. Time only moves when you press one of the Let time pass buttons.

Some things to try:

• Look up www.example.com from the laptop. The resolver starts with nothing but the root server's address, so it asks the root, the .com server and ns1 in turn. Look it up again: the laptop answers from its own cache with no messages at all.
• Switch to the phone and look up the same name. The phone's cache is empty, but the resolver's is not, so one round trip is enough. Then let 10 minutes pass and look at the TTLs: the phone is told 600 seconds less than the laptop was.
• Look up mail.example.com. The resolver already knows the servers for example.com, so it goes straight to ns1.
• Look up api.example.com. It is an alias (CNAME) for api.example.net, in another top-level domain, so the resolver has to go back to the root for net.
• Reset, then look up www.example.net first. The net servers say example.net is served by ns1.example.com, but cannot give its address, so the resolver has to find that address before it can continue.
• Press Take ns1 down, flush the resolver and look up www.example.com. The resolver waits for a timeout, then asks ns2.
• Take ns2 down as well, flush the resolver and look the name up twice. The first lookup ends in SERVFAIL after two timeouts; the second gets SERVFAIL at once, because the resolver has cached the failure. Let 10 seconds pass and try again to see the cache time double.
• Look up www.example.com, press Change www.example.com's address, and look it up again from both devices. Both keep getting the old address until their cached copies expire.

DNS resolution is the process of finding the records for a name, most often its IP address, in the Domain Name System. The data is spread across many servers, each responsible for one part of the namespace (a zone), so a lookup may involve several servers.

Two kinds of resolver take part. The stub resolver is the small client in the operating system that applications call. It does not search for answers itself: it sends each question, with the "recursion desired" flag set, to a recursive resolver, usually run by the network operator or a public service such as 1.1.1.1 or 8.8.8.8. The recursive resolver does the searching. It asks authoritative servers, each of which answers only for its own zones, and caches what it learns so that most later questions need few or no further queries.

The step-by-step walk through a single lookup, with the record types and message format, is in How DNS works. This page concentrates on what the recursive resolver does and why its cache matters.

RFC 1034 describes the resolver's job as a loop. For a question about a name and type:

1. Check the cache. If the answer is there and its TTL has not run out, return it. If the cache holds a CNAME for the name, follow it and repeat with the target. If the cache holds a negative answer, return that.
2. Find the best servers to ask. Look for the longest suffix of the name for which the cache holds NS records: for www.example.com, first example.com, then com, then the root. The root servers are always known, from the root hints file the resolver is configured with.
3. Send the question to one of those servers, choosing one whose address is known and which has answered quickly before.
4. Act on the reply. An answer is cached and returned. A referral to a zone closer to the name is cached, and the loop continues at step 3 with the new servers. A CNAME is cached and the loop starts again with the target name. NXDOMAIN or an empty answer is cached as a negative answer and returned. No reply means trying another server for the same zone.

The simulator follows this loop. Step 2 is why the second lookup under a domain is so much shorter than the first: the NS records from the earlier referrals are in the cache, so the resolver starts at the domain's own servers.

A server that is not authoritative for a name, but knows which servers are, answers with a referral: no answer records, the child zone's NS records in the authority section, and usually the addresses of those nameservers in the additional section. The aa (authoritative answer) flag is not set, which is how the resolver tells a referral from a real answer.

The addresses in a referral are called glue. They are essential when a zone's nameservers are inside the zone they serve. The .com servers can tell the resolver that example.com is served by ns1.example.com, but the resolver could never find ns1.example.com's address without asking ns1.example.com, so the .com zone carries ns1's address as well.

Resolvers are careful about which glue they accept. Since the cache poisoning attacks of the late 1990s, which slipped false addresses into the additional section, a resolver keeps an additional record only if it lies within the zone the replying server is responsible for, its bailiwick. In the simulator, the net servers refer example.net to ns1.example.com and ns2.example.com. Those names are outside net, so the net servers have no business giving their addresses, and the resolver has to look ns1.example.com up separately, starting again from the root. Once it has the address from the .com referral's glue, it can continue.

RFC 2181 also ranks cached data by how it was obtained. Glue and the NS records from a referral are good enough for finding servers, but a resolver will not hand glue to a client as an answer. The simulator marks each cache entry with its source for this reason.

Every record carries a TTL, chosen by the zone's owner, saying how many seconds it may be cached. The resolver stores each record with its expiry time. When it answers from its cache, it gives the client the time remaining, not the original TTL, so a record cached for an hour and served 20 minutes later reaches the client with a TTL of 2,400 seconds. The client cannot keep it past the moment the resolver's copy expires either.

Different records expire at very different times. Referrals for top-level domains last two days, the NS records for a domain often a day, and a host's address anything from a minute to a day. In the simulator, the api.example.net address has a TTL of 60 seconds, so letting one minute pass sends the resolver back to ns1 for it, while everything above it in the tree is still cached.

Negative answers are cached too, as RFC 2308 requires, for the smaller of the zone's SOA record TTL and the SOA's minimum field. A name that does not exist under example.com is remembered for 5 minutes here; the root's answer that there is no .internal top-level domain is remembered for a day.

Because each cache counts down independently, there is no single moment when a changed record "propagates". When you change www.example.com's address in the simulator, the authoritative servers have the new value immediately, but each cache that holds the old one keeps returning it until its own copy expires.

RFC 1034 requires every zone to be available from at least two servers, so that one failing does not take the zone off the internet. When a server does not reply, the resolver waits for a timeout and asks another server for the same zone. The lookup still succeeds, but slowly, which is often the first sign of a broken nameserver. Real resolvers also remember which servers have been slow or silent and avoid them for a while.

If every server for a zone fails to reply, the resolver returns SERVFAIL to the client. RFC 9520 (2023) requires resolvers to cache such failures for a short time, so that a dead zone does not cause a flood of repeated queries. Some resolvers can also keep serving records past their TTL when the authoritative servers cannot be reached, a behaviour standardised as "serve-stale" in RFC 8767.

In the simulator, taking ns1 down and flushing the resolver adds a 1,000 ms timeout to the next lookup under example.com. Lookups already in a cache are unaffected, which is why outages of authoritative servers often go unnoticed until TTLs start running out. Taking ns2 down too makes the zone unreachable: the resolver returns SERVFAIL and caches the failure for 5 seconds, then twice as long after each repeat, up to 5 minutes, which follows the backoff example in RFC 9520. While the failure is cached the resolver sends no queries for that name, even if the servers have come back.

• Recursive resolver software. BIND, Unbound, Knot Resolver and PowerDNS Recursor are the common open-source resolvers. Most internet service providers and companies run one of them, or a commercial equivalent.
• Public resolvers. Cloudflare (1.1.1.1), Google (8.8.8.8) and Quad9 (9.9.9.9) run large resolver networks reached through anycast addresses. Their caches are shared by many users, so popular names are almost always cached, but each address is served from many locations, and each location keeps its own cache.
• Stub resolvers and local caches. On many Linux systems systemd-resolved listens on 127.0.0.53 and caches answers; macOS uses mDNSResponder, and Windows the DNS Client service. Browsers keep their own short-lived caches on top of these.
• Inside clusters. Kubernetes runs CoreDNS as the resolver for pods. It answers names of services in the cluster itself and forwards other questions to an upstream resolver.

The simulator models the parts of resolution that decide which queries are sent and what gets cached. It leaves out:

• Twelve of the thirteen root server identities and one of the two .com/.net servers it lists. A real resolver spreads its queries over all of them.
• Server selection by measured response time, and remembering which individual servers have failed. Here the resolver always prefers the server with the lower fixed round-trip time, and only the failure of a whole zone is cached.
• QNAME minimisation (RFC 9156), which many resolvers now use to send each server only as much of the name as it needs. The simulator sends the full name, as dig +trace does.
• DNSSEC validation, EDNS, truncation and retries over TCP, and record types other than A, AAAA, NS, CNAME and SOA.
• Browser caches, prefetching of records that are about to expire, and serve-stale.