What is primary DNS?

The DNS system is used to connect human-friendly domain names with computer-friendly IP addresses and enable internet users to access the website they are looking for.

When a user enters a domain name into a web browser, the user’s computer communicates with a DNS resolver, which navigates the DNS system to reach an authoritative name server (often the primary server, but sometimes the secondary if primary is down or overloaded) with the IP address for the requested website. This corresponding IP address is sent back to the user and the user is connected to the website.

The primary DNS server is where an administrator configures zones and DNS records for a domain. Secondary servers are set up to build resiliency into the system. These servers hold complete copies of the records configured in the zone on the primary server and are used for query resolution when a primary server unavailable.

Companies might set up dozens of servers and the zone (and the records within) from the primary name server is copied to all secondary servers.

Primary DNS servers also hold a domain’s start of authority (SOA) records, which provide a sort of version control system, notifying secondary servers of updates to the primary zone file and tracking the replication process with backup servers.

The distinction between primary and secondary DNS servers is not visible to users on the internet. These servers have the same information and the distinction only holds meaning to the administrator. Primary is where changes are made, secondary servers are the ones that get copies from the primary.

This system plays a pivotal role in both DNS traffic routing and network resilience.

The Domain Name System (DNS) is the component of the internet standard protocol responsible for converting human-friendly domain names into the internet protocol (IP) addresses that computers use to identify each other on the network.

Often called the “phonebook for the internet,” a more modern analogy is that DNS manages domain names in much the same way as smartphones manage contacts. Smartphones eliminate the need for users to remember individual phone numbers by storing them in easily searchable contact lists.

Likewise, the DNS enables users to connect to websites by using internet domain names instead of IP addresses. Rather than having to remember the web server is at “93.184.216.34,” for instance, users can go to the webpage “www.example.com” to get their wanted results.

The primary DNS server holds name server (NS) records, A records, MX records and CNAME records (among other types) that route the appropriate data and information back to the to the user.

Crucially, the primary server also holds the SOA record for a domain. SOA records provide authoritative information about a domain, including primary name server, administrator email address, refresh timers (which specify the frequency of zone refreshes) and the domain serial number.

When a domain is registered, its name server (NS) records are created and stored on a primary DNS server, typically provided by a hosting company or a DNS service provider. And when an administrator wants to modify or update DNS records, they must do so on the primary DNS server. The changes then propagate to all secondary servers.

Server administrators can designate any DNS server as primary or secondary. In fact, servers can have a primary designation in one zone and a secondary designation in another. Each DNS zone, however, can only have a single primary server.

When a user enters a domain name into a browser or app, the request goes to a recursive resolver. Typically, the user's device has predefined DNS settings, provided by the internet service provider (ISP), that determine which resolver is deployed.

The resolver checks its DNS cache (the temporary storage within a web browser or OS such as Windows or Linux) for the domain's corresponding IP address. If the DNS lookup data isn’t cached, the resolver retrieves it from the authoritative DNS server, which looks up the DNS zone file, caches the DNS record—for a time specified by the record's time-to-live (TTL)—and returns the appropriate IP address to the user's device.

Then, the browser or app can initiate a connection to the host server at that IP address and access the requested website or service.

DNS servers are categorized as “primary” and “secondary” based on their role. Whereas the primary DNS server is the authoritative source for a domain’s DNS records and holds the original read/write version of the zone file, secondary DNS servers hold read-only replicas of the zone file for load balancing and redundancy management. If a primary server is down, queries are automatically routed to a secondary server which fulfills the request.

Secondary DNS servers are non-essential; DNS systems can function when only a primary server is available. But it is standard and often required by domain registrars, to maintain at least one secondary server to facilitate round-robin DNS (which distributes traffic evenly across each server), prevent denial-of-service and generally build resiliency into a system. If a server, or multiple servers fail, there is a backup that can connect the user to the website they are looking for.

Both primary and secondary servers help maintain the efficiency of DNS systems; using them together means that user queries can be resolved by any available server, regardless of primary or secondary status. However, let’s elaborate on the distinctions between primary and secondary DNS servers.

In addition to storing the primary zone file, the primary DNS server responds to update requests from the domain administrator and processes dynamic updates. Secondary zone servers are backup servers that handle DNS requests during primary server downtime or when the primary server is overloaded.

The primary zone file on the primary name server contains all the A records (address records for IPv4); AAAA records (address records for IPv6); MX records (which direct to mail servers); CNAME records (which map aliases to their true, or “canonical,” domain names); SOA records (which contain all the administrative information for a domain); and TXT records (which indicate the sender policy framework record for email authentication) for a given domain. The administrator directly manages this file and any updates or changes to DNS records are made here first.

Secondary DNS servers are replicas of the zone file, transferred from the primary server. They cannot accommodate direct revision or edits to the zone file; instead, they periodically check with the primary server for updates in a process called zone transfer.

Configuring a primary DNS involves setting up the zone file, resource records and access controls and may include arranging authoritative and incremental zone transfers (AXFRs and IXFRs) to designated secondary servers.

