The most surprising thing about DNS SOA records is that they don’t actually define your zone’s authority, they just declare it and provide a mechanism for propagating changes.
Let’s see this in action. Imagine you have a zone, example.com, and you need to delegate a subdomain, app.example.com, to a new set of name servers. You’d start by updating your authoritative name server for example.com. On that server, you’d have a zone file that looks something like this:
$ORIGIN example.com.
@ IN SOA ns1.example.com. admin.example.com. (
2023102701 ; Serial
3600 ; Refresh
1800 ; Retry
604800 ; Expire
86400 ; Minimum TTL
)
IN NS ns1.example.com.
IN NS ns2.example.com.
ns1 IN A 192.0.2.1
ns2 IN A 192.0.2.2
app IN NS ns-app.example.com.
The SOA (Start of Authority) record is the first record in any DNS zone file. It tells other DNS servers where to get authoritative information for this zone and how to keep their copies up to date.
ns1.example.com.: This is the primary name server for theexample.comzone. It’s the authoritative source.admin.example.com.: This is the email address of the zone administrator, with the@symbol replaced by a dot. So,admin.example.combecomesadmin@example.com.2023102701: This is the serial number. It’s a crucial component for zone transfers.3600: This is the refresh interval. Secondary name servers will query the primary server for updates after this many seconds (1 hour).1800: This is the retry interval. If a secondary server can’t reach the primary server during a refresh, it will retry after this many seconds (30 minutes).604800: This is the expire time. If a secondary server can’t reach the primary server for this duration (7 days), it will stop serving the zone data.86400: This is the minimum TTL (Time To Live). This value is used for negative responses (e.g., when a record doesn’t exist) and is also the default TTL for records if not explicitly set.
Now, when you add the app IN NS ns-app.example.com. line, you’re telling DNS resolvers that for any query related to app.example.com, they should ask ns-app.example.com. But this delegation only works if ns-app.example.com also has the correct SOA record for app.example.com and its own set of NS records.
The serial number is the key to how DNS replication works. When a secondary name server checks in with the primary after the refresh interval, it queries for the SOA record of the zone. If the serial number on the primary is higher than the serial number the secondary has cached, the secondary initiates a zone transfer (AXFR or IXFR) to get the updated zone data. This ensures that changes you make on your primary authoritative server eventually propagate to all secondary servers.
Most people think the SOA record enforces authority, but it’s more of a negotiation for replication. The actual authority is established by the NS records that point to your name servers, and the SOA record is the traffic cop for keeping those distributed copies in sync. When you update a record, you increment the serial number. This is the signal that a change has occurred and needs to be pushed out. A common mistake is forgetting to increment the serial number after making a change; the zone transfer simply won’t happen.
The next concept you’ll run into is understanding how different types of DNS queries, like recursive vs. iterative, interact with SOA records and zone transfers.