Test DNS › DNS guides

Configuring an authoritative DNS server for a zone

An authoritative server guesses nothing: it publishes exactly the contents of a zone, and says so. Between the zone file, the NS records and the delegation placed at the parent, three levels must stay consistent, otherwise the domain resolves intermittently.

Open server rack showing several rack-mounted machines and their cabling — An authoritative server publishes the contents of a zone: its configuration is checked before the reload, not after.

Hosting a zone is not hosting a domain

A zone is a subset of the namespace, administered as a single unit. The domain example.test can be split into several zones: the example.test zone itself, and a delegated zone for a subdomain entrusted to another team. An authoritative server for the child zone has no authority over the parent, and vice versa: it is this separation that makes delegation possible without permanent coordination between the two administrations.

The zone file describes sets of records with the same name and the same type, called RRsets. An address, a mail server, a signing key are separate records, and each carries its own TTL. Understanding this granularity avoids a common mistake: a TTL changed on one record does not apply to the other records with the same name.

The SOA, the zone's identity card

The SOA record names the zone's primary server, the address of the person responsible, then five numeric values: the serial number, the refresh and retry intervals for the secondaries, the expiry time beyond which a secondary stops answering, and the minimum, which today serves as the negative caching TTL under RFC 2308. These fields are not decorative: they drive replication and the caching behaviour of resolvers.

The serial number must increase with every published change. RFC 1982 defines the comparison arithmetic for these numbers, which allows wrapping past the limit of the representation, but the safest practice remains a simple increment, or a timestamp in year, month, day and counter format. A secondary transfers a zone only if it judges the primary's serial higher than its own: a forgotten serial produces a server still answering with the old contents, with no visible error.

The zone's NS records and the glue question

At the apex of the zone, the NS records designate the servers that are authoritative for it. They form a set: resolvers may query any of the servers listed, so it is imperative that all of them serve the same contents. A server listed but not loading the zone is a lame delegation, one of the most common errors described in RFC 1912.

When the target of an NS record belongs to the delegated domain itself, the resolver cannot find its address without querying that server: the parent zone must therefore publish the address together with the NS. This is the glue record. It lives at the parent, it is indispensable, and it must be corrected as a priority if a server's address changes, otherwise the domain becomes partially unreachable.

Delegation is set up at the parent

Configuring the server is not enough: the parent zone must actually delegate the domain. At a registrar, this operation consists of declaring the domain's name servers; technically, the parent then publishes NS records in its own zone file. As long as that declaration does not exist, the name remains unresolvable even if the zone is perfectly served by its authority.

The two sets of NS records, the parent's and the child zone's, must agree. Some registrars enforce a single list, others tolerate a temporary discrepancy, but a resolver that receives two different lists behaves unpredictably depending on which server it queries. Checking that they agree, in both directions, is part of commissioning.

Writing the zone and checking it before reloading

Modern name servers provide syntax-checking tools that re-read the file without applying it: a zone check and a general configuration check. Running them systematically avoids the classic scenario of a reload refused in production, where the server carries on serving the old version without anyone noticing immediately.

Two authoring rules deserve particular attention. A CNAME cannot coexist with other records at the same name, nor be placed at the apex of the zone: it would make the zone invalid. And a name entered without a trailing dot is relative to the zone's origin, which produces unexpected targets: absolute targets are written with their trailing dot.

Check from the resolver side, not only the server side

After the reload, verification begins with a direct query to the authoritative server, without recursion: the answer must carry the AA bit and contain the expected record. The same question put to the parent must return a delegation to the declared servers, and not an authoritative answer: if the parent answers itself, the delegation has not taken effect.

The check ends with the public resolvers, which show what the user sees. A discrepancy between the authority and the public resolver points to a cache, a partial delegation or a lagging secondary server. Repeating the operation on each server listed in the NS records, noting the serial number returned, gives a reliable picture of the state of the estate within seconds.

References

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

← Understanding the role of a DNS server in the resolution chain DNS zone hosting: primary, secondary and transfers →