We see a fair amount of confusion around secondary DNS — partly because it’s an overloaded term. A lot of registrars ask you for “primary” and “secondary” nameservers for your domain, but that’s not really what secondary DNS is all about.
Instead, you can think of secondary DNS like a slaving mechanism for your DNS: a way for a DNS server or service to pull DNS records from another DNS server, and keep them up to date, using the DNS protocol itself.
Master / Slave and Primary / Secondary DNS
In order to understand secondary DNS, we need to have a clear understanding of the RFC definitions of a master/slave DNS server setup. The master/slave DNS (RFC 1996) server setup includes one master DNS server and one or more slave DNS servers. The master DNS server is any authoritative server configured to be the source of zone transfer for one or more slave servers. There are other types of master/slave DNS configurations, but for the purpose of clearly explaining secondary DNS, we’ll keep the configuration examples simple.
A primary/secondary DNS server setup is a master/slave setup where the primary DNS server is the master and the secondary DNS server is the slave. The secondary server is created at a second DNS provider to provide redundancy in the DNS network.
The primary (master) DNS server is an authoritative server for which the zone information is locally configured, (RFC 2182) usually via via the provider’s interface or API. There can be both master and slave servers within the primaryDNS server network.
The secondary (slave) DNS server is an authoritative server that obtains information about a zone from the primary server via zone transfer. (RFC 2182) The secondary DNS server is slaved to the primary server.
Reasons to Use Secondary DNS
In the past, secondary DNS was used primarily to slave your backup nameserver to your primary one. There are certainly still plenty of similar deployments on the internet today. However, the current practice for modern managed DNS providers is to provide several nameserver IPs to use - which in many cases comprise multiple, anycasted pools of servers. These DNS providers are architected to provide inherent redundancy and high availability.
However, in today’s internet there are still uses for secondary DNS. Some customers have tools, code, or other dependencies on an existing DNS server or service, but want to leverage a high performance, reliable platform to deliver DNS. For example, you might have scripts that automate creation of new DNS records in BIND zone files on an in-house DNS server, but you don’t want to run your own anycasted, SLA-guaranteed DNS network. You can continue using your existing DNS setup as the management plane and setup secondary DNS with a reputable anycasted, SLA-guaranteed provider. In this scenario you can keep your records in sync, and point your domains at your anycasted provider for high performance, highly available delivery.
Other customers have stringent requirements around single points of failure. Some organizations, especially high traffic sites that can be heavily affected by any outage, place a premium on the idea that no one system or service should be responsible for any critical piece of the delivery pathway, including DNS. These customers might use two or more managed DNS providers and configure nameservers from both for their domains.
Rather than needing to make record changes in the systems of both providers, a common approach is to configure one of the providers as primary and the other as secondary, slaved to the primary provider. Then, all management is done in the primary provider, but both primary and secondary are used for delivery. Any catastrophic failure in the primary provider is mitigated by the secondary provider. By adding a second DNS provider, you have two separate DNS networks running simultaneously. These two networks provide backup for each other and for your users in the event one network is offline or has degraded performance.