Defaults.Exposed › Reports

SOA Records: The Internet's Most Neglected Setting

Published 2026-08-18

Figures as of 2026-08-16 · methodology v9. This is a recurring report; each edition re-measures the same population so the numbers can be tracked over time. All figures are aggregate — we never publish an individual business’s grade or name an individual registrant’s domain.

The headline: half the internet’s zones run on timers nobody has looked at

We read the Start of Authority record on 275,073,813 domains in the August 2026 census, and 138,982,990 of them — 50.5% — carry a retry or expire timer outside the ranges long-standing DNS operational guidance recommends. Not broken. Not down. Just set to values that suggest nobody has opened the zone file since the day it was generated, if a human ever opened it at all.

Every DNS zone on the internet starts with an SOA record. It names the primary nameserver, gives an administrative contact, and sets five timers that govern how the zone’s secondary servers stay in sync with the primary. It is the oldest kind of configuration there is: written once, propagated everywhere, read by machines forever, reviewed by humans never. This report is a census of what those timers actually say in 2026.

The one-line answer: the coin lands on “out of range” slightly more often than not.

Key numbers

• 50.5% of measured domains have at least one SOA timer outside recommended ranges — 138,982,990 of 275,073,813 domains with a readable SOA record, August 2026 census.
• 40.8% of domains carry an out-of-range retry timer (outside 300–3,600 seconds): 112,168,427 domains.
• 14.1% carry an out-of-range expire timer (outside 1–4 weeks): 38,706,880 domains.
• 11,892,317 domains — 4.3% — miss on both timers at once.
• Only 49.5% of the measured web — 136,090,823 domains — keeps both timers inside the recommended bands.
• The bands follow RFC 1912-style operational guidance (industry context: RFC 1912 was published in 1996 — these recommendations are three decades old and still the reference point).

What is an SOA record and why does it have timers?

DNS zones are usually served by more than one nameserver. One of them is authoritative in the original sense — the primary, where changes are made — and the others are secondaries that copy the zone from it. The SOA record is the contract between them. Its timer fields tell every secondary: check for updates this often (refresh), if the primary doesn’t answer then try again after this long (retry), and if you still can’t reach it, keep serving your last good copy of the zone for at most this long before you stop answering entirely (expire).

That last one deserves a moment. Expire is a self-destruct timer. A secondary that cannot reach its primary for longer than the expire value discards the zone and starts returning errors for every query. Set it sensibly — the guidance says one to four weeks — and a broken primary gives you days of grace to notice and fix things. Set it very short and a weekend outage at the primary can take your whole domain dark even though the secondaries are healthy. Set it absurdly long and a decommissioned-but-not-quite-dead primary can keep stale data alive for months.

Retry governs the other direction: how hard secondaries hammer a primary that just failed a refresh. Too aggressive and a struggling primary gets no room to recover; too lazy and zone changes crawl out over hours.

These numbers mattered enormously in the 1990s, when zone transfers over slow links were how DNS propagated. Modern managed DNS blunts them — more on that below, because it is the honest caveat this whole report rests on. But the timers are still live protocol machinery. Validating what they say is one DNS query per domain. So we queried all of them.

How many domains have bad SOA timers?

For each graded domain in the August 2026 census we read the SOA record and checked two of its timers against the recommended operational bands our methodology uses: retry between 300 and 3,600 seconds (5 minutes to 1 hour) and expire between 604,800 and 2,419,200 seconds (1 to 4 weeks). Both bands trace to RFC 1912-era guidance (industry context, not census data). 275,073,813 domains returned a readable SOA; here is the full crosstab.

(Denominator throughout: the 275,073,813 graded domains with a readable SOA record. Percentages are shares of that denominator.)

Retry is the big offender. Two in five domains publish a retry timer outside the 5-minutes-to-1-hour band — 112.2 million zones. Expire misses far less often, at 14.1%, which makes sense: the expire band is wide (a factor of four between its floor and ceiling), and the consequences of getting expire wrong are severe enough that some defaults respect it even when nothing else was tuned.

