DNS Working Group Minutes - RIPE 89

Date: Wednesday, 30 October 09:00 - 10:30 (UTC+1)
Chairs: Doris Hauser, Moritz Müller, Willem Toorop
Scribe: Alvaro Vives

Status: Draft

View the video recordings
View the chat logs
View the stenography transcript

Welcome

Willem Toorop mentioned the recent DNS-OARC meeting that took place right before the RIPE 89 meeting and invited people to attend Thursday’s BoF on DNS resolver recommendations.

Announcing the Next DNS Hackathon
Vesna Manojlović, RIPE NCC
T
he presentation is available at:
https://ripe89.ripe.net/wp-content/uploads/presentations/82-vesna-announcing-DNS-hackathon-2025.pdf

Vesna let everyone know about the upcoming Stockholm DNS Hackathon, scheduled for March 2025.

There were no questions or comments.

DarkDNS: Revisiting the Value of Rapid Zone Update
Raffaele Sommese, University of Twente

The presentation is available at:
https://ripe89.ripe.net/wp-content/uploads/presentations/55-DarkDNS-RIPE-1.pdf

Raffaele Sommese showcased a project on quickly identifying new TLDs to help combat domain abuse, with a call for collaboration from ccTLD and gTLD operators to fight domain names abuse and making sharing information easier.

Michael Richardson (Sandelman Software) asked about some domains withdrawal and if they showed up in another registrar very quickly.

Raffaele answered that sometimes it happens, although not frequently. The research was only for three months, so no extensive data. He said that they will look into that, but also remarked it's difficult to monitor all the TLDs, because a global view is needed and there are domains like .com or .net that are more difficult to monitor.

Michael Richardson asked if the data sharing issues are privacy or commercial concerns.

Raffaele answered that the EU privacy law is the biggest concern because some people think that the domain names are privacy identifiable. If you have your name and surname indeed the domain name, they considered it for GDPR, some TLD of course use also the commercial advantage of knowing the list of domain names for providing service for example for trademark protection or for example for new branding or things like that. He added that they were both a concern, but that if we stood up like a framework where people could really collaborate with each other, we could see for instance this data should not be used for commercial purposes.

Pavel asked Raffaele what did he see as the way forward and what would be the practical steps to make it happen. He shared an anecdote about the phishing domains they saw, for a data set of less than a year. Pavel was in favour of the proposal, that it would be a step forward, and offered help. He considered that the main problem was the speed, it's too slow.

Raffaele agreed, and considered that one snapshot a day is not enough to detect abuse. He said that the reason for his presentation at RIPE 89 was to get a couple of ccTLDs or gTLDs that are interested in participating in an experiment where they can set up agreement for data concern, demonstrate the effectiveness of sharing to better fight abuse and maybe also convince ICANN to participate.

Update of the HU Registry DNS Zone Generation and Signer Systems
Tamás Csillag, PCH
The presentation is available at: https://ripe89.ripe.net/wp-content/uploads/presentations/89-HU-signer-upgrade-at-ripe89-v1.pdf

Tamás Csillag from PCH explained the system they had for DNSSEC and its limitations and the new one they have used to substitute it and its advantages.

There were no questions or comments.

Extended DNS Errors - Unlocking the Full Potential of DNS Troubleshooting
Yevheniya Nosyk, Université Grenoble Alpes

The presentation is available at: https://ripe89.ripe.net/wp-content/uploads/presentations/66-presentation.pdf

Yevheniya Nosyk shed light on the Extended DNS Errors (RFC8914) and its potential for spotting misconfigurations in open DNS resolvers. They wanted to know if they are implemented and deployed. They made bad DNS requests to several open DNS resolvers and collected the extended error codes, checking if they showed the same behaviour or not. They tried to see if they had misconfigurations or limited capabilities.

Conclusion was that they are available and can be helpful.

An audience speaker asked said that it was very good to see the extended error codes have been so quickly and widely adopted. He also noted that the error codes are not signed or secured, so they can be useful and informative for debugging and reporting, but can't be 100% trusted and people should not rely on them to make any protocol decisions.

Shane Kerr (IBM) asked if the different error codes from different software/resolvers can cause operational problems for the users.

Yevheniya answered that it can be confusing and that it took time to dig into the differences and check why exactly they saw those. She stated that it's important to notice that different didn't mean incorrect, but more level of detail.

