Secondary DNS: Set Up a Second Provider with TSIG

A lot of domains technically have two nameservers and practically have one. ns1 and ns2 sit with the same provider, on the same network, occasionally on the same machine. When that provider is hit by a DDoS attack, the second name in the list does nothing for you.

What secondary DNS buys you

A secondary DNS server is authoritative for your zone, but it does not hold the master copy. It pulls the data from the primary and then answers queries with the same authority. Resolvers cannot tell the difference and do not need to.

Its value depends almost entirely on where it lives. RFC 2182, “Selection and Operation of Secondary DNS Servers”, advises placing secondaries so they do not fail together with the primary: different network, different location, ideally a different operator. For DDoS resilience, that is the whole point. A flood aimed at provider A does not automatically reach provider B.

The attack patterns aimed at nameservers are described in DNS DDoS attacks.

How zone transfers work

You edit a record on the primary and bump the SOA serial. The primary sends a NOTIFY. The secondary queries the SOA, sees a higher serial and fetches the changes via IXFR, falling back to AXFR when needed. If the NOTIFY never arrives, the secondary still polls on the refresh interval.

Getting the SOA timers right

The SOA record decides how the secondary behaves when things go wrong.

example.com.  3600  IN  SOA  ns1.example.com. hostmaster.example.com. (
                  2026101801 ; serial (date + counter)
                  3600       ; refresh: poll every hour
                  900        ; retry: every 15 minutes after a failure
                  1209600    ; expire: give up after 14 days without contact
                  3600 )     ; negative caching TTL

Expire is the number that matters. As long as the secondary has reached the primary within that window, it keeps serving the zone. RFC 1912 suggests two to four weeks. An expire of one day is asking for trouble: if the primary dies on a Friday evening, the secondary quits on Saturday.

Setting up secondary DNS with BIND

The example uses documentation addresses: primary at 198.51.100.10, secondary at 203.0.113.53. If your secondary is a managed provider, its control panel replaces the secondary half; the primary half stays the same.

1. Generate a TSIG key on the primary:

tsig-keygen -a hmac-sha256 xfr-key > /etc/bind/xfr-key.conf

The file contains a key "xfr-key" { … }; block. The secondary needs the identical block. Move it over a secure channel, not plain email.

2. Primary:

include "/etc/bind/xfr-key.conf";

zone "example.com" {
    type primary;
    file "/etc/bind/zones/db.example.com";
    notify yes;
    also-notify { 203.0.113.53 key "xfr-key"; };
    allow-transfer { key "xfr-key"; };
};

3. Secondary:

include "/etc/bind/xfr-key.conf";

zone "example.com" {
    type secondary;
    file "/var/cache/bind/db.example.com";
    primaries { 198.51.100.10 key "xfr-key"; };
};

Older BIND releases use master, slave and masters instead. Run named-checkconf on both sides, rndc reload, and look for transfer of 'example.com/IN' from 198.51.100.10#53: Transfer completed in the secondary’s log.

Three checks with dig

Are both servers on the same serial?

dig @ns1.example.com example.com SOA +short
dig @ns2.example.net example.com SOA +short

The third field is the serial. Matching numbers mean the secondary is current.

Is an unauthenticated transfer refused?

dig @198.51.100.10 example.com AXFR

You want to see ; Transfer failed.. If the whole zone scrolls past instead, anyone can list your records, internal hostnames included.

Do the NS records match?

dig example.com NS +short

Every nameserver, including the new secondary, must appear here. It must also be listed in the delegation at your registrar, which the registry publishes in the parent zone.

Common secondary DNS mistakes

Most secondary problems stay invisible until the day you need the secondary. These come up again and again:

• Forgetting the serial. Edit the zone file without bumping the serial and only the primary sees the change. The secondary believes its copy is current.
• TCP 53 blocked. Zone transfers use TCP. With only UDP 53 open, the NOTIFY arrives but the transfer never completes.
• Secondary missing from the delegation. It is configured and in sync, but not listed at the registrar, so resolvers never ask it.
• Stale primary address. After a server move, primaries still points at the old IP. The secondary keeps serving until expire, then silently drops the zone.
• Clock drift. TSIG checks timestamps. If one server’s clock is off by more than a few minutes, transfers fail with BADTIME. Run NTP on both sides.

Hidden primary: keep the source out of sight

A popular pattern is the hidden primary. The primary is not listed in any NS record and only accepts connections for zone transfers. Public queries are answered only by secondaries, for example at two different anycast providers.

In a DDoS scenario this helps because nobody can target an address that is never published, while the public servers sit on large networks built to absorb load. The cost is one more server to run and monitor. How anycast strengthens those public servers is covered in anycast DNS.

When your provider does not support zone transfers

Some managed DNS services neither send nor accept AXFR. You then have two options:

• API sync. A script reads records from provider A’s API and writes them to provider B. It works, but it needs maintenance and alerting when it breaks.
• One source of truth. Keep the zone in a repository and have a deployment step push it to both providers.

So when choosing a DNS provider, ask about AXFR/IXFR with TSIG up front. The answer decides whether adding a second provider later is an afternoon or a project.

DNSSEC across two providers

The easiest route is to sign on the primary and transfer the signed zone, so the secondary serves it as-is. If each provider signs on its own, you need a multi-signer model as in RFC 8901, with both sets of keys in the zone. Most setups are fine with the first approach.

The DS record goes to your registrar, which forwards it to the registry. A registrar that supports DNSSEC handles that from the domain settings.

Add the secondary’s hostnames through your registrar’s nameserver management, then run the three checks again. If you are starting a new project, you can check whether your name is free and launch it with two DNS providers from day one. For what to do when an attack is already underway, see DDoS attack: what to do.

Step by step

1. Choose an independent secondary providerPick a DNS provider that accepts secondary zones over AXFR/IXFR with TSIG and runs on a different network from your primary.
2. Generate a TSIG keyRun tsig-keygen -a hmac-sha256 xfr-key and install the same key on both primary and secondary.
3. Allow transfers on the primaryRestrict allow-transfer to the TSIG key and add the secondary to also-notify in the zone configuration.
4. Create the secondary zoneAdd the zone at the secondary provider with the primary's IP and the key, or in BIND as type secondary with a primaries list.
5. Verify synchronisationCompare SOA serials on both servers with dig SOA +short, and confirm an AXFR without the key is refused.
6. Publish the new NS recordsAdd the secondary to the NS records in the zone and in the delegation at your registrar, and keep both lists identical.