What Is an SOA Record in DNS?

An SOA record, short for Start of Authority, is the DNS record that holds the administrative settings for a zone. It names the primary name server, the responsible contact, and the timers that control how secondary servers stay in sync with the primary. Every DNS zone has exactly one, and a zone is not valid without it.

Most DNS record types point somewhere. A records resolve to an IPv4 address, MX records route mail, TXT records publish policy. The SOA record is different in that it describes the zone itself, which is why it rarely gets configured by hand and just as rarely gets checked. 

If you’re wondering what is SOA in DNS, it is essentially the record that defines the administrative authority and synchronization settings for a DNS zone. This guide covers what the DNS SOA record contains, what each field controls, and how to check the one published for your domain.

What Is an SOA Record and Why Do You Need One?

SOA is an acronym for Start of Authority, and it’s a type of DNS record that contains important information about a DNS zone, including the administrator’s email address, server refreshing timeframe, and the last time a domain was updated. 

You need to properly configure an SOA record in your DNS to conform with IETF (Internet Engineering Task Force) standards. These records are also required during zone transfers. When transferring zones, you need to send the DNS records from a primary server to a secondary server. During this process, the first record you must send is the SOA record. A zone without an SOA record is invalid, and authoritative servers will refuse to load it, which means no lookups for that domain succeed.

The SOA record serves three purposes: it identifies which server holds the authoritative copy of the zone, it gives resolvers and administrators a contact address for the zone, and it sets the timing rules that govern synchronization and negative caching. Most DNS providers create it automatically when you add a domain, which is why many administrators never look at it until something stops synchronizing.

What Is a Zone Serial Number?

The DNS zone is a particular segment of the DNS namespace. This can include a single domain, a single domain and multiple subdomains, or several domain names. 

A zone serial number is a version number for your DNS domain. The serial appears in the SERIAL field of the record, shown in the example below. When the serial number changes, the secondary server will know there are changes and request a zone transfer.

The serial is a plain number, and the format is left to you. The widely used convention is YYYYMMDDnn: four digits for the year, two for the month, two for the day, and two more for the revision number that day. A zone edited twice on March 4, 2026 would carry 2026030402. This makes the last edit date readable at a glance and guarantees the value always increases.

The one rule that matters is that the serial must increase. Secondary servers compare the number they hold against the one published, and they only pull an update when the published value is higher. A serial that goes backward, which happens when a zone is restored from an old backup, leaves secondaries serving stale data until the number climbs past the value they already have.

The SOA Record Structure

A DNS SOA record contains vital information about a particular DNS zone or domain. This record is formatted in a structure that DNS servers and tools can parse. Below is an example of an SOA record. 

name	mywebsite.com
record type	SOA
MNAME	ns.primaryserver.com
RNAME	[email protected]
SERIAL	2026030401
REFRESH	7200
RETRY	6200
EXPIRE	1209600
TTL	3600

Let’s Let’s explain the format in the above SOA record structure. 

• Name: This is the name of your domain. In the above example, it’s mywebsite.com
• Record Type: This section determines the DNS record type; in this case, it’s the SOA record.
• MNAME: The MNAME in the above format represents the domain’s primary server name. 
• RNAME: The administrator’s email address, written with the @ replaced by a dot. In the example, admin.mywebsite.com corresponds to [email protected]. 
• SERIAL: The version number for the DNS zone. Increase this value each time you edit the zone file so changes propagate to all secondary DNS servers.
• REFRESH: This is the timeframe in seconds a secondary server waits before sending a query to the primary server SOA record for any new changes. 
• RETRY: This is the time a server should wait after a failed refresh before sending a new query. 
• EXPIRE: The period in seconds that a secondary server will continue to query the primary server for an update. When this time expires, the secondary server’s zone files expire, and it stops responding to queries. 
• TTL (Minimum): The negative caching TTL. It sets how long resolvers cache a “does not exist” answer for names in this zone. Originally defined as the default TTL for records without their own TTL; RFC 2308 (1998) redefined it as the negative-caching TTL.

Recommended SOA Timer Values

The four timers control synchronization between primary and secondary servers. RFC 1912 and RFC 2308 give working ranges for each.

Field	Typical range	What it controls
REFRESH	1200 to 43200 seconds	How often a secondary checks the primary for a new serial. Lower values mean faster propagation and more query traffic.
RETRY	120 to 7200 seconds	How long a secondary waits before retrying after a failed refresh. Always set below REFRESH.
EXPIRE	1209600 to 2419200 seconds	How long a secondary keeps serving the zone when it cannot reach the primary. Two to four weeks is standard.
TTL (Minimum)	3600 to 10800 seconds	How long resolvers cache negative answers. One to three hours is the RFC 2308 recommendation.

Most DNS providers set sensible defaults, and providers that support DNS NOTIFY push changes to secondaries immediately rather than waiting for the refresh interval, which makes REFRESH a fallback rather than the primary mechanism. The value worth reviewing is EXPIRE, since it determines how long your zone survives a prolonged outage on the primary server.

What is a Zone Transfer?