Secondary DNS configurations require administrators to set up communication protocols between the primary and secondary servers for zone data transfers and to specify the frequency of check-ins with the primary server for updates.

Though the primary DNS server is essential, it also represents a single point of failure. If it crashes and there are no designated secondary servers to take over the workload, the entire DNS resolution process can suffer. Secondary servers cannot exist without a primary DNS server, but if the primary server is down, secondary servers can keep the DNS operational until the primary server is restored.

Administrators rely on secondary DNS servers to support the primary server and maximize system resiliency.

Since secondary servers have complete copies of all the records on the authoritative name server, they can stand in for the primary server if it crashes or is otherwise unavailable. If, however, the system administrator had to create and manage copies manually, it would create a delay between primary and secondary servers. Instead, primary and secondary DNS automate the copying process.

When an admin makes a change to the primary server, the domain serial number housed in the SOA records changes to the next number in the progression (if the serial number was SOA 1, for instance, it changes to SOA 2).

In a traditional DNS configuration, the secondary name server will check in with the primary server at predetermined intervals to get the current SOA serial number. If the primary server reports a change, the secondary server makes an AXFR or IXFR request to initiate copying. Then, the primary server sends the updates back to the secondary, along with the updated SOA serial number.

This DNS configuration forces secondary servers to initiate XFR pull requests to know the primary server was changed, creating an additional step that slows down the DNS.

However, more modern configurations use the ‘NOTIFY’ protocol, which allows the primary name server to send a user datagram protocol (UDP) message to the backup server whenever an admin makes a change. Secondary servers then check the SOA serial to confirm the change and initiate the pull request for updates.

Using this approach to primary and secondary DNS helps system administrators maximize system reliability and resiliency. It also keeps servers in sync and makes sure that users can go to any server for the most current information.

While using primary and secondary DNS is the most common way to achieve reliability through redundancy on the internet, the practice isn’t without its challenges. The primary-secondary approach often can’t accommodate advanced features, such as global server load balancing (GSLB).

Traffic steering tools like GSLB direct user traffic to DNS servers based on geographical proximity. DNS routers automatically send requests to the closest available server to accelerate the resolution process.

However, this feature is often proprietary and cannot be transferred over XFR. A domain administrator can set up GSLB on the primary name server, but they wouldn’t be able to transfer the configuration to secondary servers.

To address this issue, businesses can choose vendors with a proprietary system that can support multiple servers across the world. Anycast DNS, for example, enables administrators to assign one IP address—or a set of IP addresses—to multiple, geographically distributed servers.

Instead of the one-to-one communication dynamics associated with conventional DNS, Anycast facilitates one-to-many communication. Therefore, when a user submits a request, the request goes to a network of resolvers (instead of a single resolver) and to the closest available server for resolution.

Or, when using multiple vendors, organizations can set up multiple primary name servers and situate the user between them. Rather than rely on secondary DNS and XRF transfers, an administrator would configure all servers directly by using an API.

Both primary and secondary DNS are important for query routing, so maintaining and optimizing primary DNS servers can accelerate the entire DNS system. Businesses can get the most out of their DNS by incorporating the following practices.

Selecting a DNS provider with high uptime, comprehensive redundancy protocols and accessible customer support can help ensure that DNS queries are answered quickly and reliably.

Primary DNS providers range in their offerings, from public DNS services to premium, managed DNS servers. Determining the best solution for an organization will depend on organizational needs¹, budgets and complexity. While using public DNS provides clients with open, free DNS access, a migration to premium DNS can offer more fine-grained control.

Keeping abreast of the latest DNS vulnerabilities and threats (such as DNS tunneling, DDoS attacks and cache spoofing) and using firewalls, domain name system security extensions (DNSSECs) and other security measures can help secure DNS servers² and mitigate risk.

Updating DNS records promptly and frequently to reflect changes to IP addresses, infrastructure and services facilitates consistent, accurate domain resolution. 

The conventional primary/secondary DNS architecture is becoming obsolete among modern, managed DNS providers. Today, most providers offer name server IPs to use and behind each of those IPs is a pool of DNS servers that route requests using anycast (a one-to-many transport protocol). This approach tends to provide better redundancy and higher availability than the classic model.

However, even in advanced DNS deployments, secondary DNS services can help businesses:

Secondary DNS enables teams to access tools, code and legacy systems that point to an old DNS server hosted in their organization. During architecture migration, secondary servers let administrators define the secondary DNS provider without breaking dependencies. This keeps all existing processes in sync but enables the new DNS server to respond if in-house servers slow down or fail.

For many organizations with high-traffic sites and mission-critical web apps, outages cannot be tolerated. Using secondary name servers helps administrators avoid any single point of failure should primary DNS servers encounter latency or other issues.

Managed services configure a dedicated DNS deployment—which runs on a separate network and servers from its regular, managed DNS service—for your organization. This approach facilitates redundancy while allowing businesses to keep services with one provider. Furthermore, the dedicated deployment isn’t shared with other organizations, so it’s insulated from attacks targeting other customers on the service.