- dns-wg - mailman.ripe.net

DNS Related drafts adopted in the IETF.
by Warren Kumari 03 Jun '26

03 Jun '26

Hi there all, At the recent RIPE 92 meeting the IAB presented on "Bridging IETF and RIPE - From Standards to Operations and back". Part of the feedback was that we should share more targeted information, for example that a list of newly adopted drafts and published RFCs. A primary purpose of this is incase you see a newly adopted draft where you feel that you might be able and willing to provide feedback and operational insight. This is a trial run of this process - it's newly published RFCs and adopted drafts in DNS groups. Please let me know if it's actually interesting / of use to you, and I'll see about making it better. I realize that this is just a list of draft names and titles - I had considered also adding the draft abstracts, but that would have made this super long and hard to read… Because this is the first time I'm starting from Jan 1st - if this is useful, future ones would be much shorter… Feedback (including "No, this is just clutter!!!") welcome, W Operations and Management AreaDomain Name System Operations (dnsop) <https://datatracker.ietf.org/wg/dnsop/about/> adopted drafts since 2026-01-01: - draft-ietf-dnsop-delegation-mgmt-via-ddns: Automating DNS Delegation Management via DDNS <https://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-mgmt-via-ddns/> - draft-ietf-dnsop-delext: DNS Protocol Modifications for Delegation Extensions <https://datatracker.ietf.org/doc/draft-ietf-dnsop-delext/> - draft-ietf-dnsop-dnssec-keyrestore: DNSSEC Key Restore <https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-keyrestore/> - draft-ietf-dnsop-rfc9364bis: DNS Security Extensions (DNSSEC) <https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc9364bis/>

5 5

next steps for DNS, Transitive Trust and How Many is Many
by Michael Richardson 22 May '26

22 May '26

I just watched Ondřej Surý's excellent talk about "How many DNS queries does it take to resolve a single domain name?" (I declined to get up to watch live, now I regret missing the interactive part...) Jim Reid asked about turning this into a RIPE document. And Joe Abley noted how the empty cache is not really the static state. My completely unsurprising comment is that the right "goldilocks" number is going to depend, and I think that what we probably need is a way to do reproduceable tests. The observation that bind 9.11 thru .21 have radically different numbers... And I imagine unbound, and windows server's resolver, and dnsmasq, and whatever cloudflare, google, and the other public resolvers use using... each will have different results. Is there also some dependancy on distance to authoratitive resolvers? Certainly, the latency test is done for . and then the queries tend to stick to the best one. And LocalRoot changes this. I've never been quite clear what the behaviour is for other levels. "Easy" for most of the people reading this list to pop-off and start a container or VM or ./named-I-just-compiled and do some measurements. Not sure how I'd test an empty public resolver instance! Whether people like public resolvers or hate them, some portion of people use them, and most zone owners probably want to make sure they aren't tripping up some pathology in one place by optimizing another. So one thing that I think we need is something that explains how to do the tests. Command lines in appendices or better, on a forkable-on-coding-site wiki. Concepts in the document. The next thing I think that we need is then a way (a proceedure, not a tool), given the above, to simulate some kind of failure. Ondřej's reply about how, if I'm running potatocoding.org, and .org servers are all down, then I'm toast, even if I've decided to put an NS in .net/.com and .it. That's relevant, but it's not the whole story. Such broad, high-level outages are now rare, I think. What isn't rare are 2016-style Murai attacks on parts of the infrastructure. I wonder how long teams.office.com takes to resolve if ns3-39.azure-dns.org and ns3-39.azure-dns.info are both down/under-multi-TB/s attack, along with ns3-05.azure.dns.org (where office.com is). The resolver that did more queries, and cached more answers might be ahead... unless the more answers meant that it was more likely to have LRU'ed out some other useful answers. How do I simulate/test that? How do I simulate my resolver being in some other continent? Can I still resolve canada.ca when all our fiber to the US is turned off as part of another trade dispute? (Maybe more relevant to smaller *island* nations!!!) It seems to me that knowing how things degrade (not if, but how) could become an important part of due-diligence. I think someone will need to fund this, even if it's "only" in the form research grants to graduate students. -- Michael Richardson <mcr+IETF(a)sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide ** My working hours and your working hours may be different. ** ** Please do not feel obligated to reply outside your normal working hours **