This is a process where the DNS zone files on a primary server are copied to a secondary server. The SOA record in the DNS zone is always transferred first. Zone transfers provide fault tolerance by synchronizing zone files in a primary server with zone files in the secondary server. 

A zone transfer is required in the following situations:

• If the primary DNS server is down, the secondary server will have an up-to-date copy of the DNS zone files and can successfully handle DNS resolution queries from DNS clients on the internet. 
• If numerous DNS clients on the internet send queries simultaneously, you can balance the requests between the primary and secondary DNS servers. 
• If a primary nameserver is at the far end of a slow WAN link, a zone transfer allows secondary nameservers to answer queries locally, reducing network traffic.

The secondary server initiates the zone transfer by querying the primary server to see whether there are changes in the primary DNS server zone files. If any changes exist, it requests a zone transfer. When the refresh time expires on the secondary DNS server, the following happens:

• The secondary DNS server gets the Start of Authority (SOA) record from the primary server.
• The secondary DNS server compares the serial version number of the newly received SOA record with its current version. If there’s a change, then it requests a zone transfer. 
• All DNS zone files are transferred from the primary to the secondary servers in this process.

SOA Records and DNSSEC

DNSSEC signs DNS responses so resolvers can verify they came from the authoritative server and were not modified in transit. The SOA record participates in two ways.

First, it gets signed like any other record in the zone. Every record set carries an RRSIG signature, including the SOA, and a resolver validating a response checks that signature against the zone’s keys.

Second, its Minimum TTL field governs how long a validated “does not exist” answer stays cached. DNSSEC proves non-existence using NSEC or NSEC3 records, and the SOA Minimum value sets the caching duration on those proofs. A Minimum set too high means a newly added record stays invisible to resolvers that already cached the proof it did not exist.
Signing also makes serial discipline stricter. Signatures carry expiry dates, and a zone whose serial fails to increment after re-signing can leave secondaries serving records with expired signatures, which validating resolvers reject outright. This is part of how DNSSEC works to maintain trust across the DNS signing chain.

Common SOA Record Misconfigurations

SOA problems are quiet. The zone keeps resolving from the primary while secondaries drift, so the symptom usually appears as inconsistent answers depending on which server responded.

• A serial that never increments. Edits land on the primary and never reach the secondaries. This is the most common SOA fault and the hardest to spot, because the primary answers are correct throughout.
• A serial that moves backwards. Usually caused by restoring a zone from backup. Secondaries ignore the lower number and keep serving what they have.
• RNAME with an unmonitored or invalid address. The contact address in the SOA is where operators and automated systems report zone problems. A dot-formatted address pointing at a mailbox nobody reads means those reports go nowhere.
• MNAME pointing at a server that is not authoritative. The primary named in the SOA should be a server that actually holds the master copy. A mismatch breaks NOTIFY and confuses diagnostic tooling.
• RETRY set higher than REFRESH. Inverts the logic, so a secondary waits longer after a failure than it would have waited normally.
• Minimum TTL set very high. Negative answers stay cached for hours, so a record you just added appears missing to anyone who queried the name before it existed.
• Mismatched SOA records across authoritative servers. Every authoritative server for a zone should return the same SOA. Differing serials mean a transfer has not completed.

How to Check and Edit an SOA Record

Checking an SOA record is straightforward and takes one query. Editing one depends entirely on your DNS provider, since most generate the record automatically and expose only some of its fields.

Checking Your SOA Record

An SOA record lookup returns the current serial, the primary name server, the contact address, and all four timer values for a domain. It is the fastest way to confirm a change reached the zone, because the serial tells you whether the zone was updated at all.

From the command line:

dig example.com SOA +short

nslookup -type=soa example.com

To confirm every authoritative server holds the same version, query each one directly and compare serials:

dig example.com SOA @ns1.example.com +short

dig example.com SOA @ns2.example.com +short

Matching serials mean the zone is in sync. Different serials mean a transfer is pending or has failed.

Editing Your SOA Record

How much you can change depends on your DNS provider. Managed providers such as Cloudflare and GoDaddy generate the SOA automatically and increment the serial for you on every edit, exposing few or none of the fields. Providers that host traditional zone files, and any self-hosted BIND or PowerDNS setup, expose all of them.

Where the fields are editable, the practical guidance is to leave REFRESH and RETRY at their defaults, review EXPIRE against how long you could tolerate the primary being unreachable, and keep Minimum TTL low enough that newly added records become visible quickly. If you edit a zone file by hand, increment the serial in the same edit. Forgetting is the single most common cause of secondaries falling behind.

Summary

In this article, we’ve explored the meaning of SOA records and why you need to include them in your DNS domain. SOA or Start of Authority DNS records are vital information that allows your domain to function properly. 

Without this record, zone transfers are impossible. The SOA record determines how fast the zone updates are transferred from primary servers to secondary servers. 

Now that you understand what the SOA record means, make sure you configure it for all your domains. SOA records work alongside the most common DNS record types used to direct traffic, route email, publish policies, and manage other parts of a domain’s DNS configuration.

Frequently Asked Questions