ClueDNSSearch

record · intermediate

SOA record reference

Understand DNS SOA zone identity, serial and timer fields, negative caching, owner rules, provider behavior, and authoritative verification.

Published
Jul 28, 2026
Last verified
Review by
Risk
read-only
Provider
Provider-neutral

An SOA record marks the start of a zone of authority and carries operational fields for the zone. It helps identify authoritative state and negative-cache timing; it does not identify every authoritative server or prove that they serve the same zone version.

Purpose and type code

IANA registers SOA as type code 6 [1]. RFC 1035 defines one SOA at the top of each zone and specifies its seven RDATA fields [2].

The fields are:

  • MNAME: domain name of the zone’s source or primary server in the protocol model;
  • RNAME: mailbox of the responsible person, encoded as a domain name;
  • SERIAL: unsigned 32-bit zone version value;
  • REFRESH: secondary refresh interval;
  • RETRY: secondary retry interval after failure;
  • EXPIRE: time after which secondary data is no longer authoritative when it cannot refresh; and
  • MINIMUM: field used by the current negative-caching rules.

Managed DNS providers can generate or control some fields. Do not assume the displayed MNAME is the only writable server or that the serial is a date unless the operator documents that convention.

Presentation format

example.com.  3600  IN  SOA  ns1.example.net. hostmaster.example.com. (
  2026072801  ; serial
  7200        ; refresh
  900         ; retry
  1209600     ; expire
  300         ; minimum
)

The first dot in hostmaster.example.com. represents the mailbox separator in zone-file presentation; the example corresponds conceptually to hostmaster@example.com. Escaped dots can represent literal dots in the local part. It is not a TXT string or a mail-routing address.

Parentheses and comments are zone-file presentation conveniences. A DNS response carries the field values, not those comments.

Owner-name and coexistence rules

The SOA owner is the zone apex. It normally coexists there with the child zone’s authoritative NS RRset and other apex data. Because an apex requires SOA and NS, it cannot be a standard CNAME owner.

A parent zone’s SOA describes the parent, not a delegated child. When checking example.com, make sure the responding server is authoritative for example.com rather than returning the SOA of com in a referral or negative response.

Each authoritative view or split-horizon zone can have a different SOA. Label the network and server used for every observation.

Caching and changes

Resolvers can cache the SOA RRset by its TTL. Secondary authoritative servers use the serial and transfer timers according to their implementation and configuration. A larger serial usually indicates a newer version within the same serial arithmetic, but formatting conventions alone do not prove freshness.

RFC 2308 defines negative caching and limits the negative TTL using the SOA included in the authoritative negative response [3]. Adding a previously absent name does not immediately remove negative answers already cached.

Changing SOA timers after an incident does not shorten lifetimes that were already learned or repair inconsistent authoritative data.

Security and operational limits

SOA is public operational metadata, not a secret or access-control mechanism. The RNAME field can expose a contact-like value, so use the zone operator’s approved role address rather than personal data.

An equal serial across servers is useful evidence but does not prove every RRset is identical. A different serial can be expected during a controlled load window, but unexplained differences require provider investigation before another change.

DNSSEC can authenticate a signed SOA RRset. It does not make the timers appropriate, prove zone transfers succeed, or encrypt the response.

Verify

Use the DNS Lookup pathway to inspect SOA through named resolvers, then query every intended authority directly with recursion disabled. Capture:

  1. server, authoritative flag, owner, and class;
  2. all seven RDATA fields;
  3. SOA TTL and observation time;
  4. serial agreement across authorities;
  5. the SOA included with a representative authoritative negative answer; and
  6. whether the observed zone and network view are the intended ones.

Do not use one recursive SOA answer as proof that all authoritative servers have loaded the same zone.

Next step

Continue to the MX record reference for mail routing, or use Diagnose an NXDOMAIN response when the SOA appears in negative-answer evidence.