Zones

📜 Authoritative zones

Asks an authoritative server for a name it is authoritative for.

$ dig -4 @coleman.ns.cloudflare.com example.isitdns.net A

; <<>> DiG 9.20.11-0ubuntu0.2-Ubuntu <<>> -4 @coleman.ns.cloudflare.com example.isitdns.net A

; (3 servers found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1422

;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 1232

;; QUESTION SECTION:

;example.isitdns.net. IN A

;; ANSWER SECTION:

example.isitdns.net. 300 IN A 192.0.2.1

;; Query time: 32 msec

;; SERVER: 108.162.195.64#53(coleman.ns.cloudflare.com) (UDP)

;; WHEN: Mon Sep 14 17:52:09 CDT 2026

;; MSG SIZE rcvd: 64

GO aa on the flags line and the record from the zone file

NO GO no aa, which means that server is not an authority for this name

what each part of this output means →

What it is#

An auth zone holds the actual resource records. The server doesn't ask anyone else; it looks in its own data and answers. The aa (authoritative answer) flag in the response header is set (RFC 1035 §4.1.1), and because a pure authoritative server offers no recursion, ra stays clear. See anatomy-of-a-query for the full flag walk-through.

Common patterns:

Forward auth zone: example.com. Holds A, AAAA, MX, CNAME, TXT, etc.
Reverse auth zone: 100.51.198.in-addr.arpa. Holds PTR. See reverse-dns.
Sub-zone: dev.example.com standalone, not delegated from example.com. Reachable from internal resolvers pointed at the server as-is; needs a delegation from the parent to be reachable from the public Internet.

When to use it#

Always: as the default zone type for anything you publish. If you control the records, this is the zone.

When not to use it#

When you don't own the records: use forward (proxy) or delegations (point downstream).
When you only need NS-pointer caching for someone else's zone: use stub.

Gotchas#

Two views, one zone, two answers. If your server supports views, the same fqdn can exist as an auth zone in each, with different records depending on who's asking. Full treatment: split-horizon.
Apex CNAME forbidden. RFC 1034 §3.6.2 and RFC 2181 §10.1: see CNAME: canonical name (alias).
The SOA serial drives secondaries. A SOA serial that doesn't advance means subscribed secondaries never pull the change (RFC 1996); a numerically lower serial isn't always the older one near a 32-bit wraparound (RFC 1982).
Zone transfers are deny-by-default in current BIND. BIND 9.20+ refuses AXFR to everyone until an allow-transfer ACL grants it; 9.18 and earlier defaulted open (BIND 9.20.0 release notes). See transfer.
Reverse zones are ordinary zones with special names. A reverse zone is an auth zone under in-addr.arpa or ip6.arpa, nothing more. Some management UIs treat forward and reverse as separate zone types; pick the reverse type explicitly or you get a forward zone with an odd-looking name and no automatic PTR handling.
TTL is never counted down. An authoritative answer carries the record's full configured TTL; only a resolver's cached copy counts it down. A full TTL on every answer is one sign you're talking to the authority, not a cache.
Deleting an auth zone is destructive. The records inside go with it. Export first if you want a paper trail.