Test DNS

Test DNS › DNS guides

Understanding the role of a DNS server in the resolution chain

Behind every domain name lies a sequence of questions put to specialised servers, in a precise order and according to rules written forty years ago. Understanding this resolution chain makes it possible to diagnose a fault in a few commands, instead of changing records at random.

Network rack with neatly routed Ethernet cables and switches whose LEDs are lit
Every DNS answer crosses a physical network before reaching a server: the cabling is part of the resolution chain.

A query always starts at the workstation

A browser does not know a site's address: it hands the name to a stub resolver, a small component of the operating system that merely relays the question to a configured resolver, either the access provider's or a public one. The stub carries out no investigation: it sends a query with the RD bit set, for Recursion Desired, and waits for a complete answer. This split explains why changing the resolver in the machine's settings alters the behaviour of every application at once.

The question concerns a name, a type and a class: for example type A for an IPv4 address, AAAA for IPv6, MX for mail, NS for name servers. The types and their format are described in RFC 1035, extended since by many additions. A name typed without a trailing dot is completed with the local search suffix, which sometimes produces a query for a name that does not exist before the one that succeeds, and a noticeable delay on screen.

Recursive and iterative do not mean the same thing

A recursive resolver takes on responsibility for obtaining the answer: it queries the servers one after another until it finds the one that is authoritative, then returns the final answer to the machine, with the RA bit for Recursion Available, which signals that it accepts this work. A server queried iteratively does the opposite: it returns only what it knows, most often a delegation towards a server closer to the answer being sought.

The AA bit, for Authoritative Answer, marks the answer of a server that actually hosts the zone. A resolver answering from its cache does not set it, even when the answer is correct. It is precisely this difference that makes it possible to tell, during a diagnosis, whether you are talking to the right server: a machine supposed to be authoritative that answers without AA, or that refuses the question, has an incomplete configuration.

The descent through the hierarchy

The resolver starts from the root servers, whose list is supplied to it in a hints file shipped with its software. The root does not know the domains themselves: it delegates each top-level domain to a set of servers, which it cites by their names and, where necessary, by their addresses in records known as glue records. The resolver repeats the operation with the top-level domain's server, which in turn delegates to the target zone, down to the server that holds the requested record.

Each step returns a referral: a list of NS records and, when the named server belongs to the delegated domain, the corresponding addresses. Without those glue addresses, the resolver would have to resolve the name of the very server it is looking for, and the loop would never close. This is one of the reasons why an NS record whose target lies inside the delegated zone must be accompanied by its glue in the parent zone.

The cache shortens the loop

Each answer carries a time to live, the TTL, expressed in seconds. The resolver keeps the answer for that time and serves subsequent queries from memory: the full descent only happens on expiry, or for a name never requested before. A long TTL reduces load and latency, a short TTL speeds up the taking into account of a change at the cost of a larger number of queries to the authority.

Negative answers are cached as well. RFC 2308 sets the duration of that cache from the minimum field of the zone's SOA record, with recommended ceilings to avoid freezing an error for too long. A badly tuned field shows up as names that remain unfindable long after they were created, or as a stream of repeated queries to the authority for a name that does not exist.

UDP, TCP and response size

A query normally travels over UDP on port 53, with a historical limit of 512 bytes for the answer. When the answer exceeds that size, the server truncates it and sets the TC bit; the resolver then re-asks the question over TCP, on the same port. This switch is provided for by the standard and transparent to the user, but it costs an extra round trip and must be watched on high-volume zones.

The EDNS(0) extension, described in RFC 6891, makes it possible to advertise a larger buffer size and carries options between the two parties. It has become indispensable to DNSSEC, whose signatures weigh down answers markedly. Encrypted transports, DNS over TLS and DNS over HTTPS, change the exchange channel but not the model: the hierarchy, the delegations and the cache remain identical.

What an administrator should remember

A serious DNS diagnosis begins by identifying which player you are addressing. Querying the authority directly, without recursion, shows what the zone actually publishes; querying the machine's resolver shows what the user sees. Comparing the two answers separates a zone fault from a cache or transport problem in a few seconds.

The same checks, repeated on both authoritative servers of a zone, reveal lagging replication or an interrupted transfer. A discrepancy between the two answers is a more reliable alarm signal than any indicative monitoring, because it bears on the state actually being served.

References

To check a domain name live — root, TLD, name servers — use the DNS test tool. Demarcq.net runs DNS servers: managed DNS operations.

← start of the series Configuring an authoritative DNS server for a zone →