- dns-wg - mailman.ripe.net

Help us identify community-driven sessions for the November 11 following OARC 47
by Jerry Lundström 23 Jul '26

23 Jul '26

Hi, We are planning to offer a full day of community-driven sessions on Wednesday, 11 November, immediately following the main OARC 47 workshop. We'd like to hear from the broader DNS and Internet operations community. What topics or activities would you like to see happen, and what could be realistically organized—or that you would be interested in helping organize? Recent workshop feedback included interest in tutorials and short training sessions, working group and interest group side meetings, BOFs, hackathons, tool demos, and operator round-tables. To make this useful, we need more than topic suggestions: we are especially looking for people who are willing to host a session, help organize one, or point us toward someone who has already expressed interest in leading a specific project, topic, or discussion. This additional day will not require a separate registration fee for OARC 47 attendees. We have conference rooms available from 08:30–16:30 on the 11 November. Each room can accommodate up to 15 participants and includes basic boardroom AV. The day is currently planned around the following schedule: - 08:30–10:00 session block - 10:00–10:30 morning coffee break - 10:30–12:00 session block - 12:00–13:00 lunch - 13:00–14:30 session block - 14:30–15:00 afternoon coffee break - 15:00–16:30 session block Sessions may use one or more blocks depending on the format, organizer availability, and room scheduling. Possible formats include: - hands-on tutorials - OARC tools training or demos - software demos - BOFs - hackathons - focused working group or interest group meetings (for instance standards or BCP discussions) - operator round-tables - "help me brainstorm this problem" sessions If you are willing to host something, help organize something, or connect us with someone who may be a good lead for a specific session, please complete the following form by *24 August 2026 23:59 UTC*. Form Link <https://zfrmz.com/arOnEOkvgGa9UoqvwOGn> The form also includes a small section for attendee interest, but our immediate priority is identifying sessions with a potential host, organizer, or named point of contact. Submitting a proposal does not guarantee a confirmed room or time slot. OARC staff will review responses and follow up to confirm session details, timing, room fit, and any support needed. We hope this additional day can create space for practical work, smaller-group discussions, and hands-on knowledge sharing that can be difficult to fit into the regular workshop agenda. Best, DNS-OARC

1 0

OARC 47 Call for Contribution
by Ulrich Wisser 18 Jul '26

18 Jul '26

This workshop will be a hybrid event. Date - 09-10 November 2026 Location - Vancouver, British Columbia Times - approximately 10:00-17:00 PDT (Local time PDT is UTC -7; note that British Columbia has opted to remain on PDT all year round) Deadline for Submissions - 2026-08-24 23:59 UTC https://indico.dns-oarc.net/event/58/abstracts/ All DNS-related subjects and discussion topics are welcome although we're particularly keen to hear more about operational and security related experiences, best practices and practical advice; both for newcomers to the DNS arena and those who have been around for longer who want to learn more about new features and opportunities to improve resilience, security and privacy. (These topics we think will complement the usual high-quality data-based research submissions we always hope to receive!) If you have something interesting to share with the community that lies outside of the focus above, please don't be put off - if it's good, we'll be happy to include it. You can also contact us directly at submissions(a)dns-oarc.net<mailto:submissions@dns-oarc.net> if you would like to ask about the suitability of a potential presentation submission topic. If you'd like to offer a talk, but are not quite sure what to pick, here's a non-exhaustive list of ideas: 1. Operations & Deployment · Configuration management, deployment processes, and interoperability experiences. · Tools, tips, and making effective use of DNS software features. 2. Performance, Resilience & Scaling · Provisioning, load-balancing, and planning for resilience. · DNS performance management, efficiency improvements, and metrics. · Monitoring infrastructure: log pipelines, analytics, and anomaly detection. 3. Security, Privacy & Policy · DoS attacks, DNS abuse, DNSSEC signing and validation. · Privacy considerations, for example: encrypted transport, qname minimization, data anonymization. · Relevant global and regional policies, legislation, and compliance. 4. Research & Innovation · Data-driven testing, measurement, and analysis. · New protocols, protocol extensions, and next-generation namespace management. 5. Lessons & Learnings · Outage experiences, recovery stories, and cautionary tales · For further details please see https://www.dns-oarc.net/oarc47 ..., for the DNS-OARC Programme Committee Ulrich

1 0

[RIPE 93] DNS WG Call for Presentations
by Yevheniya Nosyk 10 Jul '26

10 Jul '26

Dear colleagues, It might still seem far away, but RIPE 93 in Sofia is approaching. The RIPE 93 meeting will be held from 26 to 30 October 2026. Our working group session is currently scheduled for 29 October at 11:00 local time, but please note that this may still change. This email is our official call for topics for the DNS Working Group session. Since RIPE 91, all plenary and working group proposals have been submitted through the same system, Pretalx. Please submit your proposals by 15 September 2026 using the following link: https://pretalx.ripe.net/ripe-93/cfp. Alternatively, you may still send your proposals directly to us at <dns-wg-chairs AT ripe.net>. If you are using Pretalx, please pay special attention to the following fields: • Talk type: "Lightning talk" or "Talk" • Track: "DNS WG" • Duration: Time in minutes for the presentation and Q&A. This may differ from the default duration for the selected talk type. You can find more information about the Pretalx system here: https://ripe93.ripe.net/present/how-to-submit-a-proposal/ As usual, participation in the working group session is possible both in person and remotely. We plan to send out the first round of notifications at the end of September 2026. Cheers, RIPE DNS Working Group co-chairs (Marc, Ulrich, and me)

1 0

Nominet DNS Fund
by Lizzie Griffiths 25 Jun '26

25 Jun '26

Hello, We are excited to share that the Nominet DNS Fund is now open for its second application window, with £650,000 available to support open source projects that underpin the internet's core infrastructure. Following a strong first round, this latest funding window brings increased investment and greater flexibility. We are looking to support both new and existing projects, including one-off initiatives and longer-term work that improves the sustainability of essential DNS technologies. If you are working on open source DNS software, tooling, or infrastructure - this is an opportunity to secure funding for work that is critical but often under-resourced. Successful projects from the first round span DNS libraries, testbeds and operational tools used by registries around the world, highlighting the real-world impact of this community. Applications are open now and will close on 17th August at 9am BST. Find out more and apply on the Nominet website: https://nominet.uk/our-impact/nominet-dns-fund/

1 0

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