The overlap is telling. Among domains with a bad retry value, only 10.6% also have a bad expire value. Among domains with a bad expire value, 30.7% also miss on retry. A zone that gets expire wrong is quite likely to be wrong everywhere; a zone that only misses on retry is more often carrying one odd default from whichever template stamped it out.

One direction we cannot give you: whether an out-of-range value is too high or too low. This cut of the data records in-band versus out-of-band only, not which side of the band the value fell on. [DATA GAP: low-side vs high-side split of out-of-range retry and expire values.]

Does anyone actually get hurt by this?

Mostly no, and this report would be dishonest without saying so plainly. An out-of-range SOA timer is advisory, not protocol-breaking. DNS resolution for visitors does not consult retry or expire at all — those timers only choreograph primary-to-secondary synchronisation. A domain can run retry=68 years and serve every web request perfectly.

Three things stop this from being a shrug.

First, expire is a genuine availability risk in the failure case. The scenario is specific: primary goes down or unreachable, stays down past the expire window, secondaries discard the zone, domain goes dark — resolution fails everywhere, mail bounces, the lot. A short expire narrows your window to notice a primary failure before it becomes a total outage. 38.7 million domains carry an expire value outside the band that guidance chose precisely to make that window humane.

Second, in the census the SOA check is a hygiene signal, and hygiene signals correlate. A zone with hand-rotted timers is a zone nobody is maintaining, and unmaintained zones are where the genuinely dangerous findings in our other reports live. The SOA timer is the dust on the shelf: harmless itself, informative about the housekeeping.

Third, the sheer scale of the neglect is the finding. This is one of the few settings we measure where the internet splits almost exactly in half, and the half that misses does so because the values were never chosen by anyone. They are provider defaults, control-panel templates, and zone files copied from zone files copied from a Usenet post. Half of a 275-million-domain census running on unexamined inherited configuration is a statement about how the internet is actually operated, whatever any single timer costs.

Who sets these values, if nobody does?

Almost no domain owner has ever typed an SOA retry value. The overwhelming majority of zones get their timers from whoever hosts the DNS: the registrar’s default template, the hosting panel’s zone generator, a managed-DNS provider’s house values. That has two consequences worth spelling out.

The out-of-range half is not 139 million individual mistakes. It is a much smaller number of default templates, multiplied by the customer bases of the providers that ship them. A single provider whose panel writes an out-of-band retry into every new zone contributes millions of rows to our out-of-range column in one stroke. The fix, correspondingly, is concentrated: a handful of template edits at large providers would move this statistic more than any conceivable awareness campaign aimed at domain owners.

The flip side: if you run your own zone file, you are the exception, and you are also the one reader who can act on this in five minutes. Look at your SOA. If retry sits between 300 and 3,600 seconds and expire between one and four weeks, you are in the well-configured half. If not, the change is one line, costs nothing, and the recommended values have been stable since 1996 (industry context).

There is also a quieter modern wrinkle: many large DNS providers run proprietary replication between their servers and treat SOA timers as decorative, publishing whatever constants they like because their sync doesn’t use them. Those zones sit in our out-of-range column while being operationally impeccable. We can’t separate them out from the outside, and we won’t pretend otherwise — it is one reason we frame this as a neglect census, not an outage forecast.

How we measured this

