SOA record lookup

What the SOA record contains

Every DNS zone, meaning the set of records a domain's nameservers manage, has exactly one SOA (start of authority) record. It names the zone's primary server, gives a contact for its administrator and carries a serial number plus four timers. These tell secondary servers, which keep copies of the zone, and caches how to behave. Most people never touch it. It matters when records seem stuck, when secondary servers fall out of sync, and when a brand-new name returns NXDOMAIN for longer than you expect.

How to read it

1. Enter the domainThe SOA belongs to the zone, so ask for the zone apex, such as example.com. For a subdomain that is not a zone of its own, the answer is empty and the enclosing zone's SOA appears under authority.
2. Ask an authoritative serverChoose the authoritative option under More options to read the SOA straight from the zone's own nameserver, with no cache in between.
3. Compare serials across nameserversA healthy zone returns the same serial from every nameserver. If one is lower, it is missing recent changes. Wait for its refresh interval, or ask your provider to trigger a zone transfer. The command in the last section checks all of them at once.

Reading the serial and timers

• Serial formats. Many zones use YYYYMMDDnn. For example, 2026102401 is the first change on 24 October 2026. Others use a Unix timestamp or a plain counter. Only the order matters, but serial comparison wraps around at 2^32 (RFC 1982).
• The serial did not change after an edit. Some managed DNS services do not use the serial at all, and others bump it in batches. If your provider uses zone transfers, the serial must go up for secondaries to pick up changes.
• Minimum is the negative-caching time. Under RFC 2308, resolvers remember an NXDOMAIN or NODATA answer for the smaller of the SOA record's own TTL and this value. If you query a name before you create it, you may keep seeing “does not exist” for that long.
• Refresh and retry control how quickly secondaries catch up. Providers that push changes with NOTIFY make them less important.
• Expire should be much larger than refresh and retry, usually weeks, so a primary outage does not take the zone down.

Common problems

• A new record still returns NXDOMAIN. The earlier miss was cached for the SOA minimum. Wait it out, or ask the resolver operator to flush it.
• Secondary servers return old data. Their serial is lower. Check zone transfer permissions (AXFR and IXFR), the NOTIFY setting and any firewalls between the servers.
• The serial went backwards. Restoring an old zone file or editing it by hand can lower it. Secondaries ignore a lower serial, so they stay stale until it passes the old value.
• An odd admin address. A dot inside the local part must be escaped with a backslash. Many tools show it wrongly.
• Extreme timers. A negative-cache time of a week, or a refresh of a few seconds, suggests a misconfiguration.

How the lookup works and the standards

LookupOwl asks for type SOA (code 6) from the resolver you choose or from an authoritative nameserver and decodes the fields. The record is defined in RFC 1035, serial comparison in RFC 1982, the negative-caching role of the last field in RFC 2308, and operational advice in RFC 1912.

dig +short SOA example.com
# Compare serials across all authoritative servers
for ns in $(dig +short NS example.com); do dig +short @$ns SOA example.com; done

To find the servers to compare, run an NS lookup. The DNS propagation checker can also compare the SOA answer of public resolvers with the authoritative one.