SOA (Start Of Authority) record and zone timing health checks

1. SOA Record

This block shows the exact SOA record returned by your nameservers: primary nameserver (MNAME), hostmaster e-mail, serial number and timing values.

Why this matters

The SOA is the authoritative “header” of your zone. If it points to the wrong primary server, uses an invalid hostmaster address or exposes clearly wrong timers, it usually indicates broader DNS misconfiguration.

How DNSprobe checks it

DNSprobe asks each authoritative server for the SOA at the zone apex and displays the version that appears consistent across them. It highlights the main fields so you can compare them with your intended configuration.

Typical problems detected

• The SOA is missing or different servers return different SOA records for the same zone.
• The primary nameserver (MNAME) or hostmaster e-mail address looks invalid or points to a non-existent host.
• Timing values are clearly unreasonable (for example, extremely low EXPIRE or negative TTL set to zero).

Best practices

• Keep exactly one SOA record at the apex of the zone and ensure all authoritative servers serve the same data.
• Use a valid, monitored hostmaster e-mail address that goes to a real mailbox or ticket system.
• Review the SOA at each DNS change to confirm the primary nameserver and timers still match your operational policies.

2. NSs have same SOA serial

This test verifies that all authoritative nameservers return the same SOA serial number for your zone.

Why this matters

The SOA serial is how secondary nameservers know that the zone has been updated. If different servers show different serials, your zone data is out of sync and clients may see inconsistent answers depending on which server they hit.

How DNSprobe checks it

DNSprobe queries the SOA from each nameserver and compares only the serial field. If all serials are identical, your zone appears synchronized; if not, the report shows a warning with the differing values.

Typical problems detected

• Some nameservers still serve an old SOA serial after a zone update.
• Hidden primary or misconfigured transfer settings prevent secondaries from receiving new zone versions.
• Manual edits on secondary servers that break the normal zone transfer flow.

Best practices

• Use automatic zone transfers (AXFR/IXFR or API-based sync) from a single primary instead of editing multiple servers by hand.
• Monitor that secondaries refresh within a reasonable delay after the primary serial increases.
• Avoid long-lived or stale secondary servers that rarely update but are still published in NS records.

3. SOA MNAME entry

The MNAME field in the SOA indicates the primary nameserver for the zone—the server that secondaries should contact for zone transfers.

Why this matters

If MNAME points to a host that is not authoritative, unreachable or not listed as an NS, secondaries may not refresh correctly and troubleshooting becomes harder.

How DNSprobe checks it

DNSprobe inspects the SOA’s MNAME value and verifies whether this hostname also appears in your NS set and answers authoritatively for the zone.

Typical problems detected

• MNAME is set to a host that is not present in the public NS records.
• The MNAME host does not respond authoritatively for the zone or is unreachable.
• Historical or placeholder values left in MNAME after a migration to a new DNS provider.

Best practices

• Set MNAME to your actual primary or to the DNS provider that manages the zone content.
• Keep MNAME consistent with your NS records to make debugging easier.
• Update MNAME whenever you move the zone to a new primary platform.

4. SOA Serial

This test focuses on the numeric serial in your SOA record, often using a date-based format such as YYYYMMDDnn.

Why this matters

Each time you change the zone, the serial should increase. If it does not, secondary servers and caches may never notice the update and continue to serve outdated data.

How DNSprobe checks it

DNSprobe reads the SOA serial and, when possible, comments on whether it looks like a date-based value and whether it is in a realistic range.

Typical problems detected

• Serial not increasing after zone updates, preventing secondaries from refreshing.
• Serial reset to a lower value than before, confusing secondary servers and causing transfer issues.
• Non-standard serial formats that make it hard to see when the last change occurred.

Best practices

• Use a monotonically increasing serial; a date-based scheme (YYYYMMDDnn) is easy to track.
• Ensure your DNS tooling automatically bumps the serial when you change the zone.
• Avoid manual edits that might accidentally decrease the serial number.

5. SOA REFRESH

REFRESH defines how often secondary nameservers should check with the primary to see if the zone serial has changed.

Why this matters

If REFRESH is too high, changes you make on the primary can take a long time to reach secondaries. If it is too low, secondaries poll too frequently and generate unnecessary traffic.

How DNSprobe checks it

DNSprobe reads the REFRESH value (in seconds) and compares it to common operational ranges, adding a short comment in the report.

Typical problems detected

• Very high REFRESH causing multi-hour or multi-day delays before secondaries notice updates.
• Extremely low REFRESH generating a high volume of SOA queries from secondaries.
• Values inconsistent with your expected update frequency (for example, dynamic zones with very slow REFRESH).

Best practices

• Choose a REFRESH that matches how often you change the zone (often between 15 minutes and a few hours).
• For mostly static zones, longer REFRESH reduces load without causing problems.
• For frequently updated zones, keep REFRESH reasonably short so secondaries follow changes promptly.

