Summary

  • RFC 2182, published as BCP 16 in July 1997, treated server placement as an operational reliability problem.
  • Its recommendation of three servers for most organization zones included a critical condition: at least one should be well removed from the others.
  • The standard was guidance, not proof that any zone’s listed servers had independent power, transit, ownership or real-world reachability.

A zone could list three name servers and still have only one practical route to an answer. If all three sat behind the same access link, in one building, or on one power supply, a single failure could remove the whole set. The number looked redundant; the dependencies were not.

That was the operating problem Robert Elz, Randy Bush, Scott Bradner and Michael Patton addressed in RFC 2182, “Selection and Operation of Secondary DNS Servers.” The IETF published it in July 1997 as Best Current Practice 16. It was not a new DNS protocol. It was an attempt to make the existing system’s redundancy work outside the zone file.

DNS already required multiple authoritative servers for a delegated zone. RFC 2182 separated two questions that could be mistaken for one. A primary held the locally configured zone data; a secondary acquired the zone from it. But a resolver and the parent zone did not use that distinction to rank answers. To the wider DNS, they were simply listed authoritative servers. A secondary helped only if clients could reach it when another server, or its shared infrastructure, could not.

The authors began from operational trouble they said was already visible: poor choices of secondary servers. Geographic placement and diversity of network connectivity could improve reliability and performance. Placing every server at the same local site was explicitly called poor practice. One failed link, site, building, room or power supply might disconnect them all. The point was not that distant machines were automatically safe; it was that the operator had to ask which failures could take several names out together.

RFC 2182 recommended three servers for most organization-level zones, with at least one “well removed” from the others. Four or five could be appropriate when higher reliability justified them. More was not always better: larger NS sets made DNS packets larger and created more chances for unnoticed misconfiguration. The count was a rule of thumb inside a placement argument, not a universal pass mark.

The advice also exposed a practical dependency: someone had to host the remote copy. The RFC described organizations of similar size exchanging secondary service. That arrangement could distribute the zone without disclosing private information, because the exchanged zone data was already publicly obtainable. It turned redundancy into cooperation between operators, with ongoing duties to keep transfers, serial numbers and reachability working.

The BCP did not measure whether deployments followed its advice or survived an outage. A published NS set cannot prove that two providers use different upstreams, that facilities do not share power, or that routes remain independent under stress. “Three servers” is therefore evidence of a count, not an audit of failure paths.

The 1997 document also contains a warning about DNS answers that later aged. RFC 2182 said negative answers were not cached as a general rule. RFC 2308 standardized negative caching the following year, and RFC Editor erratum 4631 later marked the blanket wording inaccurate. The correction is a reminder that even operational best practice has a date and a maintenance history.

RFC 2182’s durable insight was narrower and more useful than a magic number: redundancy is a property of dependencies. A third server matters when it changes what can fail together.

Sources