Hidden Master vs Primary-Only: DNS Deployment Patterns

Hidden Master vs Primary-Only: DNS Deployment Patterns

Teams that run authoritative DNS face a recurring design choice: publish a primary that directly answers the world, or hide it behind secondaries and providers. Both patterns work, but they optimize for different risks, controls, and workflows. Picking the right one depends on where you want change to occur, how you distribute zone data, and how you monitor correctness over time.

Hidden master keeps your writable server off the public NS set. Secondaries—often anycasted through one or more providers—serve traffic, while the master only talks to them over authenticated transfers. Primary-only flips the emphasis: you push changes straight into the authoritative fleet that the world queries, typically via API, and rely on that platform’s internal replication. Each approach has trade-offs in exposure, portability, and operational simplicity.

We’ll map the concepts to concrete mechanisms—SOA serials, NOTIFY, IXFR/AXFR, TSIG, DNSSEC—and offer simple runbooks for monitoring and automation. The goal is practical: ship zones that stay correct, fast, and resilient under maintenance and attack.

Choosing Between Hidden Master vs. Primary-Only

In hidden master (also called hidden primary or stealth primary), the zone’s writable source of truth is not listed in the public NS records. The public NS set consists of secondaries operated by you and/or providers. Secondaries receive updates via NOTIFY from the master and fetch changes using IXFR (incremental) or AXFR (full) transfers. In primary-only, the servers in the public NS set are the ones you update directly; replication is internal to that cluster or provider, so no external transfers are required.

What “Hidden Master” Really Means

“Hidden” means the master is not in the delegation or the zone’s NS RRset, so resolvers do not query it. It still has an address reachable by secondaries and may be named in the SOA’s MNAME field, which tooling and secondaries can use, though resolution itself is driven by NS and glue. Security comes from shrinking exposure and from strict controls on who can transfer the zone. Operational benefits include staging changes on a system you fully control (versioned zones, CI, preflight linting) while letting globally distributed secondaries absorb query load and DDoS.

Control Plane vs. Data Plane

Hidden master separates the control plane (edits, signing, serial management) from the data plane (answering queries). If secondaries fail, you can add or swap providers without changing your edit workflow. If the master is down, existing secondaries keep serving until signatures or TTLs expire; your SLOs hinge on refresh/expire timers and RRSIG validity windows, not on the master’s uptime.

Primary-Only Pattern Explained

Primary-only centralizes authority in the public NS fleet. You update records via the platform’s API, UI, or dynamic DNS, and that platform replicates changes across its anycast sites. Advantages: fewer moving parts (no transfer ACLs, TSIG keys, or notify lists), fast global convergence when the provider’s backbone is optimized for it, and simpler audit on one API surface. Risks: provider concentration (an outage or routing issue at the provider directly affects your zone), and portability friction when you need to multi-home or migrate.

Design Principles for Secure, Resilient Zones

Regardless of pattern, good DNS hygiene matters more than the label. Focus on isolation of changes, authenticated distribution, and independent checks that reflect what resolvers actually see.

Authoritative Surface and Anycast Placement

Publish at least two authoritative nameservers on distinct networks and geographies. Anycast helps shed volumetric attacks and reduce latency. Hidden master users typically pair an on-prem or cloud VM master with one or more provider secondaries. Primary-only users rely on the provider’s anycast footprint; add a second provider via dual delegation if you need provider diversity.

Zone Transfers, TSIG, and ACLs

For hidden master, enable NOTIFY so secondaries learn about changes promptly. Prefer IXFR to minimize transfer size and latency, with AXFR as a fallback when deltas aren’t available. Restrict transfers with both IP-based ACLs and TSIG keys. Keep an also-notify list for all secondaries and an allow-transfer ACL scoped to their transfer source IPs (not their query anycast ranges). Log each transfer and alert on failures or repeated fallback to AXFR.

SOA Tuning and Serial Arithmetic

Use a monotonically increasing 32-bit serial per the standard serial arithmetic. A common practice is YYYYMMDDnn for traceability. Set refresh, retry, and expire with your topology in mind: short refresh (e.g., 300–600s) speeds convergence but increases transfer chatter; set expire so secondaries keep serving through planned maintenance but not so long that stale data persists after a breaking change. Monitor serial parity across all authoritative NS.

DNSSEC in Both Patterns

Hidden master with inline-signing lets you sign at the master and transfer signed zones outward, or you can delegate signing to providers that manage DNSSEC keys. Primary-only often means enabling DNSSEC in the provider and automating DS updates at the registry when supported (via CDS/CDNSKEY). Either way, watch RRSIG validity and inception times, automate KSK/ZSK rollovers, and alert when signatures near expiration. Validate that each NS serves a consistent DNSKEY set and responds to DNSSEC-enabled queries with the expected chains.

