What Is Secondary DNS

Secondary DNS is a redundant copy of your DNS zone hosted on a separate nameserver. It serves the same DNS records as your primary server but provides failover and load distribution -- if the primary goes down, the secondary continues answering DNS queries for your domain.

How Primary and Secondary DNS Work

In a standard DNS setup:

• The primary (master) server holds the authoritative, editable copy of your zone
• One or more secondary (slave) servers hold read-only copies synchronized from the primary
• All servers (primary and secondary) are listed as authoritative NS records for your domain
• DNS resolvers can query any of them -- there's no preference order

example.com.  86400  IN  NS  ns1.dnscale.eu.    ; primary
example.com.  86400  IN  NS  ns2.dnscale.eu.    ; secondary
example.com.  86400  IN  NS  ns3.dnscale.eu.    ; secondary

From a resolver's perspective, all nameservers are equal. The resolver picks one (often the fastest to respond) and queries it. Understanding DNS server types helps clarify how authoritative servers differ from recursive resolvers.

The terms "primary/secondary" have replaced the older "master/slave" terminology in DNS. The functionality is identical -- only the naming has changed.

Zone Transfers

Secondary servers get their data from the primary through zone transfers:

AXFR (Full Zone Transfer)

The secondary requests the entire zone from the primary. Used for initial synchronization or when the zone has changed significantly.

Secondary -> Primary: "Send me the full zone for example.com"
Primary -> Secondary: [entire zone data]

AXFR transfers the complete zone file, including all A, AAAA, MX, TXT, CNAME, SRV, PTR, and every other record in the zone. For large zones with thousands of records, AXFR can be bandwidth-intensive. The transfer is done over TCP to ensure reliable delivery.

IXFR (Incremental Zone Transfer)

The secondary requests only the changes since its last known serial number. More efficient for large zones with frequent small changes.

Secondary -> Primary: "Send changes since serial 2026030901"
Primary -> Secondary: [only the added/removed records]

IXFR is the preferred transfer method for large zones because it transmits only the differences. The secondary includes its current SOA serial number in the request, and the primary responds with a sequence of deletions and additions needed to bring the zone up to date.

If the primary cannot provide an incremental update (for example, if the serial gap is too large or the change history has been discarded), it falls back to a full AXFR transfer automatically.

Transfer Triggers

Zone transfers happen when:

1. The refresh interval in the SOA record expires -- the secondary checks if the serial has changed
2. The primary sends a NOTIFY message -- tells secondaries that the zone has changed
3. The secondary starts up and has no data or stale data

NOTIFY messages (RFC 1996) are the primary mechanism for prompt updates. When you change a record in DNScale, the primary immediately sends NOTIFY to all listed secondaries, which then initiate a zone transfer. Without NOTIFY, secondaries would only check for updates on the SOA refresh interval, which could be hours.

Why You Need Secondary DNS

Redundancy and Uptime

If your only nameserver goes down, your entire domain becomes unreachable -- no website, no email, no API. With secondary DNS, other nameservers continue answering queries. This applies to all services that depend on DNS, including email delivery (which requires MX records) and SSL certificate validation (which may check CAA records).

Faster Query Response

Multiple nameservers in different geographic locations mean resolvers can query the nearest one, reducing latency for users worldwide. This is especially effective with anycast routing where each nameserver IP is announced from multiple locations via BGP.

DDoS Resilience

Distributing DNS across multiple servers (especially in an anycast network) makes it much harder for attackers to overwhelm your DNS infrastructure. For more on DNS threats, see DNS Attacks and Threats.

Compliance

Many domain registrars and TLD registries require at least two nameservers. Some enterprise environments require geographic redundancy.

Types of Secondary DNS Setups

Same-Provider Secondary

All nameservers are operated by the same DNS provider but run on separate infrastructure:

ns1.dnscale.eu.  ->  Server in Europe (Location A)
ns2.dnscale.eu.  ->  Server in Europe (Location B)
ns3.dnscale.eu.  ->  Server in North America

This is the default with DNScale -- your zone is automatically served from multiple geographically distributed edge nodes.

Hidden Primary Architecture

Your primary is a private ("hidden") server that isn't listed in NS records. Secondary servers at one or more providers serve all public queries:

Hidden primary: internal-dns.yourcompany.com (not public)
Public NS: ns1.dnscale.eu.
Public NS: ns1.anotherprovider.com.

The hidden primary architecture has several advantages:

• The primary server is not exposed to the internet, reducing its attack surface
• You can run the primary on internal infrastructure without worrying about DDoS protection
• Zone editing tools only need to connect to the hidden primary
• All public-facing DNS is handled by hardened, anycast-enabled providers

This is the most common architecture for organizations that want maximum control over their zone data while leveraging commercial DNS providers for serving.

Multi-Provider Secondary (Public Primary)

Similar to above, but the primary is also publicly listed:

Primary: ns1.yourprovider.com (editable, public)
Secondary: ns1.otherprovider.com (syncs via AXFR/IXFR)

This gives you full redundancy across providers. If one provider has an outage, the other continues serving. See Multi-Provider DNS Deployment for a detailed guide.

Setting Up Secondary DNS

DNScale's Built-in Redundancy

DNScale serves as a primary authoritative DNS with automatic replication to all edge nodes. No manual secondary configuration is needed — zone data propagates via real-time database replication across the anycast network, which is faster than traditional zone transfers. Changes are reflected across all nodes within seconds.

