DNS Working Group Minutes - RIPE 91
Date: Thursday, 23 October, 11:00 - 12:30 (UTC+3)
Chairs: Moritz Müller, Yevheniya Nosyk, Willem Toorop
Scribe: Karla Liddle-White
Status: Draft
Welcome and announcement of the new co-chair
Willem Toorop, NLnet Labs, welcomed everyone to the DNS Working Group session and announced his upcoming departure from the working group as his term comes to an end at RIPE 91. He introduced Ulrich Wisser as a new co-chair from RIPE 92 in Edinburgh.
The presentation is available at:
https://ripe91.ripe.net/programme/meeting-plan/sessions/41/NSCCYE/
A BCP on Hyperlocal Root
Jim Read
The presentation is available at:
https://ripe91.ripe.net/programme/meeting-plan/sessions/41/GH987G/
Jim Reid spoke on the best common practice on the hyperlocal root. He spoke on the idea that local resolving servers would have a copy of the root zone so they can answer queries rather than touching the root servers themselves to start the resolution chain. He said that we can't continue relying on the current root server system infrastructure as it is. He continued that we need more defence and depth to the whole system, and part of that chain is going to be more copies of the root zone available to those that need it.
Jim said that this would solve some geopolitical problems because there are numerous places in the world where they would like to have a root server and can't but if there was a copy of the root zone on the local resolving structure, they would have a root server for all intents and purposes.
There were no questions.
TLD Resilience in the Light of Signature Validity Constraints
Ulrich Wisser, ICANN
Ulrich examined how DNS zone timing configurations, particularly SOA expire times and DNSSEC signature lifetimes, affected the resilience of DNS infrastructure during outages.
The presentation is available at:
https://ripe91.ripe.net/programme/meeting-plan/sessions/41/8HJDVN/
Questions
Shane Kerr, IBM, observed that not everyone used the standardized zone transfer mechanism and SOA expiry would not cause an immediate outage. Even after the expiry time passes, he said that DNS resolvers could still answer queries using cached records, so the zone may continue to appear available for some time until those caches expire.
Jim Reid asked how they defined reasonable values. He added that he tried to do this 15 years ago but they could try and document what the term reasonable meant. Jim said it was helpful that it was documented so they could make informed decisions.
Ulrich said that he agreed that they needed that and that he worked for ICANN in engagement and talking to operators, he said many of them would be happy for guidelines.
Lars-Johan Liman, Netnod, said that on slide 13, there was a slight divergence and there seemed to be a very clear regularity there. He asked if they’d tried to figure out if these TLDs were operated by the same registry or possibly by the same type of software.
Ulrich said that he worked for ICANN and could not comment on that.
Anand Buddhdev, RIPE NCC, suggested that authoritative name servers could track the earliest DNSSEC signature expiry within a zone and expire the zone based on that, rather than relying solely on SOA timer values, as a way to help prevent related failures.
Ulrich agreed.
Niall O’Reilly asked if he had a script or whether there were tools which would make it easy for a small operator, a micro‑enterprise or a private individual to do this.
Ulrich said that the code was on his GitHub.
An online participant asked whether the affected TLDs were using zone transfers to distribute zone data, and Ulrich Wisser responded that while many do not, a significant number do, making the issue relevant for those operators.
UA: XoT in practice
Dmytro Kohmanyuk, Hostmaster.UA
The presentation is available at:
https://ripe91.ripe.net/programme/meeting-plan/sessions/41/YNMKZK/
Dmytro presented on deploying DNS over TLS (XoT) in the .UA infrastructure, describing its integration into a three-layer DNS architecture and the use of Knot DNS and Knot Signer. He highlighted configuration considerations, the continued use of TSIG alongside TLS, and the decision to avoid CA-based validation in favour of pre-shared trust. Operational experience showed limited issues, mostly resolved, with XoT currently used within internal and trusted environments. Future work includes exploring CA validation, multi-signer setups, and potential use of QUIC for zone transfers.
Questions
Dave Knight, DigiCert, shared operational experience from deploying XoT on a TLD platform, noting similar design decisions, including the use of BIND for distribution, TLS with TSIG authentication, and no fallback to port 53 internally.
Dmytro said that by referencing different XoT modes and a preference for avoiding the added complexity of full CA-based validation, he highlighted the operational challenges of introducing additional cryptographic dependencies.
Éric Vyncke, Cisco, thanked Dmytro and said that it was good to see the work of the IETF working group being deployed in reality. He added that there's an RFC 9250 which is about DNS over QUIC and he thought there was a zone transfer in it.
Niall also asked about alternative name server implementations that integrate key and signature provisioning, and whether these had been evaluated compared to Knot.
Dmytro acknowledged this and said that features such as catalogue zones could support provisioning, but indicated this was a broader topic for further discussion outside the session.
DNS TTL Upper Limits in Practice
Shane Kerr, IBM NS1 Connect
The presentation is available at:
https://ripe91.ripe.net/programme/meeting-plan/sessions/41/7Q99SU/
Shane presented measurements of DNS resolver TTL caps using RIPE Atlas, showing that most resolvers limit TTLs to one day or less, with common caps at one hour, six hours, 12 hours, and one week. He concluded that very high TTLs provide little benefit, advising zone operators to keep TTLs at one day or below, while noting variability in resolver behaviour.
Questions
Ondrej Sury, ISC, said that there was no recommendation for the recursive resolver implementers so BIND has a default of one week for the maximum TTL. He asked whether they should make it one day.
Shane responded that he didn’t have strong recommendations here.
Jiří Menšík, CESNET, z.s.p.o., had two questions for Shane. The first one was whether he had looked for, or found, any differences of how things were cached depending on where or which level in the tree, so were TLDs cached in a different way than enterprise level.
Shane said that he didn’t look at different levels of hierarchy but he would be surprised if this was the case. He also added that he hadn’t looked at different types such as address records which may have different limits than other records. He provided the example that Cloudflare may have a one hour cap for address records.
Jiří continued by asking whether Shane had a notion of how many different implementations he had been looking at.
Shane said that it would be possible that version.BIND or NSID queries might return something interesting. He added that he hoped somebody would do it and let them know the result.
Jiří also asked Shane how to set the TTL values for the reverse zones since they were used by mail servers who have their own record source with their own cache and for this, it would make sense to have one TTL.
Shane responded that TTL values for reverse zones should depend on how frequently records change, but added that setting TTLs above one day offered little benefit and could increase operational complexity.
Jiří also suggested using longer TTLs for reverse DNS in mail server contexts to support anti-spam checks.
Shane acknowledged the idea and noted that service-specific TTL best practices could be reasonable, particularly if mail operators use their own resolvers, but said it was unclear how effective this would be in practice.
Ondrej Sury, ISC, argued against using different TTL values for specific services such as mail servers, stating that TTLs above one day provide no practical benefit and do not meaningfully improve performance or resilience, and therefore consistent, lower TTLs are preferable.
Shane agreed that mail systems were generally designed to tolerate outages and delays, and said there was uncertainty about whether longer TTLs would provide any real benefit for mail-specific use cases.
Ondrej asked whether the work had been taken to the IETF and noted existing TTL values in the root zone.
Shane said the research had not yet been presented to the IETF and said that high TTLs in the root zone may offer limited practical benefit.
Ondrej welcomed the data-driven approach and its value in informing TTL best practices, which Shane encouraged others to build on.
RIPE NCC DNS Update
Anand Buddhdev, RIPE NCC
Anand provided an update on RIPE NCC’s hosted DNS services, reporting continued expansion of K-root (128 instances) and AuthDNS (27+ instances), including new deployments in several global locations. He outlined ongoing IPv6 renumbering to improve anycast operations and testing, progress in updating related services and ccTLD configurations, and the replacement of ageing DNSSEC signer hardware. He also described the transition from legacy DNS statistics tooling to a Prometheus and Grafana-based system for improved monitoring and visualisation.
The presentation is available at:
https://ripe91.ripe.net/programme/meeting-plan/sessions/41/UZSLH9/
Questions
Jim Reid, speaking for himself, asked whether the RIPE NCC would continue monitoring queries to old IPv6 addresses after their decommissioning.
Anand confirmed that query traffic would be captured using PCAP tools for some time after shutdown, allowing analysis and potential follow-up if significant traffic persists.
Ondrej Sury, ISC, suggested collaborating on standardising DNS statistics output across different name server implementations to integrate directly with Prometheus, reducing reliance on DSC.
Anand explained that DSC is currently used to normalise differing outputs from multiple DNS software, but agreed that a unified, multi-vendor approach to standardised metrics would be valuable and worth further discussion.