Skip to main content

DNS Working Group Minutes - RIPE 92

Date: Thursday, 21 May, 11:00 ‐ 12:30 (UTC+1)
Chairs: Moritz Müller, Ulrich Wisser, Yevheniya Nosyk
Scribe: Karla Liddle-White
Status: Draft

Welcome and announcement of the new co-chair

The presentation is available at:
https://ripe92.ripe.net/programme/meeting-plan/sessions/98/MQCJJ8/

Moritz Müller, DNS working group co-chair, welcomed everyone to the session. He announced his departure and announced that Marc van der Wal would be a new co-chair. His fellow co-chairs Ulrich and Yevheniya thanked Moritz for his time and contribution to the working group and RIPE community.

DNS, Transitive Trust and How Many is Many
Ondřej Surý, ISC

The presentation is available at:
https://ripe92.ripe.net/programme/meeting-plan/sessions/98/ATVK7Z/

This talk was about delegations and how many DNS queries it takes to resolve a name. Ondřej explained how each type of delegation affects the resolver query chain when the cache is cold. He showed how combining delegations across different TLDs and different domains increased the strain on the DNS ecosystem, and how combining this with CNAME chains can lead to an explosion of transitive trust dependencies that resolvers must chase before returning a single answer.

Questions

Joe Abley, Cloudflare, thanked Ondřej for the presentation and questioned whether the advice was general advice, noting that the measurements were made on an empty cache scenario while most caches quickly become populated, and subsequent queries are quicker. He suggested that operators may need to weigh this against other risks, such as dependency on a single registry, registry operator, or set of credentials.

Ondřej said that he had expected this question and responded that it wouldn’t matter how many providers a domain used if a specific TLD went down, since access to that delegation would be lost regardless of whether the domain was .org, .com or .it. For this reason, Ondřej had recommended using one or two well managed providers. He also added that his concerns hadn’t been limited to cold caches, saying that attacks can force resolvers to clear or fill caches.

Libor Peltan, CZ.NIC, thanked Ondřej for his research and illustrative numbers and said that the local root was becoming more of an industry standard so could he redo the same research with local root enabled and that it would be good to see this for the TLD specifically.

Ondřej said that he could do new research with those numbers.

Jim Reid, unaffiliated, said that it was interesting research and whether it was worth writing up as a RIPE Document.

Ondřej responded that while he had written a blog on the subject fifteen years prior, he would be happy to make it into a document.

Black Holes and Prisoners: Understanding AS112 Deployment Characteristics
Elizabeth Boswell, University of Glasgow

The presentation is available at:
https://ripe92.ripe.net/programme/meeting-plan/sessions/98/RATHUR/

AS112 is a volunteer-run anycast DNS deployment that responds to junk

queries, i.e. leaked queries from internal networks, which should have been handled locally. Elizabeth presented a series of RIPE Atlas measurements to answer some unanswered questions around who runs the AS112 servers, where they are located, and whether they effectively capture leaked queries.

Questions

Robert Kisteleki, RIPE NCC, noted that RIPE Atlas provides similar measurements and visualisations for the root zone and suggested that similar measurements could be implemented for AS112, with RIPE Atlas producing graphs, maps and visualisations of the data.

Elizabeth thanked Robert for the offer and said that if the community was interested it would be good to set this up.

Lukas Rose, Düsseldorf University, asked Elizabeth if she’d considered the possibility of possible biases in her study such as the geographical spread of RIPE Atlas probes being less abundant in Asia and Africa.

Elizabeth replied that they had considered it which is why they’d tried to mitigate this by using open recursive resolvers as vantage points, which were in theory more widely distributed. She added that this had limited success as, for example, she wasn’t able to use a lot of data from China from this.

Lars-Johan Liman, Netnod, said he’d found her work very interesting and suggested that there were opportunities for them to improve their own routing based on the findings. He also asked if the measurement data was publicly available as he saw value in comparable studies.

Elizabeth said that she had made the code publicly available but since responses contained personal information, she hadn’t made the data public. She added that he could email her and she would send links to the RIPE Atlas measurements.

Florian Obser, RIPE NCC, said that they run the AS112 node in Amsterdam and that he could not see how there would be a bias in RIPE Atlas for that node just because the RIPE NCC runs both. The node is only connected to AMS-IX and he supposed a lot of networks were up there.

