Authoritative DNS

Authoritative-only DNS configuration. Master/slave replication, SOA timer design, delegation, and VyOS dual-BIND HA.

What Authoritative Means

An authoritative DNS server holds the original zone data. It does not cache answers from other servers — it is the source. When dig shows the aa (Authoritative Answer) flag, the response came from the zone owner, not a cache.

Configuring an Authoritative-Only Server

Disable recursion — serve your zones and nothing else
options {
    recursion no;
    allow-query { any; };
};

An authoritative-only server answers queries for its own zones and returns REFUSED for everything else. This is the correct posture for public-facing DNS.

Minimal named.conf for authoritative service
options {
    directory "/var/named";
    recursion no;
    allow-transfer { none; };
    listen-on port 53 { 10.50.1.90; };
};

zone "inside.domusdigitalis.dev" IN {
    type master;
    file "inside.domusdigitalis.dev.zone";
    allow-transfer { 10.50.1.91; };
};

zone "1.50.10.in-addr.arpa" IN {
    type master;
    file "10.50.1.rev";
    allow-transfer { 10.50.1.91; };
};

Global allow-transfer { none; } denies transfers by default. Per-zone overrides grant access only to authorized slaves.

Testing Authoritative Responses

Verify the aa flag — confirm authoritative answer
dig @10.50.1.90 inside.domusdigitalis.dev SOA | grep -i "flags"

Look for aa in the flags line. If absent, the server is returning a cached or referred answer — not authoritative.

Query with +norecurse — what does this server actually know?
dig +norecurse @10.50.1.90 inside.domusdigitalis.dev A

Forces the server to answer only from its own data. A REFUSED or empty answer means it is not authoritative for that zone.

Compare authoritative vs recursive response
diff <(dig +norecurse @10.50.1.90 inside.domusdigitalis.dev A +short) \
     <(dig @10.50.1.90 inside.domusdigitalis.dev A +short)

If both return the same result, the server is authoritative. If only the recursive query works, you are hitting a caching resolver.

Master-Slave (Primary-Secondary) Architecture

VyOS dual-BIND HA — master on vyos-01, slave on vyos-02
# On master (10.50.1.2)
zone "inside.domusdigitalis.dev" IN {
    type master;
    file "inside.domusdigitalis.dev.zone";
    allow-transfer { 10.50.1.3; };
    also-notify { 10.50.1.3; };
};

# On slave (10.50.1.3)
zone "inside.domusdigitalis.dev" IN {
    type slave;
    masters { 10.50.1.2; };
    file "slaves/inside.domusdigitalis.dev.zone";
};

also-notify sends NOTIFY messages to the slave immediately on zone changes — don’t wait for the SOA refresh timer. The slave checks the serial and pulls a transfer if it’s behind.

Verify replication — compare serials across servers
dig @10.50.1.2 inside.domusdigitalis.dev SOA +short | awk '{print $3}'
dig @10.50.1.3 inside.domusdigitalis.dev SOA +short | awk '{print $3}'

Both should return the same serial. A mismatch means the slave hasn’t completed a zone transfer.

Force immediate slave sync
sudo rndc retransfer inside.domusdigitalis.dev

Run on the slave. Forces it to pull the zone from master immediately regardless of SOA timers.

SOA Record Design

SOA timer recommendations for internal authoritative zones
@ IN SOA ns1.inside.domusdigitalis.dev. admin.domusdigitalis.dev. (
    2026041001  ; Serial — YYYYMMDDNN, increment on every edit
    3600        ; Refresh — slave checks master every 1h
    900         ; Retry — if refresh fails, retry every 15m
    604800      ; Expire — slave stops answering after 7d without master
    86400       ; Negative TTL — cache NXDOMAIN for 1d
)

The serial format YYYYMMDDNN supports 100 changes per day. Never decrease the serial — slaves will ignore the update.

Delegation

Delegate a subdomain to another nameserver
lab    IN NS  ns1.lab.example.com.
ns1.lab IN A  10.50.2.10

The glue record (A record for ns1.lab) is required when the NS target is within the delegated zone. Without it, resolvers cannot reach the delegated nameserver.

See Also