DNS Working Group Minutes - RIPE 87

Wednesday, 29 November 2023 09:00 - 10:30 (UTC+1)
Chairs: João Damas, Moritz Müller, Willem Toorop
Scribe: Antony Gollan
Status: Final

Kick Off and Welcoming the New Co-Chair

João Damas welcomed attendees and announced there was consensus that Doris Hauser should be the new chair to replace him when his term ended at this meeting. Willem presented João with a farewell gift in recognition of his many years supporting the WG and the wider RIPE community.

DNSSEC Non-Deployment. What Can Be Done?

Edward Lewis

The presentation is available at:
https://ripe87.ripe.net/presentations/21-DNSSEC-Non-deployment.-What-can-be-done.pdf

After 25 years of DNSSEC deployment, relatively little progress had been made. Edward had been looking at this problem for a few months and considering whether the issue might be more to do with the protocol itself rather than some shortcoming on the part of network operators. Many of the features of DNSSEC were a product of the networking environment of the 1990s and various assumptions that were made at the time. To make the protocol more deployable, it needed simplicity, clarity, and needed to be more stable in terms of the number of revisions being made (among other factors).

Rob Carolina, Internet Systems Consortium, asked which problem they were trying to solve here. They were in an era in which 95% of traffic was going over TLS and so if most of the user community had an authentication solution at the application layer, he wondered how many operators would want to make a significant investment in securing DNS.

Edward said in terms of what DNSSEC should be solving, ultimately they wanted a computing base that was secure for whatever the upper protocols were. People wanted to use things like DANE and wanted to secure the DNS that way, regardless of whether something was for the web.

Rob said that was a good explanation of what some members of the technical community wanted, but he wasn’t hearing which unfulfilled need at the end user level was being met by this security solution. He knew why TLS was successful but wasn’t sure what would drive this effort.

Edward said DNSSEC was like seatbelts in cars. Most people didn’t want to use them but they knew they would save lives in an accident. It was obvious that DNSSEC was not going to have much value to end users; he said he would discuss this with Rob directly.

Lars-Johan Liman, Netnod (via Meetecho), thanked Ed for his presentation and said much of this was spot on. He wanted to caution about involving EPP in the DNS circus because that was adding another Swiss army knife to the one they already had. Mean Time To Repair (MTTR) was also an important part of this. However, perhaps in the future this would work as things increasingly did with cars today – i.e. the DNS would become a black box that was too complex for people to repair themselves and they would need specialists when something broke.

Jim Reid, Freelance Consultant, said he thought the economic incentives for deploying DNSSEC were completely perverse. The operator didn’t receive any benefit for deploying/signing their zones, it was everybody else who benefited. This made it hard to make a business case for deployment. In some cases the operator was even adding new risks to their enterprise and this was probably why only two or three of the largest websites had highly secure DNS. Maybe they needed to contact some of these people and ask what was happening, and why they hadn’t deployed it yet. He also thought the ongoing tweaks to the protocol happening at the IETF might be giving the impression that it was not stable enough.

Edward said that was fair. The lack of business case was why they had this problem. He was now trying to tease out whether it would be easier to deploy by focusing on the technology itself rather than the business case.

Peter Hessler, OpenBSD (via Meetecho), said he’d been running DNS for around 20 years, often working in operations for smaller companies with few resources that didn’t have anything to do with DNS. One of the issues he found was that his zones were entirely in text files served by BIND or NSD (or another). They were very static zones and only changed every few years. Doing DNSSEC on top of this was very complicated because you didn’t have a database to keep your new DNSSEC info signed in. In a lot of places there were zone files on each authoritative server that you edited manually, and of course doing DNSSEC there was painful. Another issue was that often he had zero access to the registrar, since this was typically owned by the CFO who paid the yearly fee but didn’t know or care what DNSSEC was.

Edward said this was very true. None of this existed 20 years ago and he thought they needed to recognise the scaling from Peter’s experience up to the major players.

João said these were good points. What they had now was the second version of DNSSEC after the first one was theoretically perfect but completely unworkable, even for technical people.

Introducing DELEG

Dave Lawrence

The presentation is available at:
https://ripe87.ripe.net/presentations/61-DELEGations.pdf

Dave gave an overview on DELEG, which was one of the proposals that had come out of the last IETF hackathon, where a brainstorming session had proposed thinking big on DNS evolution. There was initial support from a broad cross-section of the DNS community, though there was still a lot they needed to test and discuss.

Niall O’Reilly, RIPE Vice-Chair (via meetecho) asked if this was a better idea than the NS records that took so much time to chase out of the TLD zones.

Dave said one of the big things that had come up in the brainstorming wishlist was that they wanted to have separate NS records with a different parent-child relationship. Having the same type of RS set in both the parent and child led to a lot of problems. By being only a parent-side record like DS, DELEG should solve a lot of those problems.

