Support Library
Hidden Primary Design Patterns
A hidden primary feeds public secondaries by zone transfer and never answers the public. How to set it up, secure it and monitor it.
The short answer
In a hidden primary design, the server where you edit the zone is not listed in the zone's NS records and does not answer the public. It only sends the zone, by zone transfer, to a set of public secondaries, and those secondaries are what the delegation lists and what resolvers query. The primary can then sit behind a firewall, stay small, and be changed or rebuilt without users noticing, while the public-facing load and attacks land on the secondaries.
How it fits together
- You change the zone on the hidden primary, by hand, through IPAM, or through automation. If the zone is DNSSEC-signed, the primary or a signer next to it signs it.
- The primary increments the SOA serial and sends a NOTIFY to each secondary (RFC 1996).
- Each secondary checks the serial and pulls the changes by IXFR (incremental) or AXFR (full), ideally authenticated with TSIG keys.
- Resolvers only ever query the secondaries listed in the NS records.
The secondaries are often one or two managed DNS providers that accept zone transfers, which also gives you multiple providers serving identical data.
Getting it right
| Area | What to do |
|---|---|
| MNAME in the SOA | Normally the primary's name, which reveals it. Using a public secondary name instead requires explicit update, transfer and NOTIFY configuration: MNAME guides dynamic-update discovery and is excluded from the default NS-based NOTIFY set. It is not used for ordinary lookups. |
| NS records | List only the public secondaries, both in the parent delegation and in the zone itself |
| Transfers | Allow AXFR and IXFR only to the secondaries' addresses, and require TSIG |
| Notifies | Send NOTIFY to every secondary, including ones not in the NS set, with also-notify or the equivalent |
| SOA EXPIRE | Long enough, two to four weeks, that secondaries keep serving through a long primary outage |
| DNSSEC | Signatures are made on the primary side, so a stopped signer leads to expired signatures on every secondary. Monitor RRSIG expiry dates. |
| Monitoring | Alert when any secondary's SOA serial falls behind the primary's |
Checking a hidden primary setup
| Command | What you want to see |
|---|---|
| dig +nssearch example.com | The same serial on every public server |
| dig +norecurse @primary.internal example.com SOA, from inside | The serial the secondaries should be on |
| dig @ns1.example.net example.com AXFR, from outside | Transfer refused: secondaries should not hand the zone to anyone |
| dig +dnssec @ns1.example.net example.com SOA | An RRSIG whose expiry date is comfortably in the future |
How DNS Panopticon helps
Domain Visualizer shows the public side of the design: the NS records resolvers see, the SOA record (including the MNAME), and whether DNSSEC validates. It does not try zone transfers or compare serials between servers. Zone Analyzer can read a zone export from the primary so you can review its records locally.