Test DNS › DNS guides

Setting up a secondary DNS server: value, limits and good practice

Adding a secondary DNS server is often presented as the answer to availability. That holds for the failure of a machine, but not for a content error, and it forces choices of network placement and of operation that decide how effective the arrangement really is.

Two rows of server racks separated by an aisle in a computer room — Two redundant servers in the same room fail together: separating the causes of failure matters more than the number of servers.

What a secondary protects against, and what it does not

A secondary server keeps a copy of the zone and answers resolvers when the primary is unavailable: hardware failure, maintenance, network outage, overload. Resolution continues, with slightly dated but consistent content. That is exactly the service expected, and it alone justifies setting up at least one secondary for any zone that matters.

A secondary, however, protects against neither a typing error, nor an accidental deletion, nor a compromise of the primary: it replicates faithfully what it receives, mistake included. Nor does it protect against a failure of the hosting provider shared by both machines, or against a delegation error at the parent. Confusing these cases leads to arrangements that look reassuring on paper and are inoperative on the day of the incident.

The recommendations of RFC 2182

The BCP 16 document, published as RFC 2182, deals with the selection and operation of secondary servers. It recommends several secondary servers spread across distinct networks, a single source of writes, and warns against configurations in which every server depends on the same infrastructure. These recommendations remain the operational reference, almost three decades after their publication.

The text also stresses that a secondary server must be operated with the same seriousness as a primary: monitoring, security updates, checking that the copy is fresh. A forgotten secondary, left on an old version of the software and unsupervised, becomes a target rather than a protection, while still being listed in the delegation.

Network placement: shared failure is the real threat

Two machines in the same room, powered from the same source and connected to the same switch, do not constitute redundancy: they fail together. Placement must aim at separating the causes of failure, whether power, network, operator or hosting provider. A secondary at another hosting provider, in another region, brings more than a third server in the same rack.

Anycast distribution, which consists in advertising the same address from several points in the network, answers a different need: load sharing and resilience to certain volumetric attacks. It does not replace the separation of sources of writes, and it makes diagnosis harder, since the same address may be served by different machines depending on where the query comes from.

What replication costs

Each secondary multiplies transfers and read load on the primary. On a zone that is rarely modified, the cost is negligible; on a frequently updated zone, multiplying copies can saturate the primary's link, especially if transfers fall back to full mode. The number of secondaries should therefore be decided with the volume of the zone and the frequency of changes in mind, not only with the wish to be reassured.

Replication also imposes serial discipline. A primary whose serial number does not increase leaves its secondaries on an earlier version, with no error message: the only trace is a gap in the serial, visible only if it is measured. This is why recording the serial on each server is part of the routine checks of zone hosting.

Operational points to watch

Four signals are enough to cover the essentials: the same serial number everywhere, the age of the last copy staying below the expiry time, no transfer failure in the logs, and the availability of the primary as seen by each secondary. These measurements can be collected without sophisticated tools, from the server's own responses.

To these must be added the consistency of the glue addresses at the parent. When a server changes address, the child zone may be perfectly up to date while the parent zone still points to the old address: the server then becomes unreachable for resolvers, even though it is running. This case occurs with every botched migration, and the check is made at the parent, not on the machine.

A secondary is justified by a written scenario

Before adding a machine, it is better to write down the scenario it covers: which failure, for how long, with what impact for users, and how the service is restored. This sentence, often missing from projects, distinguishes useful redundancy from an accumulation of servers whose state nobody knows.

When the zone is critical, the question goes beyond the number of copies: it touches on the restoration procedure, on who holds the access, and on the person able to take back control. A well-placed secondary does not replace that preparation, it extends it.

References

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

← DNS zone hosting: primary, secondary and transfers DNSSEC: principles of signing and validation →