• Source: the August 2026 census round (figures as of 2026-08-16, methodology v9), scanned from our EU measurement infrastructure.
• Population and denominator: 275,073,813 graded domains that returned a readable SOA record with parseable timer values. The census graded 376,928,781 domains in total; the remainder lacked a usable SOA in this cut (lookup failure or malformed record) and are excluded rather than counted as failures.
• What was checked: two timers per domain — retry against a 300–3,600 second band, expire against a 604,800–2,419,200 second (1–4 week) band. These are our methodology’s recommended-range checks, following RFC 1912-style operational guidance (RFC 1912, 1996 — industry context). Refresh and minimum-TTL are checked in the census but are not part of this two-timer cut.
• In/out only: the data records whether each value fell inside or outside its band, not the value itself or which side it missed on. Claims about “too low” versus “too high” are therefore absent above.
• Vantage limits: we read the SOA as any resolver would, from outside. We cannot see whether a provider’s secondaries actually honour these timers or replicate by proprietary means, so out-of-range does not imply operational risk for any given domain.
• Advisory, not protocol-breaking: an out-of-range SOA timer violates no standard and breaks no resolution. The bands are operational guidance. This report measures configuration hygiene, not outages.
• Aggregate only. We publish population-level counts. We never name, grade, or publish data about an individual registrant’s domain.
• Data is stored and processed within the EU.

FAQ

What is a good SOA retry value? Operational guidance (RFC 1912 lineage — industry context) puts retry between 300 and 3,600 seconds: five minutes to an hour. That is long enough not to hammer a primary that just failed, short enough that secondaries re-sync promptly once it recovers. In the August 2026 census, 59.2% of measured domains sat inside that band and 40.8% — 112.2 million domains — sat outside it.

What happens if the SOA expire value is too low? Expire is how long secondaries keep serving the zone after losing contact with the primary. If it elapses, they drop the zone and the domain stops resolving everywhere — the one scenario where an SOA timer causes a real outage. The recommended band is one to four weeks; 38,706,880 domains (14.1% of those we measured) publish an expire value outside it, though our data does not record which side of the band they miss on.

Do bad SOA timers affect my website visitors? Not directly. Resolvers answering your visitors’ queries never consult retry or expire; those timers only govern how your DNS servers sync with each other. The risk is conditional: bad timers change how gracefully your domain survives a primary-nameserver failure. Day to day, an out-of-range SOA costs you nothing — which is exactly why half the internet has never looked at theirs.

Why check SOA records at all if they rarely break anything? Because they are a cheap, honest proxy for maintenance. The timer values in a zone tell you whether a human has ever reviewed its configuration, and in the August 2026 census the answer was no for 50.5% of 275 million domains. Zones that fail this hygiene check are disproportionately the same zones failing the checks that do carry direct risk.

Can my DNS provider fix this for me? Usually they are the only ones who can — most zones inherit SOA timers from the provider’s template, and many panels expose no way to edit them. If you run your own zone file, the fix is one line and five minutes. If you use managed DNS, an out-of-range value in our data most likely reflects your provider’s house defaults, and some large providers deliberately publish non-standard timers because their internal replication ignores them.

How does this compare to other DNS hygiene issues? SOA timer neglect is uniquely symmetric — nearly half the internet lands on each side. Most other hygiene problems we measure are dominated by one outcome: DNSSEC absence is the norm, DMARC enforcement is the exception. With SOA timers, the internet split essentially 50/50 in August 2026, which is a rare finding and emphasises just how much of configuration is shaped by whatever template the DNS provider shipped.

Does this affect cloud-hosted domains differently? Large managed-DNS providers running anycast infrastructure often ignore SOA timers internally and use proprietary sync instead, so out-of-range values are operationally harmless for their customers. The risk concentrates in domains running their own or less sophisticated nameserver infrastructure, where the timers are still live protocol machinery.

What should I check right now? If you manage your own zone file, run a DNS lookup for your domain’s SOA record and verify retry falls between 300 and 3,600 seconds and expire between 604,800 and 2,419,200 seconds. If you use managed DNS, confirm your provider’s replication mechanism. Either way, a failing SOA timer is also a signal to audit everything else in the zone.

What this means

For IT managers and security teams, the SOA timer finding matters most as a proxy for something harder to measure: whether anyone is actively maintaining a domain’s DNS configuration. A zone whose timers have never been reviewed is a zone whose SPF record, DNSSEC chain, and MX routing may also be set-and-forgotten. In the August 2026 census, every domain in the out-of-range half is statistically more likely to fail the checks that carry real security risk. The SOA timer doesn’t cause breaches — it predicts where to look for the configurations that do.

