Secondary DNS: Add a Backup Nameserver Before You Need It

If your domain has only one nameserver provider, you have a single point of failure you probably don't think about until it breaks. When that provider has an outage — and every DNS provider eventually does — nobody can resolve your domain. Not your website, not your email, not your API. The server itself can be perfectly healthy and it won't matter. This is what secondary DNS fixes, and it's a lot less work to set up than most people expect.

Symptom: Your Site "Goes Down" Even Though the Server Is Fine

The pattern is usually the same. You get a wave of "site is down" reports, you SSH into the VPS and everything looks normal — Nginx is running, MySQL is up, load average is boring. You curl the server's IP directly and get a response. But dig yourdomain.com from your laptop times out or returns SERVFAIL.

Run a quick check against your actual nameservers:

dig yourdomain.com NS +short
dig @ns1.yourprovider.com yourdomain.com A

If the second command hangs or errors while the first one still lists the nameserver, the authoritative server for your zone is unreachable. That's not a hosting problem or a WordPress problem — it's a DNS availability problem, and no amount of restarting Apache will touch it.

Cause: One Provider Is One Point of Failure

Most small setups list two nameserver hostnames at the registrar — say ns1.example-dns.com and ns2.example-dns.com — and assume that's redundancy. It isn't, if both live behind the same provider's infrastructure, same anycast network, same API layer, same outage blast radius. When that provider's control plane goes down (BGP mistake, DDoS, expired cert on their resolver edge, whatever), both your nameservers go dark together, because they were never actually independent.

Real redundancy means a second, operationally separate DNS provider holding a synced copy of your zone — different network, different company, different failure domain. If provider A goes down, provider B keeps answering queries and your domain stays resolvable the whole time.

Fix: Add a True Secondary DNS Provider

There are two ways to do this. Pick based on where your primary zone currently lives.

Option 1 — Zone Transfer (AXFR), the "set it and forget it" way

If your primary nameserver is a real DNS server (BIND, PowerDNS, on a VPS) rather than a locked-down panel, the clean way is a zone transfer: the secondary provider pulls a live copy of your zone automatically and stays in sync forever.

On the primary (BIND example), allow the secondary's IP to transfer your zone:

zone "yourdomain.com" {
    type master;
    file "/etc/bind/zones/db.yourdomain.com";
    allow-transfer { 203.0.113.50; };
    also-notify { 203.0.113.50; };
};

Restart BIND, then hand the secondary provider (Cloudflare's secondary DNS, deSEC, NS1, or similar) your primary IP and let them pull the zone. They'll confirm the transfer succeeded and give you their nameserver hostnames.

Option 2 — Manual sync, if your primary is a locked-down panel

If your zone lives in cPanel/WHM's DNS clustering or a registrar's basic DNS panel that doesn't expose AXFR, you won't get automatic sync. Instead:

• Export your zone file from WHM > DNS Functions > Edit Zone, or via whmapi1 dumpzone yourdomain.com
• Import the same records into the secondary provider's dashboard
• Set a recurring reminder (monthly is reasonable) to re-check that both match after any DNS edit

It's manual, but manual redundancy still beats none — and it's the only option when your primary doesn't support transfers.

Point the registrar at both

Whichever route you took, the registrar needs to list nameservers from both providers, not just the new one:

Update the NS records at your registrar, then verify globally after propagation:

dig yourdomain.com NS +short
dig @ns1.secondaryprovider.net yourdomain.com A +short

Both queries should return matching answers. If the secondary responds correctly on its own, your redundancy is live.

Prevention: Test the Failover Before You Need It

Adding a secondary provider is only half the job — most people never confirm it actually works until the day the primary is already down, which is the worst possible time to find out it doesn't.

• Query the secondary directly. Run dig @secondary-ns yourdomain.com periodically and confirm it answers independently, not just that it's listed.
• Keep TTLs sane. A 24-hour TTL means a real outage on your only nameserver could keep resolving stale (or nothing) for a full day even after you fix it. 1–4 hours is a reasonable middle ground for most sites.
• Monitor both nameservers separately, not just your website's HTTP endpoint — an uptime check that only pings your homepage won't catch a DNS-layer failure until resolvers start caching failures too.
• Re-sync after every DNS change if you're on the manual-export path — a secondary that's stale by three records is still a secondary that gives wrong answers.

None of this requires touching your hosting plan or migrating anything. It's an afternoon of setup that turns "our DNS provider had an outage" from a full outage into a non-event nobody outside your team even notices.

Frequently Asked Questions

Do I need secondary DNS if I'm already using SkyServer's nameservers?

SkyServer's nameservers already run redundant, geographically distributed infrastructure for hosted DNS, so most customers on our default nameservers don't need to add anything extra. Secondary DNS mainly matters if you're running your own authoritative nameserver on a VPS, or using a single third-party DNS provider outside of SkyServer.

Can I use two different DNS panels without zone transfers?

Yes — that's the manual-sync route. It works, but it's only as good as your discipline about re-exporting and re-importing the zone every time a record changes. If your primary supports AXFR, automatic transfer is far less error-prone long term.

Will adding a secondary nameserver slow down DNS resolution?

No. Resolvers query whichever authoritative nameserver answers fastest and cache the result per your TTL. A healthy secondary adds redundancy, not latency — worst case, it's occasionally the one that responds first.

What happens to email (MX) during a primary DNS outage if I have secondary DNS set up?

If the secondary holds a synced copy of your full zone — including MX, SPF, and DKIM records — mail resolution keeps working exactly as before. This is actually where secondary DNS matters most, since a mail queue that can't resolve your MX record will bounce or defer messages the whole time the primary is down.

How do I know if my two "redundant" nameservers are actually independent?

Check the IP ranges and ASN (autonomous system number) each nameserver resolves to — a quick whois on each nameserver's IP will show the owning network. If both come back to the same company or the same ASN, you don't have real redundancy no matter how many hostnames are listed at the registrar.