Elizabeth replied that that was the main reason since it’s good connectivity.

DNS TAPIR POP – Managing Multiple RPZ Inputs
Lars-Johan Liman, Netnod

The presentation is available at:
https://ripe92.ripe.net/programme/meeting-plan/sessions/98/ZV8NA8/

Liman introduced the audience to DNS TAPIR Policy Processor (POP), an open source tool for improving cybersecurity monitoring using pseudonymised DNS data.

DNS traffic can reveal valuable information about malicious activity but access to DNS query data is often restricted due to user privacy. POP allows operators to analyse pseudonymised DNS data for cybersecurity monitoring and threat mitigation without these privacy issues.

The project is based on transparency with open source software components and the project consists of two parts; TAPIR Edge which runs alongside resolvers and removes sensitive information before forwarding and TAPIR Core, an analysis platform that combines sets of data from multiple sources and feeds threat intelligence observations back to users.

Questions

Thijs van den Hout, SIDN, asked whether operators of TAPIR Edge software were vetted or whether anyone could join the project.

Liman said that they reserved the right not to work with people but they were not vetting people as such.

Jim Reid, unaffiliated DNS geek from Glasgow, asked how the effectiveness of the filter data compared to commercial filtering services already in place.

Liman responded that it hadn’t yet been tested against commercial services but commercial security companies had been involved in the project.

Peter Hessler, maintained that it was worth having a vetting system in place or a method of removing bad actors.

Liman thanked Peter for the advice.

Benno Overeinder, NLnet Labs, asked whether it would be possible to run a TAPIR code in the Netherlands or whether any country could run their own core. He also asked how many resolvers they had on the project.

Liman said that it was possible to operate multiple cores in different locations and they hoped to develop the system so that they could have several core systems.

Matthijs Mekking, ISC, said that when something was blocked for resolvers, did they have a reason to give to the client request.

Liman said that it was not something they had been working on yet.

Overdoing NSEC3 Hurts
Petr Špaček, Internet Systems Consortium

The presentation is available at:
https://ripe92.ripe.net/programme/meeting-plan/sessions/98/HW3LJG/

Petr gave a presentation on misconceptions when it comes to NSEC3 and spoke on the danger of configuring NSEC3 with too many iterations which can lead to excessive work on authoritative servers and resolvers. Through a series of tests involving random subdomain attacks, he demonstrated that increasing the number of iterations can dramatically reduce DNS server performance. He concluded that NSEC3 should only be used in limited circumstances and that its benefits are often outweighed by its operational costs and encouraged operators to consult Best Current Practice RFC 9276.

Questions

Shane Kerr, IBM, asked whether they would be reporting in the resolver.

Petr said that no one had asked for that yet but they would be code error reporting.


RIPE NCC DNS Update
Florian Obser, RIPE NCC

The presentation is available at:
https://ripe92.ripe.net/programme/meeting-plan/sessions/98/WVWVFD/

Florian provided an update on the RIPE NCC’s DNS team and recent operational developments including progress in expanding the network of hosted AuthDNS instances and ongoing work on service automation, including mechanisms that automatically withdraw service prefixes when DNS servers are unable to operate correctly.

The team also completed a renumbering of AuthDNS IPv6 infrastructure and have been preparing for ISO 27001 certification, reviewing risk management processes, updating operational documentation and formalising business continuity procedures.

Finally, Florian announced the publication of RIPE 859, which documents K-root's compliance with the expectations set out in RSSAC001 for root server operators.

Questions

Dave Knight, Nominet, said that K-root did not have a covering prefix from the beginning and pointed to an email by Randy Bush in October 2025 for a description of some of the unintended consequences of running local nodes.

Florian thanked him for his comment.

Measuring Resilience of Recursive Resolvers
Maynard Koch, TU Dresden

The presentation is available at:
https://ripe92.ripe.net/programme/meeting-plan/sessions/98/8TCKVY/

Maynard provided a short presentation on a new ISOC project to measure DNS resilience. He explained that this was an independent study on the measurable practices of the KINDNS framework, as well as other important DNS resilience practices. He said that currently had 100,000 resolvers in the database and asked the audience to get in touch if they would like to contribute data to the project.

There were no questions.