📜 Authoritative zones

An authoritative zone is one your server owns. Queries for names inside it come back with aa=1 and the data you published. This is the default zone type: the one you mean when you say "I have a zone."

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.

Watch it live against one of this site's own authoritative servers (output trimmed to the interesting part):

dig @coleman.ns.cloudflare.com example.isitdns.net A

;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; ANSWER SECTION:
example.isitdns.net.	300	IN	A	192.0.2.1

aa is set and ra is not. The WARNING is dig being honest: it asks for recursion by default (that's the rd in the flags), the authoritative server declines; add +norec to stop asking. Note the TTL too: an authoritative server always serves the record's full TTL (300 here), never a counted-down cache value.

Common patterns:

Forward auth zone: example.com, lab.example, internal.corp. 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 a delegation from example.com). Useful when one team owns the parent, another the sub, and they want clean separation. This works as-is for internal resolvers pointed at the server; to be reachable from the public Internet, the parent zone still needs a delegation for the sub-name.

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.

Typical pattern: split-horizon (a.k.a. DNS views)#

Split-horizon DNS, also called DNS views, is when the same zone name is authoritative in two (or more) places at once, and the server picks which copy to serve based on who's asking. The canonical use: internal clients see RFC 1918 addresses, external clients see public ones, all under the same hostname. Full treatment on the split-horizon page.

A common deployment:

Zone	Who serves it	Why
`example.com` (public view)	Managed DNS provider or self-hosted public auth	What the world sees
`example.com` (internal view)	On-LAN authoritative server	Returns internal addresses to internal clients
`10.10.in-addr.arpa`	Internal authoritative	PTRs for the internal `10.10.0.0/16`
`0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa`	Internal authoritative	PTRs for the IPv6 prefix (`2001:db8::/64`)

How the server picks a view#

An ACL (Access Control List, typically a list of source IP ranges) maps clients to views. When a query arrives, the server matches the client's source IP against each view's ACL in order, picks the first match, and answers from that view's copy of the zone.

The smallest working example, in BIND-flavored syntax:

acl "internal-clients" {
    10.10.0.0/16;                  // anyone on the corporate LAN
};

view "internal" {
    match-clients { internal-clients; };
    zone "example.com" {
        type primary;
        // "type master" is the legacy spelling; "primary" is its synonym since BIND 9.14
        file "zones/internal/example.com";   // returns 10.10.0.5
    };
};

view "external" {
    match-clients { any; };                  // catch-all (everyone else)
    zone "example.com" {
        type primary;
        file "zones/external/example.com";   // returns 203.0.113.5
    };
};

The two zone files share the apex and structure; only the records differ (the SOA and NS records every zone file also needs are omitted here for brevity):

;; zones/internal/example.com
@    IN  A   10.10.0.5

;; zones/external/example.com
@    IN  A   203.0.113.5

Result: dig example.com A from 10.10.0.42 returns 10.10.0.5; the same query from 203.0.113.1 returns 203.0.113.5. Same name, same record type, two truthful answers. That is DNS views in action. See split-horizon for deployment patterns, troubleshooting, and the security trade-offs.

Views are a server feature, not a protocol feature. BIND has them natively; servers without a view concept get the same effect by running one instance per audience and steering clients at the network layer. Managed DNS providers do it through geo or IP-based steering rules in their dashboards or APIs.

SOA: the metadata at the apex#

Every auth zone has exactly one SOA record at the apex. SOA fields drive secondary refresh, negative caching, and transfer behavior. Managed DNS providers maintain the SOA for you from zone-level settings; on a self-hosted server it is a literal record at the top of the zone file. Full coverage on soa.

Allow / restrict transfers#

A well-configured authoritative server refuses zone transfers to anyone it does not know. That is now also the shipped default in BIND 9.20+, which disables outgoing transfers entirely unless an allow-transfer ACL grants them; older BIND versions allowed transfers to any host unless told otherwise (BIND 9.20.0 release notes). Opening one to a specific peer (a secondary, a monitoring host, a dig AXFR test) means adding the peer's IP, a TSIG key, or both to an allow-transfer ACL or equivalent. Every common DNS server exposes this; the exact syntax varies. Managed DNS providers handle secondaries through a dashboard pairing flow rather than open-Internet AXFR.

How transfers actually work, AXFR, IXFR, SOA increments, and what shows up in syslog, is the whole transfer page.

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. That's the split-horizon pattern: same name, different answers per source-IP rule.
Apex CNAME forbidden. RFC 1034 §3.6.2 and RFC 2181 §10.1: see CNAME: canonical name (alias).
SOA serial bumps drive secondaries. Every commit should bump the serial. Hand-editing the serial on a primary while secondaries are subscribed is a recipe for "everyone has a different copy."
Reverse zones are ordinary zones with special names. To the protocol, a reverse zone is just an auth zone under in-addr.arpa or ip6.arpa. In management UIs that treat forward and reverse as separate zone types, creating the name as the wrong type leaves you a forward zone with an odd-looking name and none of the reverse-zone conveniences, such as automatic PTR handling. Pick the reverse type explicitly.
Deleting an auth zone is destructive. The records inside go with it. Export first if you want a paper trail.