1 0

Reverse DNS
by Ulrich Wisser 13 May '26

13 May '26

Hello WG, I am looking into reverse delegation. I found RFC 2317 https://datatracker.ietf.org/doc/html/rfc2317 (aka BCP20). Is that really true? Does anyone use ”/” in their delegation names? <- Maybe someone who scans the whole tree could look into this? Does Ripe have a recommendation/BCP on reverse delegation (for non-octet boundaries)? Greetings from rainy Stockholm /Ulrich

6 7

Feedback requested on the selection process of new co-chairs
by Moritz Müller 12 May '26

12 May '26

Dear RIPE DNS-WG, During the previous selection process of a new co-chair (in the run-up to RIPE 91), some discussion sparked offline and online on whether the current process of selecting a co-chair for this working group is still adequate. The current process is described here [1]. We hereby invite the community to provide feedback on the current selection process. Note that the current selection for a new working group co-chair will not be affected by this discussion. Any potential changes to the selection process will only come into action after RIPE 92. You still have until Monday to express your support for the new co-chair. - Moritz Müller for the RIPE DNS working group co-chairs (Ulrich, Yevheniya and me) [1] https://www.ripe.net/participate/ripe/wg/dns/dns-wg-chair-selection-process

9 13

Public ENUM article and RIPE 92 Services WG discussion
by Hisham Ibrahim 12 May '26

12 May '26

Dear colleagues, I wanted to share an article on the current operational status of Public ENUM under e164.arpa. The article is based on a 2026 operational review carried out by the RIPE NCC and looks at the status of current delegations and the questions this raises for the future support of Public ENUM. I plan to present this topic during the Services Working Group session at RIPE 92, where I hope we can discuss the findings and possible next steps with the community. Article: https://labs.ripe.net/author/hisham_ibrahim/operational-review-of-public-en… Best regards, Hisham

1 0

ripe-859 RIPE NCC Statement on RSSAC001v2 "Service Expectations of Root Servers Operators"
by Florian Obser 11 May '26

11 May '26

Dear colleagues, We have published ripe-859 which is our statement on RSSAC001v2 "Service Expectations of Root Servers Operators": https://www.ripe.net/publications/docs/ripe-859/ In this document, you can read our statements corresponding to each of the service expectations for Root Server operators and how we comply with them for k.root-servers.net. Best regards, Florian Obser Principal Engineer, DNS

1 0

Agenda DNS-WG at Ripe92
by Ulrich Wisser 25 Apr '26

25 Apr '26

Dear working group, The preliminary agenda for our meeting at Ripe92 in Edinburgh is ready. 1. Welcome and announcement of the new co-chair 2. DNS, Transitive Trust and How Many is Many, Ondřej Surý 3. Black Holes and Prisoners: Understanding AS112 Deployment Characteristics, Elizabeth Boswell 4. DNS TAPIR POP – Managing Multiple RPZ Inputs, Lars-Johan Liman 5. Overdoing NSEC3 Hurts, Petr Špaček 6. RIPE NCC DNS Update, Florian Obser 7. (Time Permitting) Measuring Resilience of Recursive Resolvers, Maynard Koch A friendly reminder: We are still collecting expressions of support (or opposition) for the new working group co-chair from the mailing list until Monday, 18th May 2026. See you all in Edinburgh or online! Your chairs (Yevheniya, Moritz and Ulrich)

1 0

ENUM (e164.arpa): background, scope, and coordination steps
by Hisham Ibrahim 08 Apr '26

08 Apr '26