Monitoring the Zone Lifecycle

Measure correctness from the outside in. Continuously query each authoritative NS for SOA and key records, compare serials, verify NS sets match delegation, and check that A/AAAA/CNAME targets resolve end-to-end. Record latency, TCP fallback rate, truncation frequency, and SERVFAIL spikes. On signing, track RRSIG remaining lifetime and NSEC/NSEC3 coverage. For hidden master, alert on missed NOTIFY or repeated IXFR failures; for primary-only, alert on replication lag within the provider.

Simple Commands That Scale

Keep one-liners you can automate: compare serials with dig +noall +answer SOA example.com @ns1.example.net across all NS; check delegation vs authoritative with dig NS example.com +trace; verify TSIG-signed transfers with dig @master example.com AXFR +tcp -y hmac-sha256:keyname:base64secret (or -k keyfile); probe TCP on 53 with dig +tcp to ensure large DNSSEC answers succeed; sample RCODE distribution from logs to catch spikes in SERVFAIL or REFUSED.

Automation Patterns

Use a repository as the zone source of truth and a CI pipeline to lint, build, and test before publish. Hidden master flow: push → CI lints (syntax, CNAME loops, dangling records) → bump serial → rndc reload → NOTIFY fan-out → verify serial parity and record availability. Primary-only flow: push → CI calls provider API → verify via out-of-band queries against each NS → rollback if probes fail. Gate deploys on health signals, not just API success, and always verify what resolvers would see.

When to Use Which

Pick hidden master when you want tight control over zone generation, need to multi-home across providers using standard transfers, or must minimize public exposure of your edit surface. It’s also a clean fit when you require DNSSEC signing workflows the provider doesn’t support. Choose primary-only when you prefer provider-managed replication, need rapid converged updates with low operational effort, or your platform forbids inbound transfers. Many teams adopt a hybrid: a hidden master feeding Provider A as secondary and a second path into Provider B’s primary-only API for dual delegation.

Failure and Recovery Characteristics

Hidden master can ride through master outages as long as secondaries remain healthy and signatures/TTL haven’t expired; risk concentrates in transfer failures or stale data if expire is mis-tuned. Primary-only’s mean-time-to-change is often excellent, but a provider’s control plane incident can block updates while the data plane stays healthy; a data plane incident impacts resolution directly. Dual-provider delegation reduces both patterns’ blast radius.

Security Considerations That Actually Matter

Don’t treat “hidden” as secrecy. Assume the master can be discovered via logs or SOA MNAME. Real controls are patches, locked-down recursion (off), no open transfers, TSIG on transfers/NOTIFY, minimal responses, response rate limiting if your software supports it, TCP/53 open per transport requirements, and strict egress from the master. For primary-only, rotate provider API tokens, use scoped roles, and guard automation runners that hold credentials.

A Minimal Checklist

Publish two or more NS on diverse networks; confirm glue at the parent; keep serials monotonic; set sane SOA timers; enable NOTIFY and prefer IXFR (hidden master); sign zones and monitor RRSIG lifetimes; alert on serial skew and SERVFAIL; validate both UDP and TCP; test changes from multiple vantage points; rehearse provider-fail and master-fail drills.

Hidden Master vs. Primary-Only DNS (FAQ)

It reduces the attack surface by removing the writable server from the public NS set, but it’s not secrecy-based security; you still need patched software, strict transfer ACLs, TSIG on IXFR/AXFR, and closed recursion.

Query each NS for SOA/NS and compare results; an online DNS Lookup Tool helps you check delegation, authoritative answers, and serials from multiple vantage points.

Anycast improves reachability, but provider concentration remains; many teams add dual delegation to a second platform or run a hidden master feeding an alternate secondary path for independence.

Compare SOA serials across all authoritative NS, then spot-check key records; if serials drift or IXFR falls back to AXFR repeatedly, investigate transfer logs and NOTIFY delivery.

Use multiple resolvers and vantage points to query A and AAAA records; a one-stop Domain to IP checker can show current targets and reveal propagation lag.

Yes; publish AAAA glue where possible and ensure each NS listens on v6; you can confirm client reachability with an IPv6 Test from different networks.

Resolvers ignore MNAME for resolution; it’s primarily administrative. Secondaries and tooling may use it by default, but many deployments override it with explicit masters settings.

The master sends NOTIFY to tell secondaries a serial is newer; each secondary checks SOA, requests IXFR if possible, and falls back to AXFR if it lacks a delta or journals are missing.