DNS Working Group Minutes - RIPE 88
Date: Wednesday, 22 May 2024, 09:00-10:30 (UTC+2)
Chairs: Doris Hauser, Moritz Müller, Willem Toorop
Scribe: Michela Galante
Status: Final
View the video recordings
View the chat logs
View the stenography transcript
Welcome and New Chair Selection
Doris Hauser welcomed the audience and announced the re-election of Moritz Muller as co-chair of the DNS Working Group. He was joining remotely this time because of the most important of the priorities: a new baby. The Working Group congratulated Moritz on the new arrival to the family.
DNSSEC Bootstrapping Support in Knot DNS 3.3.5 and in PowerDNS
Peter Thomassen
The presentation is available at:
https://ripe88.ripe.net/wp-content/uploads/presentations/76-RIPE-88-Implementation-Status-of-DNSSEC-Bootstrapping.pdf
Peter Thomassen gave an update about DNSSEC Bootstrapping Protocol, which aims to automate and simplify the process of adding SDS records to parent zones for DNSSEC validation. The draft has passed the IETF last call and is close to being published.
There were no questions or comments.
DELEG Updates
David Lawrence
The presentation is available at:
https://ripe88.ripe.net/wp-content/uploads/presentations/75-RIPE-88-DELEG-Updates.pdf
Dave Lawrence presented about DELEG, a project aimed at improving DNS delegations by enabling new features and facilitating encrypted DNS protocols more seamlessly. DELEG, short for "delegations," proposes an extensible parent-side record to specify name server attributes. A new IETF Working Group is proposed to focus on DELEG. The group will first create a requirements document before drafting specific solutions. The ongoing work aims to enhance DNS protocol efficiency and security while considering community feedback and alternative approaches.
Jim Reid said that it was important to clarify that you don’t need to always go through the full IETF process of having a Working Group-forming BoF before setting up a Working Group. The BoF in Brisbane was successful and constructive enough for the IETF leadership to agree to go straight to forming the working group once the charter is in place.
He also stated another concern – that once the Working Group meets for the first time, there might be overlapping or competing ideas and it will be a challenge for the Working Group chairs to trade off the competing balances as far as the future of DELEG is concerned.
Dave thanked Jim. He added that in addition to GitHub, it would be good to see operators implementing this and showing up once in a while. Seeing useful adoption on a relatively short time frame is valuable even if the old method of delegations is likely to be around for a while.
Jim said that the mailing list should be used and not GitHub.
Dave said he agreed in the case of this document.
Jim added that this was going to have significant repercussions on DNS infrastructure and the IETF is going to need a more considered approach towards deployment and implementation. DoH was done and dusted in one meeting and had several implications. It would be good to have a better understanding of what we are getting into beforehand.
DNS Update from the RIPE NCC
Martin Pels
The presentation is available at:
https://ripe88.ripe.net/wp-content/uploads/presentations/9-RIPE-NCC-DNS-Update-RIPE88.pdf
Martin Pels shared an updated from the RIPE NCC mentioning the ongoing work on the AuthDNS core site in Tokyo, new AuthDNS hosted nodes added since RIPE 87 and providing an overview of actions taken after a recent outage. He also asked the working group to share feedback about the proposal to shut down ns.ripe.net, with a proposed timeline to stop updates by 1 July 2024 and shutting down the service entirely by January 2025. He asked for feedback via the mailing list.
There were no questions or comments.
Studying DNS Energy Consumption
Sandoche Balakrichenan
The presentation is available at:
https://ripe88.ripe.net/wp-content/uploads/presentations/77-RIPE88_22May2024.pdf
Sandoche Balakrichenan presented a study about DNS energy consumption. The aim of the study, which nobody did before, is to understand the environmental impact of DNS.
Sandoche highlighted the motivation behind the study, which includes corporate social responsibility and technical curiosity regarding the increasing encryption in DNS traffic and its impact on energy consumption.
Preliminary measurements were conducted at the authoritative server and resolver levels. They used watt meters to measure energy consumption per second and software probes to generate DNS traffic for analysis.
Lars-Johan Liman, Netnod, acknowledged the importance of the study and also the challenges
in obtaining useful results due to the complexity of variables involved. He added that if the community didn’t start working on the problem there would be no appreciation for the difficulties involved. He also pointed out that the study is based on a certain set of assumptions, so that should be made clear. He also stated that this would help build a better picture of energy consumption.
Sandoche agreed that the study was preliminary and therefore there were several assumptions. Further research and maturity were necessary.
Alex Lemer commented that evaluating CO2 equivalence at the query level is interesting but it doesn’t take into account the hardware purchased, which has the capacity to carry out more actions. Even if the footprint of a query is reduced, the footprint of the overall system doesn’t reduce. He said that the entire system should be evaluated on a macroscopic scale rather than each query or use at the microscopic side of reducing the query.
Sandoche agreed that consumption depends on hardware, the resources used, the energy source etc. under Scope 1. Under Scope 2 though, there are assumptions, if, for example, in the future there are name minimisations in the DNS to reduce traffic and perhaps even servers which are overprovisioned. These are all hypotheses, so there is a need to dig further.
Comparing RIPE DNS Resolver BCP Recommendations With Actual Resolvers
Shane Kerr, Dave Knight and Babak Farrokhi
The presentation is available at:
https://ripe88.ripe.net/wp-content/uploads/presentations/65-RIPE-88-Review-of-DNS-Resolver-Recommendations.pdf
The session concluded with a panel moderated by Shane Kerr, IBM, with Babak Farrokhi, Quad9, and Dave Knight, Vercara - Ultra DNS. Each panellist represented a company operating large-scale DNS resolvers and shared insights on the recommendations made by the task force.
The purpose of the panel was to compare the RIPE DNS Resolver Best Common Practice Task Force recommendations with real-world implementations. The discussion covered several topics around DNS implementation and best practices at their organisations.
The panellists discussed the pros and cons of running multiple DNS resolver implementations for increased security against vulnerabilities versus the operational complexity it introduces. Dave was more in favour of a single implementation while Babak was in favour of the multiple implementations.
Jim Reid, rtfm llp, disagreed with Dave’s opinion and thinks that a single implementation brings a big business risk for Ultra DNS.
Dave replied that he didn’t want to teach people to run an anycast service but those running a small enterprise network could benefit from the document. It was important for them to think about the bigger picture before making a decision.
Jim agreed with Dave pointing out that people need to think about the reputational and financial cost if their DNS goes down.
Patrick Scheck (SC-IT) agreed and added that it was important to have competent people who could handle multiple implementations.
The next topic of discussion was deployment options, choosing between bare metal and cloud.
The panellists compared the benefits and challenges of deploying DNS resolvers on bare metal versus using cloud services, considering factors like performance, control, and availability in different geographical locations. Dave’s organisation uses Cloud services but not one of the Big Five. In Babak’s organisation they chose for their own virtual machines, on their own metal.
The discussion then moved to the use of IP Anycast for achieving high availability across multiple locations and the technical implementations employed by the panellists’ organisations.
They addressed the privacy and operational implications of supporting ECS. The document itself does not provide direction but Shane adds to it that the more widely distributed your edge is the less useful ECS becomes.
Patrick Scheck, SC-IT, adds that the same is true if you are at the other end of this spectrum and concentrated in one place: you don't need ECS then because there is no impact.
The panellists shared their strategies for implementing RPKI to enhance route security, highlighting the importance of both publishing and validating signed ROAs.
David Lawrence, Salesforce, emphasized that many security issues blamed on DNS are actually related to route hijacks. They supported the use of RPKI for its role in mitigating such risks, highlighting its importance beyond DNS alone.
The panellists also discussed the adoption of encrypted DNS transport protocols such as DNSCrypt, DNS over TLS (DoT), and DNS over HTTPS (DoH), with insights into the increasing demand for encrypted DNS traffic and the importance of NSID for identifying DNS resolver nodes, especially in Anycast deployments.
The panellists also questioned the adoption of DNS cookies as a lightweight security measure against reflection and amplification attacks.
Babak mentioned Quad9's support for DNS cookies, offering users the choice to enable them.
Dave expressed interest in enabling DNS cookies but noted that it hadn't been prioritised yet at UltraDNS.
Ondřej Surý, ISC, said it was important to ensure that systems don't break if they receive DNS cookies, regardless of whether they support cookies themselves.
Willem Toorop thanked the Working Group for their participation and concluded the session.