Dear colleagues, This message summarises recent discussion regarding ENUM (e164.arpa) and clarifies the scope and next steps. The RIPE NCC has operated the e164.arpa registry for many years under instructions and coordination arrangements established with the ITU-T and IAB. These arrangements, and the operational context for how the registry is run, are described here: https://www.ripe.net/manage-ips-and-asns/dns/enum/iab-instructions/ Recently, a request was raised in the RIPE Database Working Group to support ENUM (e164.arpa) in RDAP for querying the RIPE Database. We noted that RDAP support for ENUM is not currently implemented, but could be added if there is clear interest. We also checked current query patterns and found a few hundred ENUM-related queries per day in DNS and in Database; so low usage, but not zero. Following discussion on the Database WG mailing list, including replies in support, we proposed implementing RDAP support for ENUM. While this is a limited operational change, it was recognised that anything touching E.164 and e164.arpa can raise political questions that go beyond the purely technical. As e164.arpa is directly linked to the ITU E.164 numbering system, the relevant points of contact are typically national administrations and the entities they designate. This led us to consult ITU-T Study Group 2 to clarify the status of ENUM and its usage and needs for ongoing support. ITU-T will ask member states for their feedback and share this with us. ITU-T provides an established and coordinated channel to reach those administrations, and importantly confirm whether any delegating authorities still rely on the service, so our technical decisions are informed by real-world use and help us avoid unnecessary operational risk, confusion, or compliance headaches (including in the context of regulatory frameworks such as NIS2). We are also reaching out to the IAB regarding these operations, which the RIPE NCC performs under its instruction on behalf of the global DNS and Internet community. I am sharing this message with the DNS, Database, Cooperation and RIPE NCC Services Working Group mailing lists to ensure all relevant working groups are informed. If you wish to share thoughts in response, please reply to the thread on the RIPE NCC Services WG mailing list. Best regards, Hisham Ibrahim Chief Community Officer, RIPE NCC

3 5

Co-chair selection: Collecting expressions of support now
by Moritz Müller 19 Mar '26

19 Mar '26

Dear colleagues, I am glad to announce that we have one candidate for the co-chair position that will become vacant at RIPE 92. We will now collect expressions of support (or opposition) from the mailing list until Monday, 18 May 2026, and will announce the results on Thursday, 21 May 2026 during the DNS working group session at the RIPE 92. Please also provide a short statement when expressing your support or opposition. Our candidate is: ***************************************** Name: Marc van der Wal Nominated by: self-nomination Statement by Marc: I would hereby like to nominate myself as a candidate for becoming a co-chair of the RIPE DNS working group. I’ve been working as an R&D engineer at Afnic for almost 4 years now, during which I’ve been involved with many different aspects of DNS operations: DNS testing tools such as Zonemaster or IBDNS, e-mail security with SPF, DKIM and DMARC, fighting abuse, and so on. As a regular RIPE attendee, I’ve been very happy with the way DNS working group sessions have been led during the past few years. I want to do more for the international community and, as a hypothetical co-chair, help keeping the high quality of those working group sessions. I am particularly sensitive to diversity, equality and inclusion as well. Although it would be a first experience in such a role, I am a fast learner, and I know I can count on input and support from fellow chairs, and from colleagues like Sandoche Balakrichenan who co-chaired the IoT working group. ***************************************** Best regards, Moritz, for the RIPE DNS working group co-chairs (Yevheniya, Ulrich and me)

3 2

DNS propagation inconsistencies across European resolvers — observations and data
by Vahid Shaik 09 Mar '26

09 Mar '26

Hi team, I've been investigating DNS propagation behavior across European resolvers and wanted to share some observations that might be useful to the group. When testing DNS record changes (particularly A, AAAA, and MX records) across resolvers in different RIPE member regions, I've noticed significant inconsistencies in how quickly changes propagate — even when TTLs are identical. Some examples: * Records with TTL 300 updated within 5 minutes on Cloudflare (1.1.1.1) and Google (8.8.8.8), but took 15-25 minutes on several ISP resolvers in DE, NL, and FR. * CNAME chains with 3+ levels caused noticeably slower propagation compared to direct A records, particularly on resolvers that don't support aggressive NSEC caching (RFC 8198). * Some ISP resolvers appear to enforce a minimum TTL floor (often 300-600s), overriding the authoritative server's lower TTL values. For anyone investigating similar behaviour, I've found it helpful to query the same record from multiple global locations simultaneously to identify which resolvers are lagging. We built a tool called DNS lookup<https://dnsrobot.net/dns-lookup> that does this at it queries from 20+ server locations in parallel and shows per-location results with response times. Has anyone else on the list observed ISP resolvers in the RIPE region enforcing minimum TTL values? RFC 8767 (Serving Stale Data) seems related, but I'm curious whether this is intentional policy or just aggressive caching implementations. Regards, Vahid

4 5