Zones and delegation
SOA records and authority
Read the Start of Authority record as zone metadata rather than treating it as the address of a service.
Every zone starts with an SOA record. SOA stands for Start of Authority. It doesn’t point to any service. It’s metadata about the zone itself.
What’s inside
Let’s look at one:
dig +noall +answer SOA flaviocopes.com
You’ll get one line with several fields. In order:
- the primary nameserver, a field traditionally called
MNAME - the responsible party’s email, with the first dot standing in for
@ - a serial number that identifies this version of the zone
- refresh, retry, and expire timers, used by secondary servers
- a final value used for negative caching
The primary nameserver field is DNS bookkeeping. It’s not your web server. On a managed provider like Cloudflare it may not even describe the internal source of truth. Don’t read too much into it.
The serial
The serial should change every time the zone content changes. That’s how secondary servers notice there’s a newer version to fetch. Managed providers bump it for you.
This makes the serial a useful clue. When two authoritative servers give you different answers, compare their serials:
authoritative_server=$(dig NS flaviocopes.com +short | head -n 1)
dig @"$authoritative_server" +noall +answer SOA flaviocopes.com
Run that against each listed nameserver. A server with a lower serial hasn’t picked up the latest change yet.
The SOA and negative answers
The SOA shows up in one more place: the authority section of a negative answer.
When you ask for a name that doesn’t exist, or for a record type the name doesn’t have, the authoritative server includes the zone’s SOA in the response. Resolvers use its TTL and that last field to decide how long to remember “this doesn’t exist”.
That’s why a record you created two minutes ago can still be missing for some people. Their resolver cached the negative answer, and the SOA told it how long to keep it.
Leave the timers alone
My advice is to not touch the SOA timers unless you know why. They control how secondaries sync and how long negative answers stick around. Both affect availability. Managed providers set them on purpose and often don’t let you edit them at all.
Try this: query the SOA through your normal resolver, then directly from two of the zone’s authoritative servers. Find the primary field, the serial, and the negative-cache value. Do the serials match?
Lesson completed