A hidden primary DNS server supplies a zone to secondary servers while staying out of the zone's public NS records. DNS links names to records, such as IP addresses, and a zone groups records managed together for part of the domain namespace. NS records name the zone's authoritative servers, which answer from their own stored copies.

This arrangement separates the source that distributes the zone from the servers contacted by resolvers, the programs that fetch DNS answers for clients. It can keep an administrative system away from ordinary public DNS traffic, although it does not make the zone's published records private.

Each public secondary must receive and load an update before it can answer with the changed records. Operators therefore need both a working transfer path and a way to detect failed updates.

How the Hidden Primary Supplies a Zone

In a common hidden primary setup, the primary loads records from a local source, such as a zone file or an authorized update process. Its secondaries obtain their copies through zone transfers, which copy DNS records between servers. Both roles provide authoritative answers for the zone; primary and secondary do not describe different levels of authority.

For a delegated zone, the hidden primary is omitted from the parent zone's delegation, the NS records that direct queries to the child zone's servers. It is also absent from the NS records at the zone's apex, the name where that zone begins. The published servers need usable addresses and must answer authoritatively for the zone.

Each secondary must be able to reach the hidden primary to transfer the zone. That endpoint might sit behind a firewall or on a private connection. Simply removing its name from NS records does not create the required network access or restrict the access that already exists.

Choose a clear owner for record changes. If teams edit copies independently, the primary distributes the copy it holds; it does not merge the competing edits. Before using that arrangement, establish where authorized edits are made and how the accepted version reaches every public server.

Public Secondaries Answer from Their Own Copies

For example, suppose example.com has two public authoritative servers named ns1.example.net and ns2.example.net. An internal primary maintains the zone, while both public servers obtain copies from it. The names describe a hypothetical arrangement, not a working service.

When a resolver follows the delegation for example.com, it reaches the public servers. Each secondary answers using the zone it has loaded locally. It does not contact the hidden primary for every visitor's query.

The records reach clients in three stages:

  1. The administrator or authorized update service changes the records at the source.
  2. The secondaries retrieve and load an updated version of the zone.
  3. The public authoritative service answers queries using those loaded copies.

Public secondaries do not become recursive resolvers merely because they receive data from another server. A recursive resolver follows up DNS queries for a client, including requests outside the zones stored locally. That service can exist in the same software as authoritative DNS, but it needs its own access controls.

Check every published server after a change. One secondary might have loaded the new record while another still holds the previous version. A successful answer from one address does not establish that all public copies have caught up.

How Changes Travel to the Secondaries

The zone's SOA (Start of Authority) record stores its serial number and the timers used by secondaries. The serial identifies the zone's version for transfer purposes, and changes must have a value that secondaries recognize as newer. DNS serial comparisons account for the number wrapping around its 32-bit range, so they are not ordinary comparisons of ever-increasing integers. Editing record text without advancing the serial can leave the public copies behind.

A primary can send DNS NOTIFY messages when an update is available. A NOTIFY is a prompt to check for a change, not a packet containing the replacement zone. An acknowledgment also does not prove that the receiver has loaded the update.

The secondary checks its configured source for the SOA serial. When it discovers a newer version, it obtains the necessary zone data and loads the result. AXFR transfers a complete zone, while IXFR can transfer the changes between versions.

Periodic refresh checks let a secondary discover changes even if a notification does not arrive. A failed check leads to another attempt according to the retry timer. These scheduled checks continue alongside notifications; a successful NOTIFY exchange does not establish that later updates will arrive.

Transfer sources and notification targets need to match the actual deployment. A hidden primary cannot be found through the public NS list that deliberately omits it. The secondary's configuration must tell it where to obtain its copy.

Give the Transfer Path Its Own Access Controls

Restrict access to the hidden server according to its actual clients and tasks. The secondary servers need the transfer service; an administration system might need a separate update or management interface. Those permissions need not be identical.

Use transfer authorization appropriate to the endpoints. TSIG uses a shared secret key to authenticate DNS messages between configured peers. Protect that secret and assign permissions deliberately, rather than treating any request from a familiar network as an authorized zone transfer.

Firewall rules and DNS server permissions must agree about the traffic they permit. Address translation can change the source address seen by the server. An unexpected source address can then make a legitimate secondary fail an address-based rule. Conversely, an overly broad rule can expose the service to clients that were never intended to receive zone copies.

Keep management credentials separate from ordinary query access. Public nameservers can answer the zone without giving every system that reaches them permission to alter its records. Management interfaces, update services, backups, and private signing keys require their own controls.

Review the public servers' services as well. Limiting access to the primary does not justify offering unrestricted recursion on a public authoritative server. The query service should expose the capabilities its intended users need.

How Long Secondaries Can Serve without the Primary

If the hidden primary becomes unreachable, the secondaries do not immediately lose their loaded zones. They can continue answering from those copies while they attempt to contact a source again. New edits, however, cannot reach them through the failed path.

The SOA refresh timer sets the interval between routine checks, and the retry timer sets the interval after a failed check. The expire timer limits how long a secondary may serve the zone without a successful refresh. When that period runs out, the secondary must stop treating its copy as authoritative.

A record's TTL has a different purpose: it controls the lifetime of a cached record at a resolver. It does not determine how long a secondary may keep serving an unrefreshed zone. Lowering record TTLs cannot repair a broken transfer path.

DNSSEC adds digital signatures that validating resolvers check against trusted keys. In a signed zone, those signatures can expire before the SOA expire timer runs out. A secondary might still be serving its loaded zone while validating resolvers can no longer accept answers whose signatures have expired.

The signer, the software that generates those signatures, may run on the hidden primary or in a separate publishing process. Either way, monitor the supply of fresh signatures as well as the availability of the transfer source. A source outage is operationally different from an outage in every public server, but it can eventually affect public answers.

Verify Updates on Every Public Server

After an intended change, inspect the primary's loaded version and the versions reported by each public secondary. Then query the changed record at each public server.

Keep transfer failures visible. Authentication failures, rejected sources, unreachable endpoints, and zone loading errors require different fixes. The relevant logs should identify which source and destination were involved, rather than leaving the operator with a generic report that DNS is unavailable.

Check that the following conditions are met:

  • The intended zone is loaded at the source.
  • Every public secondary can retrieve and load updates from its configured source.
  • The changed record is present in each public copy.
  • The zone and its DNSSEC signatures, if present, are not close to expiring.

Distinguish a valid answer that a name does not exist from a refusal, a server failure, or a query that never receives a response. Those observations point to different conditions. An absent record should be evaluated against the intended zone data before it is described as a transfer outage.

Back up the primary's zone data and configuration, and keep a record of authorized changes. A public secondary's current copy may help with investigation, but it should not be the only record of intended configuration and authorized changes. Before restoring the primary to service, confirm which version it will distribute and how the secondaries will recognize that version.

What a Hidden Primary Does Not Hide

Hidden means unpublished as a public nameserver, not necessarily undiscoverable. The SOA record can contain a name associated with the primary, and other information can reveal an address or administrative relationship. Protect the transfer endpoint even when its name is absent from the NS records.

Records deliberately published through the secondaries remain public DNS data. Removing the primary from the delegation does not conceal hostnames or addresses that those servers are meant to return.

The public secondaries also remain exposed to public queries and the availability risks of operating that service. Keeping the source away from that traffic can reduce one area of exposure, but it does not prevent attacks against the public servers or mistakes in authorized changes.