The Start of Authority Record

A record about the zone, not about a host

The SOA record, short for start of authority, is a zone's metadata about itself. There is exactly one per zone, it sits at the apex alongside the zone's NS records, and it points at no website and no service.

Its seven fields are a mixed set. Two are names, one is a version number, three are timers that govern how a secondary nameserver keeps its copy of a zone in step with the primary, and the last decides how long the internet remembers that something in your zone does not exist.

For an owner on managed DNS, six of the seven are inert. The provider generates them, replicates the zone by its own means, and nothing you type into those fields changes what anyone observes. The seventh can hold an outage open after you have already fixed it.

The two names at the front

MNAME is the first field: the nameserver that was the original or primary source of data for the zone. In a classic primary-and-secondary setup it names the server the secondaries pull from. On a managed anycast platform it names one of the provider's servers because the format requires a name in that position, and it carries little meaning for you.

RNAME is the second, and it is the field people misread, because it is an email address written as a domain name. The record format has no room for an @ sign, so the @ becomes a dot. hostmaster.example.com in an SOA record means [email protected]. RFC 1912 states the rule and adds the wrinkle: where the local part of the address itself contains a dot, that dot is escaped with a backslash, so john\.smith.example.com is [email protected] and not a subdomain of anything.

The convention RFC 1912 recommends is a generic address such as hostmaster, aliased to whoever should actually read it. That is worth checking on any zone you inherited: the address is public, it is where a network operator with a problem will write, and on a great many zones it stopped being a working mailbox years ago.

Serial, refresh, retry and expire speak to secondaries

These four fields exist for zone transfer, the mechanism by which a secondary nameserver holds a copy of a zone published by a primary.

The serial is a version number, and RFC 1034 requires it to advance whenever the zone changes. A secondary compares the serial it holds with the primary's, and a higher serial means fetch the zone again. Comparison uses sequence space arithmetic rather than a plain greater-than test, which is part of why the common YYYYMMDDnn format works well: it always increases and stays readable. On managed DNS with a proprietary replication layer, the visible serial may not move in step with your edits, and that is architecture rather than a fault.

The three timers say when the secondary acts. Refresh is how long it waits before checking the primary for a new serial. Retry is how soon it tries again when that check fails. Expire is the outer limit: a secondary that cannot complete a serial check for that long must treat its copy as obsolete and discard it, which stops a stale zone answering forever after its primary disappears. Published defaults at managed providers commonly run to a couple of hours for refresh, a quarter of an hour for retry, and two weeks for expire.

If your zone lives entirely on one provider's network, no secondary is polling a primary in this sense and these values describe a relationship that does not exist. They matter when you run a hidden primary with secondaries, or add a secondary DNS service that transfers your zone.

The minimum field stopped meaning minimum in 1998

The last field is labeled MINIMUM in RFC 1035 and in most control panels, and the label is misleading. RFC 2308 redefined it, and this is the most commonly misstated fact about the SOA record.

RFC 2308 sets out the three meanings the field had been carrying at once and disposes of them one at a time. The original meaning, a minimum TTL for every record in the zone, had never been used in practice and was deprecated outright. The second, a default TTL for records written without one, was moved out of the SOA entirely and given to the $TTL directive, which RFC 2308 added to the master file format. What remained, and what the field now means, is the TTL to be used for negative responses.

Three claims still in circulation follow from the old meanings, and all three are wrong:

• That the field sets a floor under the TTL of your ordinary records. It does not, and in practice it never did.
• That it supplies a default TTL for records that lack one. That job belongs to $TTL.
• That it affects positive answers at all. It affects only the answers that say no.

The field was not renamed. It is still MINIMUM on the wire, which is exactly why the misunderstanding survives.

How long a resolver remembers that a name does not exist

When an authoritative server has to say no, it must include the zone's SOA record in the authority section of that response. The resolver takes a TTL from it and holds on to the no.

There are two kinds of no. NXDOMAIN means the name does not exist at all. NODATA means the name exists but carries no record of the type asked for, which is what you hit when a name has an address record and something queries it for TXT. Both are cached.

The duration is not simply whatever sits in the minimum field. RFC 2308 specifies the lesser of two numbers: the MINIMUM field, and the TTL of the SOA record itself. Lowering one while the other stays smaller changes nothing, and both are visible in the SOA record as your servers actually serve it.

The practical bite is familiar to anyone who has added a verification TXT record and then watched the service keep reporting it as missing. Something asked for the record before it existed, got a no, and cached it. The record is live; the resolver in front of the checker is not asking again yet. The same effect stretches a brief deletion into a longer outage than the deletion itself, because the negative answers handed out during the gap outlive it.

RFC 2308 records what has been found to work: one to three hours makes a sensible default for how long negative answers are held, and values beyond a day have proven problematic. Older guidance to set this field to several days is not so much wrong as out of date, since it was written for the pre-1998 meaning, when the field described the zone's ordinary TTLs rather than its denials.

What to touch and what to leave

On a zone that lives on a single managed provider, the honest list of SOA fields worth your attention is short.

• Leave MNAME, serial, refresh, retry and expire as generated unless you genuinely run zone transfers to a secondary. On a single-provider zone, changing them changes nothing anyone can observe.
• Fix RNAME if it points at a mailbox nobody reads, since that is the address a stranger will use to tell you your zone is broken.
• Read the minimum field and the SOA's own TTL together, because the smaller of the two is the one in force.
• Lower the negative-caching TTL ahead of planned work that will create or restore names, the same way you would lower a record's TTL before changing it, then put it back.

Providers differ in how much of this they expose. Some publish the SOA read-only, some allow the last field to be edited, and some allow all of it. Where it cannot be edited, the provider has chosen the values for you. What you should not do is treat a large minimum value as a performance setting: it buys nothing on positive answers, and it lengthens the window in which a mistake stays visible after you have corrected it.