--- title: New subdomain not resolving? Check a SOA record with the SOA Record Lookup description: You created a subdomain, it works for you, and a colleague or a certificate authority still gets 'no such domain'. The answer is in the zone's SOA record: its minimum field and TTL set how long resolvers cache a 'doesn't exist' answer. Here's how to check a SOA record with the free SOA Record Lookup, how to read all seven fields, and the dig commands that compare serials across nameservers. canonical: https://watchfor.io/blog/how-to-check-a-soa-record --- # New subdomain not resolving? Check a SOA record with the SOA Record Lookup 2026-10-04 · WatchFor Team · Guides · guides, dns, networking You created a subdomain, it works for you, and a colleague or a certificate authority still gets 'no such domain'. The answer is in the zone's SOA record: its minimum field and TTL set how long resolvers cache a 'doesn't exist' answer. Here's how to check a SOA record with the free SOA Record Lookup, how to read all seven fields, and the dig commands that compare serials across nameservers. To check a SOA record, look up the SOA of the zone apex (`example.com`, not a subdomain) and read its fields. The two that answer most practical questions are the **serial**, which tells you whether every nameserver has the latest version of the zone, and the **minimum** field, which together with the SOA's own TTL sets how long resolvers remember that a name doesn't exist. That second number is why a brand-new subdomain can keep failing for up to an hour after you create it. The free [SOA Record Lookup](/soa-record-lookup) shows every field of a zone's SOA record, with its TTL, from a real WatchFor location. No signup. ## What this tool answers *Who is primary for this zone, which version is it on, and how long do caches hold a "doesn't exist" answer?* Reach for it when a new record isn't visible to some people, when you run secondary nameservers and need to know they've picked up a change, or when you want the zone's administrative contact and timers before a migration. ## A real example ### Checking a SOA record when a new name still returns NXDOMAIN A familiar sequence: someone tries `new.example.com` before it exists (or a monitoring tool, or a certificate authority does), gets `NXDOMAIN`, then you create the record. Your own lookup works; theirs keeps failing. Their resolver cached the "no such name" answer, and the SOA says for how long. In the [SOA Record Lookup](/soa-record-lookup) we typed `wikipedia.org`, kept the resolver on **Auto** and pressed **Run lookup**: ![The SOA Record Lookup for wikipedia.org from Europe / Lithuania: NOERROR, 1 record, expire 1209600, mbox hostmaster.wikimedia.org., minttl 3600, ns ns0.wikimedia.org., refresh 43200, retry 7200, serial 2026060420, ttl 3253, type SOA](/blog/how-to-check-a-soa-record-result.webp) One record, `NOERROR`, served from the resolver's cache (0 ms): | Field | Value | In plain words | | --- | --- | --- | | ns | ns0.wikimedia.org. | Primary nameserver | | mbox | hostmaster.wikimedia.org. | Admin contact: `hostmaster@wikimedia.org` | | serial | 2026060420 | Zone version | | refresh | 43200 | Secondaries check for changes every 12 hours | | retry | 7200 | After a failed check, retry every 2 hours | | expire | 1209600 | Secondaries stop answering after 14 days without the primary | | minttl | 3600 | Upper bound for caching "doesn't exist", in seconds | | ttl | 3253 | Seconds left on this cached copy (3,600 at the source) | Per RFC 2308, a resolver caches a negative answer for the smaller of the SOA's TTL and its minimum field. Here both are 3,600, so a "no such name" answer for any `wikipedia.org` name can stick for **up to one hour**. **The answer:** in this zone, someone who looked up a name before it existed may keep getting `NXDOMAIN` for up to an hour. For your own zone, read the same two numbers: the smaller one is how long to wait (or how long to ask people to wait) after creating a record that someone already tried. ## How to read the results | Field | What it means | | --- | --- | | **ns** (MNAME) | The primary nameserver, where changes originate. Managed DNS providers often put one of their servers here. | | **mbox** (RNAME) | The admin mailbox, with the first dot standing for `@`. | | **serial** | A number that must increase with every zone change. Secondaries compare it to decide whether to transfer the zone. | | **refresh / retry / expire** | Timers for secondary nameservers, in seconds. Only matter if you run classic primary/secondary replication. | | **minttl** (MINIMUM) | Today used as the negative-caching TTL cap (RFC 2308). | | **ttl** | How long this SOA record itself may be cached; shown as the time left when it comes from a cache. | | **Resolve time / NOERROR** | As in every DNS lookup: green under 50 ms; amber badges mean no usable answer. | The rows are listed alphabetically by field name, not in zone-file order. ## More ways to use it - **Proving a change reached every nameserver.** Point the resolver at each of your nameservers in turn (Custom IP in the [DNS Lookup](/dns-checker)) and compare serials. Identical means they all serve the same version. - **Before a migration.** Note the minimum and TTL so you know how long negative answers for new names will linger during the switch. - **Finding where a zone starts.** Ask for the SOA of a deep name with `dig`; the authority section names the zone it belongs to. - **Contacting the DNS admin.** The mbox field is the zone's published technical contact, though many providers use a generic address. ## Tips and gotchas - **Query the apex.** The SOA lives at the top of the zone. Asking the tool for `www.wikipedia.org` returns no SOA records; `dig` shows that SOA in the authority section instead. - **Serials only compare within one provider.** Zones served by two providers have two SOAs. `github.com` returns serial `1656468023` from NS1 and `1` from Route 53, both correct (see below). - **Managed DNS often fixes the serial.** Route 53, for example, publishes serial `1` and doesn't use classic zone transfers; the serial won't tell you about changes there. - **Lower minimum, faster recovery.** A minimum of a few minutes shortens how long a premature lookup hurts. Some providers don't let you change it. - **Negative caching also hits record types.** Asking for a TXT record that doesn't exist yet caches "no TXT here" for the same period, a common reason domain verifications fail right after adding the record. ## Check it from the command line too The SOA at the source, and the serial on each nameserver: ```bash dig +noall +answer SOA wikipedia.org @ns0.wikimedia.org for n in ns0 ns1 ns2; do echo -n "$n "; dig +short SOA wikipedia.org @$n.wikimedia.org; done ``` ```text wikipedia.org. 3600 IN SOA ns0.wikimedia.org. hostmaster.wikimedia.org. 2026060420 43200 7200 1209600 3600 ns0 ns0.wikimedia.org. hostmaster.wikimedia.org. 2026060420 43200 7200 1209600 3600 ns1 ns0.wikimedia.org. hostmaster.wikimedia.org. 2026060420 43200 7200 1209600 3600 ns2 ns0.wikimedia.org. hostmaster.wikimedia.org. 2026060420 43200 7200 1209600 3600 ``` All three serve serial `2026060420`. A name that doesn't exist returns `NXDOMAIN` with the SOA attached, and that SOA's TTL is the negative-cache time: ```bash dig nope-g1-test.wikipedia.org A @ns0.wikimedia.org | grep -E "status|SOA" ``` ```text ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10937 wikipedia.org. 3600 IN SOA ns0.wikimedia.org. hostmaster.wikimedia.org. 2026060420 43200 7200 1209600 3600 ``` A zone on two providers shows two different SOAs: ```bash dig +short SOA github.com @dns1.p08.nsone.net dig +short SOA github.com @ns-421.awsdns-52.com ``` ```text dns1.p08.nsone.net. hostmaster.nsone.net. 1656468023 43200 7200 1209600 3600 ns-1707.awsdns-21.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400 ``` ## Keep watching it If you run your own primary and secondaries, a serial that stops advancing on one server means it serves an old zone. A [DNS monitor](/dns-monitoring) on the **SOA** record type, pointed at a specific nameserver through a custom upstream resolver, re-checks it on a schedule; the **Expected DNS Records** rule can match the primary nameserver, the mailbox or a serial value and opens an incident when the answer differs. ## FAQ **What is a SOA record used for?** It marks the start of a DNS zone and holds its administrative data: the primary nameserver, the admin contact, the serial number and the timers that control zone transfers and negative caching. Every zone has exactly one. More in [DNS record types explained](/blog/dns-record-types-explained). **How long is an NXDOMAIN cached?** For the smaller of the SOA record's TTL and its minimum field, per RFC 2308. For `wikipedia.org` that's 3,600 seconds; many zones use between a few minutes and a day. **Why are the SOA serials different on my nameservers?** Either a secondary hasn't transferred the latest zone yet (it retries on the refresh and retry timers), or your nameservers belong to different providers that each generate their own SOA. The [nameserver guide](/blog/how-to-find-a-domains-nameservers) shows how to list them. --- Canonical page: https://watchfor.io/blog/how-to-check-a-soa-record · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt