🪵 Stub zones

$ dig @1.1.1.1 probe.isitdns.net NS

What it is#

A stub zone holds only:

• The zone's SOA
• The zone's NS records
• Any glue (A/AAAA for NS names inside the stubbed zone, in-domain in RFC 9499 section 7 terms)

That's it. When a resolver gets a query for a name inside a stub zone, it goes straight to the authoritative servers on the stub's NS list, skipping the full . → TLD → zone hierarchy walk.

It polls the master servers on the zone's SOA refresh timer to keep that NS list current, the same schedule a secondary uses; BIND clamps that interval between min-refresh-time (default 300 seconds) and max-refresh-time (default 4 weeks) for both zone types (BIND 9 ARM, min-refresh-time). NOTIFY does not update a stub: BIND's allow-notify only applies to secondary and mirror zones.

Stub zones are not defined in any RFC: "Stub zones are not a standard part of the DNS; they are a feature specific to the BIND implementation" (BIND 9 ARM, Zone Types). BIND (type stub;), Microsoft DNS (a stub zone in DNS Manager, Understanding Zone Types) and Unbound (stub-zone:, unbound.conf(5)) each implement the same idea under their own syntax.

When to use it#

• Cross-team / cross-org referrals where you want fast resolution into a peer's zone without operating as a secondary.
• Speeding up lookups into a frequently-queried external zone. Skip the recursion walk, hit the authoritative directly.
• Tracking NS changes automatically. If the target zone changes its NS list, a stub picks that up via SOA refresh: a forward zone with hard-coded forwarder IPs doesn't.

When not to use it#

• When you want to act as a secondary copy of the whole zone: use a real secondary (which transfers all records).
• When you don't want clients to talk to the authoritative servers at all: use forward instead. (A stub uses the upstream NS; a forward talks through your resolver to the upstream.)
• When you own the records: use auth.
• BIND's own docs discourage it outright: "Use of stub zones is not recommended. Proper delegation with NS records in the parent zone should be used" (BIND 9 ARM, stub zone type).

Gotchas#

• Not a copy of the data. A stub caches NS + SOA only. If the authoritative NS list goes stale, your resolver keeps querying dead servers until the next SOA refresh picks up the new one.
• You cannot stub a zone you are authoritative for (in the same view): Microsoft DNS refuses to host a stub zone on a server that is already authoritative for it (Add a Stub Zone), and BIND will not load two zones with the same name in one view.

See also#

• transfer: how stub differs from a real secondary