is it dns? / wiki ← back to the live monitor

SOA: start of authority

Required at every zone apex. Exactly one per zone. SOA holds the zone's metadata: who runs it, the serial number that drives secondary refresh, and the timers that govern zone transfer behavior.

Type number6
RFC1035
RDATAPrimary NS · admin email · serial · refresh · retry · expire · minimum

What it holds#

Seven fields, in this order on the wire:

isitdns.net.  SOA  coleman.ns.cloudflare.com.  dns.cloudflare.com.
              2409741473  10000  2400  604800  1800

Fields in order: primary NS, admin email, serial, refresh, retry, expire, minimum. The serial advances every time the zone is edited, so the live value will differ from the snapshot above.

FieldMeaning
Primary NSThe "MNAME": the master server. Secondaries refresh from this name.
Admin emailContact for the zone, encoded with . instead of @ (dns.cloudflare.com. encodes dns@cloudflare.com). A . already in the local part must be escaped: John.Smith@widget.xx becomes John\.Smith.widget.xx (RFC 1912 section 2.2).
SerialA monotonically increasing integer secondaries use to detect changes. Conventional format: YYYYMMDDNN.
RefreshHow often secondaries poll the primary for serial changes. Mostly superseded by [[transfer#The cast of characters
RetryIf a refresh fails, how long to wait before retrying.
ExpireIf the primary stays unreachable, how long before secondaries stop serving stale data.
MinimumHow long resolvers may cache negative answers (NXDOMAIN and NODATA) from this zone (RFC 2308 negative-cache TTL). See [[fundamentals#TTL: the double-edged knob

When you'll touch it#

  • Almost never directly. Managed DNS providers auto-generate the SOA from zone-level settings; in a self-hosted zone file (BIND, NSD) you write it once and afterward mostly touch only the serial.
  • When tuning negative caching: a long minimum means NXDOMAIN responses hang around in resolvers long after you add the record. Pulling minimum down before adding records that previously did not exist is a good habit.
  • When debugging zone-transfer issues between primary and secondaries: the serial mismatch is the symptom.

dig example#

dig isitdns.net SOA +short
coleman.ns.cloudflare.com. dns.cloudflare.com. 2409741473 10000 2400 604800 1800

The serial advances each time the zone is edited, so the live value will differ from the snapshot above.

nslookup shows the same fields but in a labeled layout:

nslookup -type=SOA isitdns.net 1.1.1.1
Server:         1.1.1.1
Address:        1.1.1.1#53

Non-authoritative answer:
isitdns.net
        origin = coleman.ns.cloudflare.com
        mail addr = dns.cloudflare.com
        serial = 2409741473
        refresh = 10000
        retry = 2400
        expire = 604800
        minimum = 1800

The serial in the answer is the heartbeat of zone state: if two nameservers disagree, the one whose serial is behind per RFC 1982 serial arithmetic is stale. A numerically lower serial is not always the older one. Near a 32-bit wraparound, the numerically higher value can be the stale copy.

To compare, ask each authoritative server directly:

dig @coleman.ns.cloudflare.com isitdns.net SOA +short
dig @hera.ns.cloudflare.com isitdns.net SOA +short

Both should return the same serial; a lagging server is serving a stale copy of the zone.

For an internal zone you control, query your authoritative server directly:

dig @<your-dns-server> example.internal SOA
nslookup -type=SOA example.internal <your-dns-server>

<your-dns-server> and example.internal are placeholders. Neither resolves publicly. Substitute your own authoritative server address and zone name; these commands return no answer as written.

nslookup cannot show EDNS options, DNSSEC bits, or the AD flag. Use dig for those.

DoH query (HTTPS)#

DoH is DNS-over-HTTPS. The JSON wire format uses application/dns-json (a Cloudflare/Google convention; RFC 8484 uses binary DNS-wire-format instead):

curl -s -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=isitdns.net&type=SOA' \
  | jq .Answer
[
  {
    "name": "isitdns.net",
    "type": 6,
    "TTL": 1800,
    "data": "coleman.ns.cloudflare.com. dns.cloudflare.com. 2409741473 10000 2400 604800 1800"
  }
]

nslookup cannot do DoH/DoT/DoQ. On Windows, Resolve-DnsName uses the system-configured DoH resolver when the OS is set up for encrypted DNS; there is no -DnsOverHttps parameter and it does not accept an arbitrary endpoint as -Server. To probe a specific DoH endpoint, use the curl example above.

Gotchas#

  • Serial number rollover. SOA serial is a 32-bit unsigned int governed by RFC 1982 serial-number arithmetic. Use YYYYMMDDNN (the RFC 1912 section 2.2 recommendation, good until year 4294) for predictability and you will never hit it. Use a hand-tracked counter and someday you will.
  • Long minimum bites. A zone with minimum = 86400 (a day) means an NXDOMAIN you cached this morning is still cached when you fix the record this afternoon. Lower it before making schema-style changes; raise it back later. Per RFC 2308 section 5, the actual negative cache TTL used by resolvers is min(minimum, SOA record TTL): setting minimum low while leaving the SOA record TTL at 86400 will not shorten negative caching.
  • Multiple SOAs. RFC 1035 section 5.2 says exactly one SOA RR should be present at the top of the zone. Most authoritative servers refuse to create a second. But if you import a zone file with two SOAs by accident, behavior is undefined and embarrassing.
  • Cloudflare-managed zones. Cloudflare auto-generates the SOA, but the fields (MNAME, admin email, refresh, retry, expire, minimum, and the SOA record's own TTL) are tunable per zone via the DNS settings API or account-wide via DNS zone defaults. The serial is the exception: Cloudflare manages it internally, and it is an opaque counter (2409741473 in the snapshot above), not YYYYMMDDNN.

See also#