DNS Records & Concepts
What is an SOA record?
An SOA record, Start of Authority record, is a DNS record that contains essential administrative information about a DNS zone. Every DNS zone has exactly one SOA record, it is mandatory, automatically created by DNS providers, and marks the beginning of authority for the zone. The SOA record identifies the primary nameserver for the zone, provides contact information for the zone administrator, and contains timing parameters that control how the zone’s data is distributed and cached across the DNS system.
The Start of Authority name reflects the record’s role, it is the authoritative starting point for a DNS zone. When a DNS resolver queries an authoritative nameserver for a domain, the SOA record is the first record in the zone, the record that establishes the authority and identity of the nameserver responding to queries. It tells resolvers and secondary nameservers everything they need to know about the administrative structure of the zone and how to handle its data.
SOA records are not something domain owners typically configure directly. DNS providers create and maintain SOA records automatically as part of zone management. Understanding what SOA records contain and what each field means is valuable for anyone working with DNS at a deeper level, particularly when troubleshooting zone transfer issues, understanding DNS caching behaviour, or interpreting raw DNS query output.
How an SOA record works
The SOA record is stored at the zone apex, the root of the DNS zone, alongside other records for the domain. When a nameserver receives a query for any record in a zone it has authority over the SOA record establishes that authority. Resolvers that receive negative responses, responses indicating a record does not exist, use the SOA record’s TTL value to determine how long to cache the negative response.
Secondary nameservers, additional nameservers that hold copies of a zone’s data, use the SOA record to manage zone transfers. They compare the serial number in the SOA record against their own cached version to determine whether the primary nameserver has newer data. If the serial number has increased since the last transfer the secondary initiates a zone transfer to fetch the updated records.
A raw SOA record in DNS zone file format looks like this:
Each element in the SOA record serves a specific purpose in DNS zone management.
SOA record fields
The SOA record contains seven fields beyond the standard DNS record name and type, the primary nameserver, the administrator email, and five numeric values that control zone behaviour.
Primary nameserver (MNAME): the hostname of the primary authoritative nameserver for the zone. This is the nameserver that receives DNS updates and from which secondary nameservers pull zone transfer data. In the example above ns1.registrar.com is the primary nameserver. Secondary nameservers contact this hostname when initiating zone transfers.
The primary nameserver in the SOA record does not need to match the NS records for the zone, and often does not in modern managed DNS environments where multiple nameservers all function as peers rather than in a strict primary-secondary hierarchy. The MNAME field is primarily relevant for traditional zone transfer setups.
Administrator email (RNAME): the email address of the zone administrator encoded in DNS format. Because the @ symbol is used in DNS record syntax for the zone apex, the email address uses a dot in place of the @. admin.example.com. in the SOA record represents the email address admin@example.com. The first dot in the RNAME field, before the domain, represents the @ separator. Any dots in the local part of the email address, before the @: are escaped with backslashes in the zone file, though most DNS management interfaces handle this encoding automatically.
Serial number: a positive integer that increases every time the zone data is updated. Secondary nameservers compare the serial number in the primary nameserver’s SOA record against their own to determine whether a zone transfer is needed. If the primary has a higher serial number the secondary initiates a transfer. If the numbers match no transfer is needed.
Serial numbers must always increase when zone data changes, never decrease. The most common convention is to use a date-based format, YYYYMMDDNN where NN is a two-digit daily revision number. 2024042301 means the first revision on April 23rd 2024. This convention makes the serial number meaningful at a glance while guaranteeing it increases with each update. Simple incrementing integers are also valid, 1, 2, 3: though they provide no date context.
DNS providers that manage zones automatically update the serial number whenever zone records are changed. Domain owners managing their own zone files must remember to increment the serial number manually whenever making changes, or secondary nameservers will not detect that an update has occurred.
Refresh: the interval in seconds at which secondary nameservers should check the primary nameserver for updates by comparing serial numbers. A refresh value of 3600 means secondary nameservers check for updates every hour. Lower values mean more frequent checks and faster propagation of changes. Higher values reduce the query load on the primary nameserver.
Modern DNS architectures using anycast and synchronised nameserver clusters often have refresh values that are less critical than in traditional primary-secondary setups, all nameservers in the cluster receive updates simultaneously. For traditional zone transfers a refresh value between 3600 and 86400 seconds is typical.
Retry: the interval in seconds at which secondary nameservers should retry contacting the primary nameserver if a refresh check or zone transfer attempt fails. If the primary is unreachable during a refresh cycle the secondary waits the retry interval before trying again. A retry value of 900 seconds, 15 minutes, means the secondary tries again every 15 minutes until it can reach the primary.
The retry value should be shorter than the refresh value, a secondary that cannot reach the primary should check more frequently than its normal refresh interval until the problem is resolved.
Expire: the duration in seconds after which secondary nameservers should stop serving zone data if they cannot reach the primary nameserver. If a secondary cannot perform a successful zone transfer within the expire period it considers its cached zone data stale and stops serving it. A value of 604800 seconds, one week, means secondary nameservers continue serving cached zone data for up to one week without a successful zone transfer before giving up.
The expire value should be significantly longer than the refresh and retry values, long enough that a primary nameserver outage lasting days does not immediately take down all secondary nameservers. A week or longer is typical.
Minimum TTL (NXDOMAIN TTL): despite its name this field does not set the minimum TTL for all records in the zone. It specifies the TTL for negative responses, NXDOMAIN responses indicating a queried name does not exist in the zone. When a resolver queries for a record that does not exist the authoritative nameserver returns a negative response. The resolver caches this negative response for the duration specified in the minimum TTL field.
Setting an appropriate minimum TTL balances reducing unnecessary repeated queries for non-existent names, which would be reduced by a higher value, against ensuring that newly created records propagate quickly to resolvers that previously received negative responses, which requires a lower value. A value between 300 and 3600 seconds is typical for most zones.
SOA records and DNS propagation
The SOA record’s serial number is the mechanism that drives DNS propagation in traditional primary-secondary DNS architectures. When zone data changes the serial number increments. Secondary nameservers detect the increment during their next refresh cycle and initiate a zone transfer. After the transfer the secondary nameservers serve the updated data.
The propagation speed in this model is governed by the refresh interval, the shorter the refresh the faster changes propagate to secondary nameservers. Modern managed DNS services often use push-based propagation, the primary notifies secondaries of changes immediately using DNS NOTIFY messages rather than waiting for the scheduled refresh cycle. With NOTIFY-based propagation changes reach all secondaries within seconds regardless of the refresh interval.
For domain owners using managed DNS providers the SOA record’s propagation mechanisms are handled entirely by the provider. Changes made through the DNS management interface propagate automatically, the provider handles serial number increments, NOTIFY messages, and zone transfers without requiring manual intervention.
SOA records and negative caching
The minimum TTL field in the SOA record, which governs negative response caching, is relevant for redirect management in a specific way.
When a domain is newly connected to redirect management infrastructure DNS propagation means some resolvers continue serving old DNS data while others have the new records. For resolvers that previously received a negative response, a NXDOMAIN for a newly created record, the minimum TTL determines how long they cache that negative before querying again.
A high minimum TTL means resolvers that cached a negative response before the new record was created continue to serve that negative for the full minimum TTL period. Visitors on those resolvers receive DNS errors rather than the correct redirect response even after the record exists on the authoritative nameserver.
For domains that are actively being set up and where rapid propagation of new records is important a lower minimum TTL, 300 seconds, is preferable. For established domains where negative caching efficiency matters more than propagation speed a higher value, 3600 seconds, is appropriate.
Checking SOA records
SOA records can be queried directly using standard DNS tools.
dig command: on Linux and macOS:
Returns the SOA record for example.com showing all seven fields, primary nameserver, administrator email, serial number, refresh, retry, expire, and minimum TTL, along with the record TTL.
Adding +short returns a condensed single-line view of the SOA values:
Checking the primary nameserver’s SOA: to see the SOA record directly from the primary nameserver rather than from a cached resolver query specify the nameserver in the dig command:
Comparing serial numbers: when diagnosing zone transfer issues compare the serial number on the primary nameserver against secondary nameservers to determine whether they are in sync:
Different serial numbers between nameservers indicates a zone transfer has not completed, the secondary has not yet received the latest updates from the primary.
nslookup: on Windows and other platforms:
SOA records in managed DNS vs self-hosted DNS
The degree to which SOA record management matters depends on whether DNS is managed by a provider or self-hosted.
Managed DNS providers: all major DNS providers, Cloudflare, Route 53, Google Cloud DNS, NS1, and others, manage SOA records automatically. Domain owners making changes through the provider’s interface never need to think about SOA records. Serial numbers increment automatically. Refresh, retry, expire, and minimum TTL values are set to appropriate defaults. The primary nameserver field points to the provider’s infrastructure. SOA records are an implementation detail managed entirely by the provider.
Self-hosted DNS: organisations running their own authoritative nameservers, BIND, PowerDNS, Knot DNS, manage SOA records manually or through zone management tools. The zone administrator is responsible for incrementing the serial number with every zone update, setting appropriate timing values, and configuring the primary nameserver field correctly. Forgetting to increment the serial number is one of the most common mistakes in self-hosted DNS, secondary nameservers do not detect that changes have been made and continue serving stale zone data.
Common SOA record issues
Serial number not incrementing: in self-hosted DNS environments forgetting to increment the serial number when updating zone data prevents secondary nameservers from detecting changes. Zone transfers do not occur and secondaries serve stale data. The fix is to increment the serial number in the SOA record and allow the next refresh cycle to trigger a transfer. DNS providers that manage zones automatically never have this issue.
Serial number decreasing: the serial number must always increase. If it decreases, whether through a rollback to an older zone file or a miscalculation, secondary nameservers stop accepting zone transfers from the primary because the lower serial number looks like older data. Recovering from a decreased serial number requires incrementing the value past the highest number the secondaries have seen.
Expire value too short: an expire value shorter than the time needed to resolve a primary nameserver outage causes secondaries to stop serving zone data during extended outages. If the primary is unreachable for longer than the expire period all secondary nameservers stop responding for the zone, effectively taking the entire domain offline. The expire value should be at least several days and ideally a week or more.
Minimum TTL too high for new records: a high minimum TTL causes resolvers that received negative responses for non-existent names to cache those negatives for an extended period. Newly created records do not reach those resolvers until their negative cache expires. For domains where new records are frequently created a moderate minimum TTL, 300 to 600 seconds, ensures new records propagate promptly.
Wrong administrator email format: in self-managed zone files the administrator email must be in DNS format, dot replacing @: rather than standard email format. admin@example.com must be entered as admin.example.com. in the zone file. Entering the standard email format breaks the SOA record syntax.