January 2026 - dns-wg - mailman.ripe.net

[RIPE 92] DNS WG: Call for presentations
by Yevheniya Nosyk 29 Jan '26

29 Jan '26

Dear colleagues, It might still seem far away, but RIPE 92 in Edinburgh is approaching. The RIPE 92 meeting will be held from 18th to 22nd May 2026. Our working group meeting is currently scheduled for 21st May at 11:00 am, but please note that this may still change. This e-mail is our first official call for topics for the DNS working group session. From RIPE 91 onwards, all plenary and working group proposals can be submitted through the same system, Pretalx. Please submit your proposals by 9 March 2026 using the following link: https://ripe92.ripe.net/present/call-for-presentations/. Alternatively, you may still send your proposals directly to us at <dns-wg-chairs AT ripe.net>. If using Pretalx, please pay special attention to the following fields: • Talk type: This field is not relevant to us. Select any option you like. Instead, make sure that you fill in the time you will need for your presentation, including Q&A, in the "Duration" field. • Track: Make sure that you select "DNS WG" • Duration: See "Talk type" above You can find more information on the Pretalx system here: https://ripe92.ripe.net/present/how-to-submit-a-proposal/ As usual, both in-person and remote participation in the working group is possible. We plan to send out the first round of notifications at the end of March 2026. Cheers, Yevheniya on behalf of the RIPE DNS Working Group co-chairs (Moritz, Ulrich and me) -- Yevheniya Nosyk, Ph.D. Cybersecurity Researcher https://korlabs.io

1 0

Co-chair selection for the RIPE DNS working group
by Moritz Müller 26 Jan '26

26 Jan '26

Dear DNS-WG, In accordance with the chair selection process we announce that the term of one of our co-chairs (Moritz Müller) will expire at the upcoming RIPE Meeting (RIPE 92, Edinburgh) and we would like to invite volunteers, or nominations for someone to become a co-chair of the DNS working group. Anyone may volunteer, and anyone may be nominated by someone else (we will check with the person for acceptance). I (Moritz) reached my final number of terms and cannot volunteer any more for a new term. I had a great time as a co-chair and I would like to thank the community for their support in the last years. To volunteer yourself or nominate someone else, please send a mail to <dns-wg-chairs AT ripe.net> before end of Sunday 15 March 2026 (UTC). Please DO NOT send your volunteer/nomination to the DNS WG mailing but rather the dns-wg-chairs mail alias. It would be helpful for candidates to give some words as to why they think they ought to be a co-chair, what new ideas, or improvements they might bring, and so on. We will publish the list of volunteers, along with anything the volunteers wish to include with their nomination, to this mailing list on Monday 16 March 2026. Discussion and support (or opposition) for each candidate can then be offered on the list. At the DNS working group session at RIPE 92, Ulrich and Yevheniya hope to announce consensus based on the mailing list discussion. Timeline Monday, 26 January 2026 This call for volunteers posted to the dns-wg mailing list Sunday, 15 March 2026 Deadline for volunteers/nominations Monday, 16 March 2026 List of candidates and call for support posted to the mailing list Monday, 18 May 2026 Deadline for showing support for candidates/volunteers on the mailing list Thursday, 21 May 2026 DNS WG session at RIPE 92 (still subject to change) References The RIPE working group chair job description is included in ripe-692: https://www.ripe.net/publications/docs/ripe-692 The DNS working group chair selection process is documented here: https://www.ripe.net/participate/ripe/wg/dns/dns-wg-chair-selection-process We have 3 co-chairs so the term is 3 years. As always, please feel free to reach out to any of the co-chairs directly, to us as a group at dns-wg-chairs AT ripe.net, or discuss this or any other any relevant topic on this mailing list. -- Moritz Müller for the RIPE DNS working group co-chairs (Ulrich, Yevheniya and me)

1 0

AuthDNS anycast cluster IPv6 renumbering completed
by Anand Buddhdev 15 Jan '26

15 Jan '26

Dear colleagues, During RIPE 90 in May 2025, we announced that we would renumber our AuthDNS anycast cluster's IPv6 addresses, to ease various operational aspects of this service. The renumbering is now complete. The previous /48-sized prefix has been withdrawn completely, and most of the clean up work is done. We are in the process of returning this address space to the RIPE NCC's pool of unallocated address space. Regards, Anand Buddhdev RIPE NCC

1 0

Seeking advice: API-friendly authoritative DNS stack for a domain reseller platform
by v0 01 Jan '26

01 Jan '26

Hi DNS WG, I’m looking for advice from operators who run authoritative DNS at scale. I’ve been building a domain reselling platform for ~2 years. Today, we manage customer DNS zones via the individual registrar/provider APIs (multiple upstreams). Operationally it’s painful: high/variable latency, inconsistent semantics, and unpredictable failures. Long-term, we’d like to operate our own authoritative DNS service (geo-distributed, e.g. ns1/ns2/ns3) and have customer domains delegate directly to our nameservers. The challenge: I’m struggling to find a “right-sized” authoritative DNS stack that is API-first (or at least automation-friendly) without having to build an entire DNS control plane from scratch. What we’re looking for: - Clean, automatable zone + record lifecycle (create/retrieve/update/delete) via API or well-supported automation interfaces - Preferably open standards / minimal vendor lock-in - DNSSEC support What we’ve considered so far: - BIND / NSD / Knot: solid, but “no native API” makes dynamic management feel awkward at scale or require custom workarounds (which often rely on consistency from provider-side which tends to cause issues) - PowerDNS: seems powerful, but may be heavier than we need (happy to be convinced otherwise) - Managed (Cloudflare / NS1 etc.): technically great, but cost/lock-in doesn’t fit our reseller model, also, we are fans of self-hosting in the Hetzner Cloud Questions for the group: 1. If you were starting this today, what stack (authoritative server + control/management layer) would you recommend for this kind of product? 2. Are there established open-source “control planes” or patterns people use (e.g., RFC2136 dynamic updates, catalog zones, GitOps-style zone generation, database-backed auth, etc.) that work well in practice? 3. Any pitfalls you’d warn about when turning authoritative DNS into a customer-facing service? Happy to share more details (expected zone counts, update rates, deployment model) if that helps. Thanks a lot in advance, Sebastiaan

1 0