Roy Arends (ICANN) said that the error code 16 mentioned in the presentation as an error was not, there was a reason. He said that they did an interesting work and presentation. He also expressed his opinion about a previous answer from the presenter about the convenience of different implementations standardise the same error code in the context of error reporting. He said that in the context of error reporting it might be interesting to see different answers from different resolvers, and combined this may actually make sense and give information of what's going on, that the different error codes can amplify each other.

Yevheniya answered that if they were going to receive those reports, careful interpretation would be needed.

Roy Arends agreed with her and asked if she had come across any DNSSEC error reporting.

Yevheniya answered that she had not.

Peter van Dijk (PowerDNS.com) referenced the data about Quad 9 in the presentation, that was a mix of Unbound and powerDNS data. He explained that that happens because Quad 9 is running two versions of resolvers so you can get different error codes from each one, and they have asked them to be more consistent with what Unbound does.

The Rise and Fall of an Undelegated Domain: The Impact of a Global Misconfiguration
Roy Arends, ICANN

The presentation is available at: https://ripe89.ripe.net/wp-content/uploads/presentations/91-RIPE-roy-arends.pdf

Roy Arends from ICANN detailed a case on domain "magnitude", a metric based on counting unique hosts making queries instead of amount of queries for a TLD. They found a bug in Microsoft Teams that caused a sharp spike in the "magnitude" in queries for the reserved TLD “scloud.”. The problem was fixed.

Jim Reed (rtfm) greeted the presenter for an interesting and well done presentation. He said that we have seen a trend of big vendors using a domain name for internal/own management purposes and affecting the whole DNS system and the root servers in particular. He stated that perhaps it's time for SSAC to come up with a strong recommendations, particularly for big vendors, to not do these kind of things. He said that it's a dangerous thing to do specially for large applications with a huge number of users.

Roy Arends agreed with Jim.

Cathy Almond (ISC) said that they didn't get any reports of that or didn't hear of any. She asked if while that was going on, resolver operators saw a lot of queries that were responded with NXDOMAIN.

Roy answered that there were not too many queries but a big amount of hosts, so it went off the radar for an individual resolver operator. He said that he didn't think that resolver operators would have the ability to detect it, because internally the amount of queries would not be very high, and some of those queries, like in the case of Microsoft Teams and cloud would look benign.

Sebastian Jürges (Bundesdruckerei) said that usually no one would defend Microsoft, and asked if it was maybe just a typo while Microsoft was migrating their services to Microsoft cloud.

Roy said that he had no answer for that, that it could be, but he would expect them to know what they were doing. He said that .internal is the domain that should be used.

Suzanne Woolf (Public Interest Registry (.ORG)) said that there has been a discussion about these .internal kind of domains. She said that there is a document that explains where all these domain names come from and advises people about ad hoc names.

She said that it would be good to have in that document that appropriating top-level domain names is never a good idea, and that if you have to do it you have to look closely at what you are doing and why. She also stated that making that document an RFC will only reach to RFC readers. She asked the audience and presenter to think about creating such a document with that recommendation and where to have it.

Michael Richardson (Sandelman Software Works) talked about using top-level domain names for internal purposes together with split horizon and what a bad idea that is. He said that we only need that document for junior engineers to use it with their managers to tell them that doing that is a bad idea.

DNS Update from the RIPE NCC
Anand Buddhdev, RIPE NCC

The presentation is available at:
https://ripe89.ripe.net/wp-content/uploads/presentations/90-RIPE-89-DNS-Update.pdf

Anand Buddhdev closed the session with an update on RIPE NCC’s DNS services, including plans to retire the secondary DNS service on ns.ripe.net and calls for additional AuthDNS hosts to bolster redundancy.

Mauricio Vergara Ereche (DigitalOcean) asked Anand if they had detected any vanity name being used for the name server that you are retiring, someone who was reusing your APLs on queries that they haven't seen.

Anand answered that they were not aware of any. When they looked at all the zones that were using RIPE NCC's service they just referenced ns.ripe.net.

Jim Reed thanked Anand and his colleagues for the great job running this DNS infrastructure. He also asked if for new instances of AuthDNS they were still favouring instances within RIPE region or if they were taking a more open minded approach

Anand answered that the RIPE NCC is open to host new instances anywhere, and that they tried to look for regions that are not very well served.

Tamas Csillag (PCH) asked if the service they are retiring is only for reverse zones or also for forward zones.

Anand answered that only for reverse DNS zones. For some LIRs that had a large amount of IP addresses, like a /16 for IPv6 or a /32 for IPv6, that were getting the service from the RIPE NC. Those are the ones they were retiring.

Willem Toorop thanked the working group for their participation and closed the session.