RIPE 68 DNS Working Group Minutes

You’re viewing an archived page. It is no longer being updated.

RIPE 68 Minutes
DNS Working Group - Session I and II
14 May 2014, 11:00-12:30 and 14:00-15:30
Co-Chairs: Jim Reid, Peter Koch and Jaap Akkerhuis
Scribes: Denis Walker and Emile Aben

Session I

A. Usual Administrivia

Jaap Akkerhuis opened the session and welcomed the participants. He explained the logistics of the small presentation room and the overflow room with audio connection. Jaap asked if there were any comments on the previous minutes and there were none. There were no action items to be reviewed.

B. RIPE NCC Report
Anand Buddhev, RIPE NCC

The presentation is available at:
https://ripe68.ripe.net/presentations/284-AnandBuddhdev_RIPE68_DNS_Update.pdf

Niall O'Reilly, University College Dublin, asked about e164.arpa. Niall assumed that, as nothing was said, it is just working fine. Anand confirmed that the zone just is there and is delegating to various entities, but there are no updates really. Niall pointed out that Malaysia had just joined nrenum.net so there is still some ENUM activity.

Jim Reid asked if there was further information or procedures - requirements, criteria, etc - for those who might be interested in hosting an instance of K Root. Anand said that the RIPE NCC will be trying to identify hosts and potential hosts for this service. This process will start in the next couple of months and the RIPE NCC will be inviting people to come and talk to them. There are some minimum requirements in order to operate such an instance, and these will be made public. Anybody who meets these requirements will be welcome to approach the NCC about hosting an instance of K Root.

Patrik Fälström, Netnod, asked about diversity in operating systems and hardware. Anand said these have been discussed internally. For the operating system, there were the obvious candidates of NetBSD and FreeBSD. However monitoring and hardware support is not as good for these as it is with CentOS Linux, the current platform for K root. He acknowledged that diversity is a good thing. Hardware diversity is also good but more difficult to achieve. Any hardware has to be easily available to hosts and the NCC needs to be able to support it. Anand added that RIPE NCC is happy to talk with anyone about diversity issues for K root.

C. Using DDoS to Trace the Source of a DDoS Attack
Curon Davies, JISC RSC Wales

The presentation is available at
https://ripe68.ripe.net/presentations/276-DDoS.pdf

Jaap Akkerhuis asked if the college had any idea why they were being attacked. Curon said they strongly suspected it was a student doing the attacks. There had been some suspicious VPN traffic, but they could not be 100 per cent sure of the identity of the attacker. Curon also said that another aspect that he had not mentioned is that these techniques can probably be used for spam filtering and a few other options, in addition to just denial of service attacks.

D. Measuring DNSSEC Validation Deployment
Nicolas Canceill, NLnet Labs/University of Amsterdam

The presentation is available at:
https://ripe68.ripe.net/presentations/232-slides.pdf

At the end of the presentation, Nicolas mentioned an issue with bad validation of wild cards with BIND9 in the Debian package. André Chapuis, Swisscom, commented that this wild card issue is a common problem with any stable version of BIND, not just the one in Debian. However André and others only experienced this problem with a particular home version of a router. It worked with others.

Jim Reid said that Nicolas was talking about using the instance of the DO bit to indicate DNSSEC awareness, and Jim has some concerns over this because the BIND9 implementation always sets this on its outbound queries even if it doesn't have a Trust Anchor or has validation turned off. BIND9 even sets the bit when it is unable to do crypto because it was not compiled with the OpenSSL crypto libraries. Jim asked if Nicolas tried to counter that by doing some fingerprinting on the resolving address to find out if this is an instance of BIND that might not be necessarily DNSSEC-aware, or some other DNS implementation that is fully DNSSEC-aware.

Nicolas said that he knew of this distinction. He stated that there is a big difference because they see about 90% of resolvers able to set the DO bit when requested but still only 30% are setting authenticated answers. While there is a big difference between those two categories there was unfortunately not enough time to look more into it and try to categorise it.

E. Measuring DNSSEC from the End User Perspective
Geoff Huston, APNIC

The presentation is available at:
https://ripe68.ripe.net/presentations/164-2014-05-14-huston-dns-measurements.pdf

Warren Kumari, Google, said that Google might collect all sorts of information from users but they don't use any of the DNS data. This is explained in Google's public DNS privacy documents.

Shane Kerr, Dyn, said that it's not as much of a mystery that queries for signed domains come in with the DO bit set more because certain users are more likely going to search for certain domains and sit behind certain ISPs. Geoff replied that it's not quite like that because every user across the planet is getting the same three URLs but what he is finding is that the URL for the signed zone tends to get more where the DO bit was not set.

