Hello everyone Was wondering if anyone who has worked across root servers ops could answer about the expire value in SOA record: dig @a.root-servers.net. . soa +short a.root-servers.net. nstld.verisign-grs.com. 2026050800 1800 900 604800 86400 So 604800 (1 week) would actually make the DNS replicas to stop resolving if disconnected for an extended period of over a week from their master? Unsure of tech root operators use to replicate zone (if other than traditional zone transfers) but many of auth DNS providers these days use database backend and thus in their case primary is DB primary, secondaries are DB replicas but from DNS software point of view all are just the masters and expire value is just ignored. Is that also true for some or all or none of the root DNS servers? Thanks. -- Anurag Bhatia anuragbhatia.com
On 5/8/26 09:44, Anurag Bhatia via NANOG wrote:
o 604800 (1 week) would actually make the DNS replicas to stop resolving if disconnected for an extended period of over a week from their master?
Unless the server stores a negative/expiry result for the domain, which I don't think any major implementations do, it should just fall back to its hints file which would allow it to bootstrap itself again the same as upon initial startup. In that respect, I don't think the SOA expiry is a big deal. You want it to be long enough that normally-running systems won't constantly keep having to resolve it or fall back to their hints, but you also don't want it super long so that they won't pick up actual changes (which allow long-lived servers to keep running even if their hints file is out of date). A week seems reasonable in both respects. I assume that replication of the root zone among the actual root servers is handled by means other than simple AXFR/IXFR. -- Brandon Martin
On 2026/05/08 20:45, Brandon Martin via NANOG wrote:
I assume that replication of the root zone among the actual root servers is handled by means other than simple AXFR/IXFR.
Actually, no - it is all just AXFR, and each RSO transfers from a private set of servers managed by the Root Zone Maintainer (Verisign). IXFR doesn't work well for the root zone where RRSIGs are regenerated twice every day. Ray (Director of DNS Operations, ISC - F-Root)
On 2026/05/08 14:44, Anurag Bhatia via NANOG wrote:
Hello everyone
Was wondering if anyone who has worked across root servers ops could answer about the expire value in SOA record:
dig @a.root-servers.net. . soa +short a.root-servers.net. nstld.verisign-grs.com. 2026050800 1800 900 604800 86400
So 604800 (1 week) would actually make the DNS replicas to stop resolving if disconnected for an extended period of over a week from their master? Unsure of tech root operators use to replicate zone (if other than traditional zone transfers) but many of auth DNS providers these days use database backend and thus in their case primary is DB primary, secondaries are DB replicas but from DNS software point of view all are just the masters and expire value is just ignored.
Is that also true for some or all or none of the root DNS servers?
It's true for the F-root nodes that I run. Note however that as soon as the zone expires and the server at a site starts returning SERVFAIL, a watchdog script detects this and withdraws the Anycast BGP announcements for that site. Ray
Of more interest is probably how the SOA values affect your and other random operators’ resolvers. The BCP is for resolvers to AXFR the root zone and not query the roots for recursive resolution. What values make sense for that? On Tue, May 12, 2026 at 1:55 PM Ray Bellis via NANOG <nanog@lists.nanog.org> wrote:
On 2026/05/08 14:44, Anurag Bhatia via NANOG wrote:
Hello everyone
Was wondering if anyone who has worked across root servers ops could answer about the expire value in SOA record:
dig @a.root-servers.net. . soa +short a.root-servers.net. nstld.verisign-grs.com. 2026050800 1800 900 604800 86400
So 604800 (1 week) would actually make the DNS replicas to stop resolving if disconnected for an extended period of over a week from their master? Unsure of tech root operators use to replicate zone (if other than traditional zone transfers) but many of auth DNS providers these days use database backend and thus in their case primary is DB primary, secondaries are DB replicas but from DNS software point of view all are just the masters and expire value is just ignored.
Is that also true for some or all or none of the root DNS servers?
It's true for the F-root nodes that I run.
Note however that as soon as the zone expires and the server at a site starts returning SERVFAIL, a watchdog script detects this and withdraws the Anycast BGP announcements for that site.
Ray
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/7YXVTSBD...
On 2026/05/13 02:53, Crist Clark wrote:
The BCP is for resolvers to AXFR the root zone and not query the roots for recursive resolution. There is no such BCP. There is a specification for how to this, but it does not have (IETF) BCP status, not least because providing downstream AXFR service to resolvers is not a formal part of the root server system's function.
Ray
The BCP is for resolvers to AXFR the root zone and not query the roots for recursive resolution. There is no such BCP. There is a specification for how to this, but it does not have (IETF) BCP status, not least because providing downstream AXFR service to resolvers is not a formal part of the root server system's function.
and, as has been discussed a number of times, here there be dragons randy
participants (5)
-
Anurag Bhatia -
Brandon Martin -
Crist Clark -
Randy Bush -
Ray Bellis