Because DNScale operates multiple nameservers across geographically distributed POPs, you already have the redundancy benefits of secondary DNS without configuring AXFR or IXFR.

Multi-Provider with DNScale

For maximum redundancy, combine DNScale with another DNS provider using Infrastructure as Code:

1. Use DNScale's API or Terraform provider to manage your zones
2. Use the same IaC tool (Terraform or DNSControl) to push identical records to a second provider
3. List both providers' nameservers in your NS records

This approach keeps both providers in sync through automation rather than zone transfers, and gives you full control over records at both providers.

See Multi-Provider DNS Deployment for a step-by-step guide.

DNScale does not support AXFR/IXFR zone transfers. Multi-provider redundancy is achieved through API-based synchronisation using Terraform or DNSControl, which provides more control and auditability than traditional zone transfers.

TSIG Authentication

Zone transfers should be authenticated to prevent unauthorized servers from copying your zone data. TSIG (Transaction Signature) uses shared secrets to authenticate transfer requests:

# On the primary, define a TSIG key
key "transfer-key" {
    algorithm hmac-sha256;
    secret "base64-encoded-secret";
};
 
# Restrict AXFR to clients presenting this key
zone "example.com" {
    allow-transfer { key "transfer-key"; };
};

TSIG protects against two threats:

1. Unauthorized zone copying: Without TSIG, anyone who knows your primary's IP can request a full zone transfer, exposing all your DNS records
2. Zone poisoning: TSIG ensures that secondaries only accept zone data from the authenticated primary, preventing an attacker from injecting false records

When using traditional AXFR-based secondary DNS between your own servers or with providers that support zone transfers, the TSIG key must use hmac-sha256 or stronger — older algorithms like hmac-md5 are deprecated.

Always use TSIG for zone transfers, even if you also restrict transfers by IP address. IP-based restrictions alone are insufficient because source IPs can be spoofed.

SOA Record and Zone Transfer Timing

The SOA record contains several fields that control zone transfer behavior:

example.com.  SOA  ns1.dnscale.eu. admin.example.com. (
    2026031801  ; Serial number
    3600        ; Refresh (1 hour)
    900         ; Retry (15 minutes)
    604800      ; Expire (1 week)
    300         ; Minimum TTL
)

With NOTIFY enabled, the refresh interval is less critical because secondaries are proactively notified of changes. However, refresh acts as a safety net in case a NOTIFY message is lost.

DNScale's Approach to Redundancy

Traditional secondary DNS relies on AXFR/IXFR zone transfers, which can have delays between the primary update and secondary synchronization. DNScale takes a different approach:

• Real-time database replication synchronizes zone data to all edge nodes in near real-time
• All edge nodes serve the same data within seconds of a change
• No AXFR polling delays — updates propagate as they happen
• Anycast routing ensures resolvers reach the nearest edge node
• Multi-provider redundancy via API and IaC tools (Terraform, DNSControl) rather than zone transfers

This means DNScale provides the redundancy benefits of secondary DNS without the synchronization delays. DNS propagation to recursive resolvers still depends on TTL expiration, but the authoritative side is consistent almost instantly.

Best Practices

1. Always have at least two nameservers -- one nameserver is a single point of failure

2. Use geographically distributed servers -- protects against regional outages and improves query latency

3. Consider multi-provider DNS for critical domains -- no single provider is 100% reliable

4. Monitor zone transfer status -- ensure secondaries are in sync by comparing serial numbers

5. Use TSIG for zone transfer authentication -- never allow unauthenticated AXFR

6. Keep the SOA refresh/retry values reasonable -- 1 hour refresh, 15 minute retry is a good default

7. Set appropriate TTL values -- shorter TTLs mean faster failover but more query volume

8. Test failover regularly -- verify that your domain remains reachable when the primary is down

Verifying Secondary DNS

Check that all nameservers return the same serial number:

# Get the SOA serial from each nameserver
dig +short SOA example.com @ns1.dnscale.eu
dig +short SOA example.com @ns2.dnscale.eu
dig +short SOA example.com @ns3.dnscale.eu
 
# Compare A record responses across nameservers
for ns in ns1.dnscale.eu ns2.dnscale.eu ns3.dnscale.eu; do
  echo "$ns: $(dig +short A example.com @$ns)"
done

If serial numbers match, all servers are in sync. If they differ, check replication status or zone transfer logs depending on your setup.

Related Topics

• What Is an SOA Record -- SOA controls zone transfer timing
• What Is an NS Record -- NS records define your nameservers
• Multi-Provider DNS Deployment -- redundancy across providers
• Anycast DNS Network -- geographic distribution of DNS
• DNS Server Types -- understanding authoritative vs recursive servers
• DNS Attacks and Threats -- why DNS redundancy matters for security
• DNSSEC Key Management -- signing considerations for secondary zones

Conclusion

Secondary DNS is fundamental to a reliable DNS infrastructure. It provides redundancy, faster global query response, and protection against outages and DDoS attacks. Whether you use traditional AXFR/IXFR zone transfers with TSIG authentication, or an API-driven multi-provider approach like DNScale offers through Terraform and DNSControl, ensuring your zones are served from multiple independent nameservers is one of the most important steps you can take for domain reliability.