6. SOA RETRY

RETRY defines how long a secondary waits before trying again if the primary was unreachable during a refresh attempt.

Why this matters

If RETRY is too long, secondary servers may wait a long time before attempting another refresh, slowing recovery after outages. If it is too short, they may hammer an already failing primary.

How DNSprobe checks it

DNSprobe reads the RETRY value and checks that it is shorter than REFRESH and within a reasonable range for typical DNS operations.

Typical problems detected

• RETRY greater than or equal to REFRESH, making the refresh logic less effective.
• Very long RETRY delaying recovery after temporary network problems.
• Extremely short RETRY causing repeated bursts of failed refresh attempts.

Best practices

• Set RETRY significantly lower than REFRESH so secondaries try again sooner after an error.
• Use a moderate value—often a few minutes—to balance quick recovery and load.
• Review RETRY together with REFRESH and EXPIRE so all timers make sense as a group.

7. SOA EXPIRE

EXPIRE defines how long a secondary can continue serving data if it cannot reach the primary at all.

Why this matters

If EXPIRE is too low, a long outage of the primary can cause secondaries to stop serving the zone entirely. If it is too high, stale data may persist for a long time even after a critical change.

How DNSprobe checks it

DNSprobe reads the EXPIRE value and checks that it is much larger than REFRESH and RETRY, and within a realistic operational window (often several days).

Typical problems detected

• EXPIRE too short, risking complete zone outage during long maintenance or incidents.
• EXPIRE set to a value that is not significantly greater than REFRESH, reducing its protective effect.
• Extremely large EXPIRE that may keep outdated data alive far beyond your comfort level.

Best practices

• Choose an EXPIRE that matches your risk tolerance—often 1 to 2 weeks or more for critical zones.
• Ensure EXPIRE is many times higher than REFRESH and RETRY so it only triggers in exceptional situations.
• Review EXPIRE when changing your redundancy or disaster-recovery strategy.

8. SOA MINIMUM TTL

The MINIMUM field historically served as a default TTL, but is now mainly used as the negative caching TTL (how long resolvers may cache a “does not exist” answer).

Why this matters

If the negative TTL is too high, newly created records may appear to “not exist” for a long time because resolvers cached earlier NXDOMAIN replies. If it is too low, resolvers will re-query often for non-existent names.

How DNSprobe checks it

DNSprobe reads the MINIMUM value and comments on whether it looks appropriate for negative caching on a typical public zone.

Typical problems detected

• Very high MINIMUM TTL causing long delays before new records appear after previous NXDOMAIN responses.
• Very low MINIMUM TTL creating unnecessary extra traffic for non-existent names.
• Values that contradict your explicit per-record TTL policy.

Best practices

• Use a moderate negative TTL—long enough to reduce load but not so long that changes are blocked.
• Align MINIMUM with how frequently you add new hostnames to the zone.
• Remember that many modern DNS platforms use per-record TTLs and treat MINIMUM mostly as a negative caching hint.

9. Test SOA records manually from your own terminal

DNSprobe reads the SOA (Start of Authority) record for your zone and checks that all nameservers agree on the same serial and timing values (refresh, retry, expire, minimum TTL). You can inspect the raw SOA record yourself from a terminal and compare the serial across each authoritative nameserver.

Linux: using dig (BIND utilities)

On most Linux distributions, the dig command is provided by the BIND utilities package. The following commands display the SOA record for your domain and then query individual nameservers so you can confirm that the serial number matches on each one:

                dig example.com SOA
                dig example.com SOA +noall +answer
    
                # Optional: query each authoritative nameserver directly and compare the SOA serial values    
                dig @ns1.example.com example.com SOA
                dig @ns2.example.com example.com SOA
        

macOS: using dig from the built-in tools

macOS ships with dig as part of its standard command-line tools. Open Terminal and run the same commands as on Linux to view the SOA record and verify that all nameservers expose the same serial:

                dig example.com SOA
                dig example.com SOA +noall +answer
    
                # Optional: query each authoritative nameserver directly and compare the SOA serial values    
                dig @ns1.example.com example.com SOA
                dig @ns2.example.com example.com SOA
        

Windows: using nslookup

On Windows, the legacy nslookup tool can query the SOA record for your domain. Run the following commands from a Command Prompt or PowerShell window. You can ask for the generic SOA record, then explicitly query each nameserver to make sure they all report the same serial:

                nslookup -type=SOA example.com
    
                REM Optional: specify each authoritative nameserver explicitly to compare the SOA serial values    
                nslookup -type=SOA example.com ns1.example.com
                nslookup -type=SOA example.com ns2.example.com
        

Important: only query DNS records for domains that you own or are authorised to analyse. Repeated automated lookups against third-party domains may be treated as abusive traffic by some providers.