Olaf Kolkman, NLnet Labs, and Geoff had a discussion about failed queries on name servers and what is returned to the user. Olaf suggested trying to get a good answer if there is one. Geoff said that trying to understand what failed would be even better because you then know what you send back in that good answer. Geoff stated that this is was a cheap remark because his servers will actually return everything that could be the "good answer". However, Geoff added, it's an expensive answer on the authoritative name server.

Nicolas Canceill, University of Amsterdam, said that he is also very worried that Geoff found more DO bits on the secure zone, and asked how much more it was. Geoff responded, saying that it was around 5% but added that he suspects there are more repeat queries going on and that he has yet to complete the full analysis.

An unnamed audience speaker asked if Geoff had looked at what other information was available, perhaps from browser history or caches, adding that this could be a huge global privacy issue. Geoff said he had not looked at this, adding that this exercise would essentially be limited to the information returned from an HTTP GET.

Lars-Johan Liman, Netnod, asked where the work is being done and if the errors were generated in the forwarder or resolver. Geoff said that, no matter where you sit, you actually can't tell whether it is a validating resolver sending questions or whether they are being forwarded.

Eric (audience speaker) was curious about the additional numbers of DO bit queries for signed zones. Geoff said he was looking at the A queries and was actually looking at zones that were signed versus unsigned because he still gets 87% on average whether it's signed or unsigned, that have the DO bit set. Geoff added that there is still some work to be done and the repeats still need to be analysed.

Session II

F. Report from Ad-hoc ccTLD Group
Peter Koch, DNS WG Co-chair

The presentation is available at:
https://ripe68.ripe.net/presentations/298-Koch-Action-67-1.pdf

Stéphane Bortzmeyer, AFNIC, expressed concerned about the formality
of the letter exchange process and proposed to just make it a
"ping-test".

Kaveh Ranjbar, RIPE NCC, clarified that he was thinking of making this a lightweight Memorandum of Understanding (MoU) of half a page to a maximum of a full page. Lars-Johan Liman, Netnod, supported Kaveh in the idea of creating an MoU, stating that a document like this needs text about responsibilities.

Jim Reid clarified the further process. The draft MoU will go to the mailing list for further discussion. Jim expressed his preference to make the MoU into a RIPE Document once the WG has reached consensus on it. Alternatively, it could go through the RIPE Policy Development Process (PDP) if the WG felt that this needed to be documented as a formal NCC policy.

G. Registry Infrastructure Transformation
Michael Daly, Nominet

The presentation is available at:
https://ripe68.ripe.net/presentations/300-Nominet_Transformation.pdf

There were no comments from participants.

H. Google DNS Hijacking in Turkey
Stéphane Bortzmeyer, AFNIC

The presentation is available at:
https://ripe68.ripe.net/presentations/158-bortzmeyer-google-dns-turkey.pdf

Robert Kisteleki, RIPE NCC, mentioned an article from Emile Aben on RIPE Labs as additional background information. Edvard Ayvazyan, Arminco, thanked Stéphane for a brilliant presentation and said that he didn't see much difference in using DNS or BGP for redirecting users to a false destination. He said that maybe political measures are needed against these government actions, or maybe it should be regulated on the ISP level.

Warren Kumari, Google, revealed a method to detect what specific node of Google's public DNS service one is communicating with, which is using a specific command: 'dig @8.8.8.8 o-o.myaddr.l.google.com txt'.

Stéphane responded that RIPE Atlas could be used to query for this name.

Warren mentioned a suggestion from somebody in the Turkish government to blur out an offensive tweet. Warren said this would be very hard because it is an ASCII protocol.

Carsten Schiefner, DENIC, asked if Stéphane or anybody else had seen anything approximating official reactions in any publications about this subject. Stéphane said that he received many replies from the Turkish community, but not from the Turkish government.

Emile Aben, RIPE NCC, indicated that the RIPE NCC didn't receive any official reaction either.

Blake Willis, L33 Networks, indicated that it's a slippery slope to say that this type of network intervention is unwelcome. Personally, he administered captive portals, where he had a legitimate technical use for the same type of intervention. He indicated that it only was the intent that differed.

Olaf Kolkman, NLnet Labs, and Pier Carlo Chiodi (no affiliation) promoted a presentation Olaf was going to give at the Cooperation Working Group: This would be an evaluation of the places and techniques to apply filtering and what the intended and non-intended effects could be if this had to be done.

I. DNSMON Developments
Robert Kisteleki, RIPE NCC

The presentation is available at:
https://ripe68.ripe.net/presentations/247-kisteleki-ripe68-dnsmon.pdf

Peter Koch, DENIC, pointed out that the old DNSMON had anti-DDoS control features, namely a two-hour delay window in which it was only available to members. Peter didn't accept the argument that the new one doesn't have this because the data is available regardless. He argued that the publication and monitoring channel is a crucial part here, too. He encouraged the RIPE NCC to reconsider the decision to not have the two-hour delay window for the new DNSMON.