For business owners with multiple domains, the practical consequence is an audit question: when did anyone last look at the DNS configuration for your secondary domains, brand-protection registrations, or legacy properties? Most organisations know the security posture of their primary domain reasonably well. The SOA data suggests that for the rest of the portfolio, the answer is often “never.” A timer set at registration and unreviewed since is the DNS equivalent of a password that was never rotated.

For infrastructure teams evaluating DNS providers, the concentration finding — that a handful of provider templates account for the majority of out-of-range values — means the right conversation is with the provider, not with individual administrators. Asking a managed-DNS vendor whether their default SOA template produces in-range timers, and whether they use those timers internally or override them with proprietary sync, is a worthwhile due-diligence question that most procurement checklists don’t include. The August 2026 census provides the baseline: 49.5% of the measured web has both timers in range. A good provider should be able to tell you which side of that line their defaults put you on.

Data to cite

• “50.5% of measured domains — 138,982,990 of 275,073,813 — carry at least one SOA timer outside recommended operational ranges.” — defaults.exposed August 2026 Domain Security Census (432M domains)
• “40.8% of domains publish a retry timer outside the 300–3,600 second band, covering 112,168,427 zones in the August 2026 census.” — defaults.exposed August 2026 Domain Security Census (432M domains)
• “14.1% of measured domains carry an expire timer outside the one-to-four-week recommended range — 38,706,880 domains.” — defaults.exposed August 2026 Domain Security Census (432M domains)
• “Only 49.5% of the measured web — 136,090,823 domains — keeps both SOA retry and expire timers inside the recommended bands.” — defaults.exposed August 2026 Domain Security Census (432M domains)
• “11,892,317 domains — 4.3% of those measured — fail on both retry and expire timers simultaneously.” — defaults.exposed August 2026 Domain Security Census (432M domains)
• “Among domains with an out-of-range expire value, 30.7% also miss on retry — a zone that gets expire wrong is quite likely to be wrong everywhere.” — defaults.exposed August 2026 Domain Security Census (432M domains)

See where your own domain stands

Your SOA timers are one query away, and they are the least of what we check. Our census grades live domains across 34 externally observable security checks, and most of what a failing domain is missing is free and quick to fix — the barrier is almost never cost, it’s that nobody told the owner it mattered. You can check your domain privately and free, and see exactly which checks you pass.

Check your domain free at defaults.exposed — see whether your SOA timers are in the maintained half or the inherited-default half, alongside all 34 security checks. Takes 30 seconds. No account needed.

Read next: The Internet Security Grade Curve →

Also in this series: The DNSSEC Paradox · The Internet’s Dead Domains

How to cite this report

Press / blog: defaults.exposed (2026). SOA Records: The Internet’s Most Neglected Setting. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/en/articles/soa-records-the-internets-most-neglected-setting

Academic: defaults.exposed. (2026, August 18). SOA Records: The Internet’s Most Neglected Setting. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/en/articles/soa-records-the-internets-most-neglected-setting

In-line citation: (defaults.exposed, August 2026 Domain Security Census, n=275,073,813)

About the defaults.exposed August 2026 Census

The defaults.exposed Domain Security Census is a recurring independent measurement of the public domain namespace. The August 2026 edition scanned 432,127,908 domains between 1–16 August 2026 and graded 376,928,781 of them using methodology v9. Scans are conducted from EU infrastructure. No individual domain, registrant, or business is named in any report. All figures are aggregate distributions. Data is stored and processed within the EU.

Methodology: defaults.exposed/en/articles/domain-security-scoring-methodology-v9 Full census report: defaults.exposed/en/articles/the-state-of-domain-security-2026

Aggregate data only. Data stored and processed in the EU.