João said he saw the need for this, but they had just discussed Swiss army knives and there were other records that had become part of the DNS recently that could be configured along different parameters. He asked if this was something to keep in mind.

Dave said that it was. One of the slightly limiting factors was that it wasn’t completely arbitrary. There was a service binding parameters registry which indicated what the values were. The service binding document also specified how those parameters were meant to be interpreted. It was a numeric registry with a text represented but you were limited by having to go through some process to get to the registry so it wasn’t the case that anybody could throw anything in there.

Erik Vyncke, CISCO, asked if this needed a BoF and a WG as it was a big topic.

David said they’d discussed this with the DNSOP Chairs already. They had a channel on the DNS-OARC’s Mattermost that had a few dozen people from all across the DNS discipline in there. So far it seemed like they might get DELEG through DNSOP but then the much bigger job of pursuing the BHAGs (Big Hairy Audacious Goals) would probably warrant a BoF – DNSOP had a lot on its plate and this was a big enough effort to warrant its own WG.

Erik asked what would happen if the information given in the AAAA records was different from that in DELEG.

Dave said that was actually one of the considerations that was considered a feature. For example, you could give dot addresses that were completely separate from your legacy DNS addresses. The operator could build separate infrastructure for pursuing them so the glue records that might come through the regular legacy delegation were not necessarily expected to be consistent. There was a separate question as well – if you provided offloading in the child and the record was desynchronised from the parent, was that an issue? His position was that it didn’t matter, but that was something to take further in DNSOP or wherever the discussion would be held.

DNS Resolver Best Common Practice Task Force Update

Shane Kerr

The presentation is available at:
https://ripe87.ripe.net/wp-content/uploads/presentations/65-RIPE-DNS-Resolver-Recommendations-TF-RIPE-87-DNS-WG-edition.pdf

Shane gave an update on the work of the DNS Resolver BCP TF, which had formed in light of greater attention being paid to the idea of having European public DNS resolvers. They were working on a BCP document that was intended for the operators of DNS resolvers as well as for users when choosing a revolver operator. It was not intended as a checklist or something that could be used for certification. They were planning to review feedback from the TF before publishing this as a RIPE Document.

Tamas Csillag, PCH, noted that Shane had referenced the EU and said this was confusing as Quad9 was based in Switzerland. He wasn’t sure if Shane had been referring to the EU as a region or the European Union specifically.

João said the fact that Quad9 was based in Switzerland had come up in terms of how far the EU could reach, because being based in Switzerland didn’t stop companies being sued for privacy issues or for access to data. This had triggered their thought process but the goal of the document was to be generic so it could be applied anywhere.

Žarko Kecić, RNIDS, said he supported their work as it was important at all levels. He hoped there would be more public resolvers rather than simply using Google for 50% of the Internet. He had seen ISPs with poorly configured resolvers and thought this would help; it would be good to have a list of recommendations that could be followed.

IETF DNSOP Update

Tim Wicinski

The presentation is available at:
https://ripe87.ripe.net/wp-content/uploads/presentations/76-DNS-and-IETF-and-RIPE.pdf

Tim gave an update on the work of the DNSOP WG inside the IETF. Currently they had 15 WG documents at various stages, so there was a lot of work being done. The WG had published seven RFCs in the last two years.

João said he was always kind of surprised at how much work was being done, because at one point someone had said everything was done and now they could focus on the operations, but that now seemed like one of those ‘hold my beer’ moments because since then they had been rewriting the whole thing.

DNS Update from the RIPE NCC

Anand Buddhev RIPE NCC

This presentation is available at:
https://ripe87.ripe.net/presentations/78-RIPE87_DNS_Update.pdf

Anand Buddhev gave an update from the RIPE NCC. Their AuthDNS expansion had been affected by COVID supply-chain delays but they had received all the hardware they needed earlier and this would be deployed in Tokyo next year. There had been a ripe.net DNSSEC outage on 1 November, which was the result of human error which increased the TTL to ten days instead of one. All the details were in a postmortem which had been sent to the DNS WG mailing list. Anand noted that you could now type in a reverse DNS zone into RIPEstat which would trigger a reverse DNS check using Zonemaster. In future RIPEstat would be the sole interface to use the RIPE NCC’s Zonemaster instance.

Lars-Johan asked if they were using the default things for Zonemaster. He found it was a useful tool but it seemed to be packed with people’s opinions. He asked if warnings would prevent people from having their reverse zones delegated.

Anand agreed that Zonemaster came with certain opinions about how DNS should be. They had deviated from the default policy for a few things that their users thought were too strict. Notices and warnings did not prevent reverse DNS delegation. They only prevented delegation in the case of errors or critical messages in Zonemaster, as they indicated the zone might be broken or not functioning properly.

End of session.