Peter also commented that he didn't like that the visualisations for the old DNSMON are going to go away, and argued for ways to keep this information accessible. Robert responded that the RIPE NCC could take look at the usage of the old DNSMON system and make a judgement call based on that. He added that it would require some resources to maintain parts of the old system.

Jim Martin, ISC, mentioned that during beta-testing, issues with ISC infrastructure where uncovered, which was really useful. Daniel Karrenberg, RIPE NCC, remarked that the RIPE NCC should not be burdened with maintaining this. He proposed mechanisms to point people in the right direction if they hit URLs that point into the old DNSMON system.

Daniel further responded to Peter Koch's wish to reinstate the two-hour delay. An open question with this is what the criteria would be for access to the undelayed version. If everybody is happy with a delay, then the discussion is moot. If not, the group of people with undelayed access needs to be easily authenticated. He encouraged the group to think about this. Robert added that because DNSMON became a membership service, so it's hard to figure out if somebody is a DNSMON user or not.

Jim asked Robert to send an email to the mailing list about the advantages and disadvantages of delayed and non-delayed versions of DNSMON, specifically related to the management of the software and the ongoing maintenance of the systems that the RIPE NCC want to retire to legacy status. Robert agreed.

Gilles Massen, DNS-LU, agreed with Peter about delaying the visualisation. He answered Daniel's question by saying that delay for everybody is fine because people can go to the raw data if they want. Kaveh Ranjbar said that he wants to revisit keeping the old DNSMON visualisation, at the next RIPE meeting. If there is real traction, it could be kept online. Jim warned against micro-managing the RIPE NCC, urging that the Working Group focus its discussion on requests and needs with regards to functionality and features. Kaveh mentioned an email that had been sent to the working group, where the RIPE NCC asked for feedback on DNSMON planning and timeline, that did not receive any responses. He encouraged people to give feedback.

J. DNS Monitoring Common Practices/APIs Panel Session

Lars-Johan Liman, Netnod
Michael Daly, Nominet
Ondrej Sury, CZ.NIC
Robert Kisteleki, RIPE NCC

Lars-Johan started with the observation that there is an increase in the types of statistics that various groups of people want to have. The DNS Operations, Analysis, and Research Center (DNS-OARC) created an open mailing list and wiki page for this, and the goal is to find common things that all can agree on. Lars-Johan further mentioned a document from the RSSAC to the ICANN Board of Directors that mentions a very basic set of statistics that root-server operators are expected to report publicly.

Michael stated that he would like to see statistics on how reachability for gTLDs look from the outside world, and have the ability to pull that data, and have alerting when something is wrong. It would be handy if it would be anycast-aware.

Jim Reid asked if ICANN is setting any requirements for monitoring, in the light of their operation of gTLDs and emergency registry service backup operations. Michael responded that although there are some requirements, they are not particularly specific right now. They are more in terms of response times as opposed to the specific data.

Robert said that the RIPE NCC can add an independent external view of how a particular DNS service performs. Status checks were recently introduced in RIPE Atlas, as a means to do alerting. For now, they are just ping measurements. For this functionality i.e. DNS measurements there would need to be expert opinion/comment on how to conduct that exactly.

Keith Mitchell, DNS-OARC, stated support for RIPE Atlas on behalf of DNS-OARC. He said that another way of monitoring root and TLD DNS servers was DNS-OARC's TLDmon facility.

Jim asked the panel about statistics from the actual name server software itself. Lars-Johan responded that what they were looking for a common set of counters and common understanding of what they mean. That would allow for comparison between different software, and different views like external traffic or instrumentation inside the name server. He wanted calculations to be performed at a local site because it scales for large deployments. Michael indicated that they used a blend of monitoring a server inside a node, external probing and agents on the name servers themselves.

Matthijs Mekking, NLnet Labs, mentioned dnstap, which was presented at the DNS-OARC meeting. He specifically asked if the dnstap representation format would be a good basis for the effort currently under discussion. Lars-Johan said that he saw it there for first time and was unable to respond right now. He made the point that it would important to avoid reinventing the wheel. Mark McFadden, Interconnect, argued for flexibility in the scope of this data set. Lars-Johan clarified that he sees a difference between a format for sharing information, and minimal requirements for collection, and further explained the special role that the root-server operators have here.

Jim Reid thanked people for taking part in the panel, as well as the speakers, audiovisual support, RIPE NCC staff, chat monitor and stenographer. He thanked those in attendance and closed the session.

RIPE Forum

The RIPE Forum is an additional way to participate in RIPE community mailing list discussions using a web-based interface rather than an email client.

Check out the forum