April 2014 - dns-wg - mailman.ripe.net

Announcing changes to DNSMON
by Vesna Manojlovic 09 Sep '14

09 Sep '14

Dear colleagues, The DNS Monitoring Service (DNSMON) has been providing a comprehensive, objective and up-to-date overview of the quality of various global and regional DNS operators' services since 2003. As announced last year by Kaveh Ranjbar in the RIPE Labs article, "Future of RIPE NCC Technical Services", we are in the process of integrating DNSMON within RIPE Atlas, using RIPE Atlas anchors as vantage points. The beta version of the new DNSMON will be available next week, when we will invite you all to try the new service and provide your feedback. In the meantime, we wanted to let you know about some of the changes in the new DNSMON service: New interactive graphs that will allow you to zoom in on interesting details, such as servers, vantage points, and time intervals. Support of TCP queries. Data delay for non-DNSMON users will not be replicated because the measurements performed by RIPE Atlas anchors for the new DNSMON are public measurements. Therefore, the results will also be publicly available. Server-side generated RRD graphs will not be migrated, as the client-side visualisations provide a comparable replacement. However, the existing service will keep working in parallel and decommissioning plans will be discussed with the community. In the meantime, the graphs and data from the old system will still be available. We will publish a RIPE Labs article with more details when the new service becomes available next week. We’re confident the new DNSMON will continue to meet your needs and hope you'll be pleased with the new features. Please stay tuned for more information. Kind regards, Vesna Manojlovic Senior Community Builder Measurements Community Building RIPE NCC

8 14

Timeline for Phasing Out the Old TTM-based DNSMON
by Romeo Zwart 23 Apr '14

23 Apr '14

Dear colleagues, A new article is available on RIPELabs, the "Timeline for Phasing Out the Old TTM-based DNSMON": https://labs.ripe.net/Members/romeo_zwart/copy_of_proposed-time-lines-for-p… We invite your feedback about our planning before Tuesday, 15 April, to the DNS Working Group Mailing List <dns-wg(a)ripe.net> or to myself directly <romeo.zwart(a)ripe.net>. After the deadline has passed, the responses received will be summarised to the DNS Working Group Mailing List, along with a decision based on the feedback provided. Romeo Zwart GII Services Manager RIPE NCC

2 1

[Dnsmon-test] DNSMON beta update
by Massimo Candela 10 Apr '14

10 Apr '14

Hi all, We reached another great amount of improvements on the new DNSMON, especially for stability and user interaction. Some of them are reported in the following lines: - a full screen mode has been introduced; - we continued to improve the time navigation and time perception (e.g. by hovering the “get last data” button a sliding menu allows you to select the last 5 hours, 1 day, 1 week, and 1 month); - the embed code is now more flexible (e.g. the exact widget dimensions can be specified, alternatively the widget will automatically optimise them); - some improvements in the user interaction (e.g. the selection of cells is now more intuitive and precise and the flickering during interaction has been removed); - improved the quality and readability of the JSON. Regards, Massimo

1 0

RIPE67 minutes
by Jim Reid 02 Apr '14

02 Apr '14

Apologies for the delay in circulating these. Please let me know if you have any comments or corrections. Thanks. # # $Id: minutes,v 1.2 2014/04/02 15:03:52 jim Exp $ # DNS Working Group Date: 16 October 2013, 11:00-12:30 and 14:00-15:30 Co-Chairs: Jim Reid, Peter Koch Scribes: Chris Buckridge and Denis Walker Session I A. Administrative Matters Jim Reid opened the session, welcomed participants and reminded them that all proceedings were being webcast. He noted that the draft minutes from the RIPE 66 session had recently been posted. There were no objections to the draft and the minutes were adopted. B. ENUM WG Announcement Carsten Schiefner, DENIC eG The presentation is available at: https://ripe67.ripe.net/presentations/239-RIPE-67-ENUM-Status.pdf There was no discussion. Jim noted that the remaining four presentations looked at related issues and would be considered as part of a wider-ranging discussion in the DNS Working Group. C. PMTU for better IPv6 Performance Willem Toorop, NLnet Labs The presentation is available at: https://ripe67.ripe.net/presentations/230-pmtud4dns.pdf There were no questions. D. DNS over TCP analysis Geoff Huston, APNIC The presentation is available at: https://ripe67.ripe.net/presentations/112-2013-10-16-dns-protocol.pdf Shane Kerr, Internet Systems Consortium (ISC), asked for some clarification regarding Geoff's graph on "time to resolve a name", specifically regarding the zero seconds resolution. Geoff noted that he is looking at the time between the first query for a name and the last query for that name, and a single query is zero seconds. Jim asked whether it was clear, when talking about TCP failover, if it was broken firewalls or issues with the DNS software causing problems. Geoff noted that he had looked at what percentage had "naked SYNs", and it looks like the TCP-blocking rate is remarkably small (<1%). He added that there’s no sign of systematic blocking by resolvers that query authoritative name servers. Jared Mauch of NTT Communications noted that he has considered, as part of the open resolver project, doing a TCP 53 scan, and wondered whether people would consider this useful. Geoff was not sure that such a study would provide information worth the trouble of conducting the study, however Bill Manning, ISI, speaking from the audience, said he believed it would be valuable. Bill noted that he had looked at this issue in 2009 and at that time they looked at the impact of query on one address family (IPv6) and response on a different address family (IPv4). Geoff noted that his experiment was deliberately conducted all in IPv4. Bill noted that, running an authoritative name server, the response, when given in a different address family, would not necessarily match the request, and encouraged looking at this in a future experiment. E. Defeating DNS Amplification Attacks Ralf Weber, Nominum The presentation is available at: https://ripe67.ripe.net/presentations/133-RW-DNS-Amplification-RIPE67.pdf Kostas Zorbadelos (OTE SA) noted that his organisation had been hit by this attack and they were able to mitigate the effects by filtering and rate-limiting. He also asked if Ralf had a solution for defeating these attacks. Ralf noted that his company does sell a software solution that can be used in this way. Shane Kerr noted that having the servers limit the reply rate based on size is a good idea, but that people don't have reply rate limiting (RRL) turned on by default because it can be quite confusing for an administrator, as it can cause your server to act in ways you're not expecting. He suggested that if the community sees these attacks as being very widespread, it's possible to switch RRL on by default. Ralf suggested that this decision should remain in the operator’s hands, especially as it may result in dropping legitimate traffic. There were no further questions. F. UDP Fragmentation/PMTU attack mitigation Tomáš Hlaváček, CZ.NIC The presentation is available at: https://ripe67.ripe.net/presentations/240-ipfragattack.pdf There were no questions for Tomáš. He was then joined on stage by the previous two speakers for a panel discussion. G. Open discussion of C, D, E & F Jim Reid noted that Shane Kerr discussed potentially using some sort of rate-limiting solutions. Shane responded that the goal was actually to control the amplification factor, the idea being to target this problem. He said the way to do this is to penalise larger responses. Shane added that this is a sophisticated algorithm that might be confusing for network operators, but it shouldn’t have any effect except in an attack scenario. He noted that the basic philosophy is having a name server act in a degraded mode when under attack, which is unfortunate, but perhaps the least worst option. Geoff Huston noted that rate limiting might not be the best option, and noted that Jared’s work seems to suggest there is a mechanism that gets around this. He said response size seems to be the problem, and it seems that BCP38 is unlikely to gain traction. He added that EDNS0 seems the a good option, but the usual default 4096 size seems to have been overly optimistic, and opened up vulnerabilities - 512 would be better. Ralf Weber said it still might be effective to look at rate limiting. Geoff argued that this strategy would mean you were rate limiting everyone. Bill Manning, ISI, suggested that authoritative servers are doomed if everyone supports a 64k response size. Jim suggested there would be fragmentation issues long before reaching that point. Bill noted that pushing the response size to 64k changes the idea of what a threat is. Shane suggested that few people were likely to be considering 64k as a major issue. An unidentified attendee noted that rate limiting will work for a while, but it requires increasingly complex algorithms. He suggested that it's not just DNS, with enough other public UDP services in the network, SNMP. Jim noted however that TCP is also a very good vector for attack. The attendee agreed that this had been an issue for Yandex in Russia. Geoff disagreed, noting that other protocols (UDP or SNMP) are not reliable attack vectors, but agreed that RRL is not effective and can only buy a small amount of time. Michael Daly of Nominet, noted that Nominet infrastructure had been used for amplification attacks and that RRL had helped, but they found that looking at signatures and rapidly responding helped more. Shane suggested that it looked grim, though there have been some suggestions put forward. He suggested TCP might be a good option, though not complete, and that it’s weird that UDP is being made more like TCP (through approaches like UDP-based cookies). He noted that there is so much old stuff on the Internet that it may not be worthwhile pursuing a new technology response if it won't be taken up for another 15 years. Geoff noted that he hadn't looked at all of the respondents in his study, but suggested it's probably not so grim - the tail end of old stuff only serves a small population of clients (perhaps the 2.6% that he found in his study). An unidentified attendee noted that there have been discussions of all these various kinds of attacks and DNSSEC could solve them all. He noted that his organisation had made the considered decision to use RRL (with the associated dropping of some queries). Now with proposals on doing DNS over TCP, he noted that the only time RRL had not worked was in cases of attacks played out over open recursive resolvers. He noted that there is more data required on whether it’s viable to do DNS over TCP. Ralph noted that the designers of DNS software expected the use of TCP to be a rare occurrence, and it's a problem that large volumes of TCP can't be consumed, but it's solvable. Geoff noted that he had done some work in this area using virtual TCP drivers, but that, with a standard TCP driver, you'll run into trouble. Edward Lewis (Neustar) argued a need to recognise where we want to go to and begin to move toward that long-term goal, evolving the DNS into the protocol we want it to be rather than simply patching what we currently have. AFNIC's Mohsen Souissi agreed, noting that although DNS developers and engineers are hitting obstacles one at a time, there is a larger issue that might be better addressed at the IETF level. Jim closed the first session of the DNS Working Group. Session II Peter Koch opened the second DNS session and welcomed everyone back. He announced a small adjustment to the agenda: Jeff Osborn will follow Dave Knight. H. RIPE NCC DNS Report Anand Buddhev, RIPE NCC The presentation is available at: https://ripe67.ripe.net/presentations/248-RIPE67_AnandBuddhdev_DNS_update.p… There were no questions. Peter asked for volunteers to look into the issue of secondary DNS provided by the RIPE NCC in order to consider criteria, guidelines, service levels, and possibly even a policy if it is thought necessary. He asked anyone interested to contact the DNS Working Group Chairs after the meeting. I. Which habitat fits your name server’s nature best? Willem Toorop, NLnet Labs The presentation is available at: https://ripe67.ripe.net/presentations/250-habitat.pdf Ondřej Surý, CZ.NIC, remarked that dropped zone compilations has been removedfrom the newest version of Knot. This had sped up performance and Willem's measurements did not take that into account. Willem replied the benchmarks were performed in June and so the presentation shows the results using the software that was available then. He said he will repeat the tests with the newer version of the software. Liam Hynes (Dyn) asked what type of queries Willem was sending to the name servers for his performance tests. Willem responded that there were all different type of queries – A records or AAAA and NS – and they all existed. Liam asked if he tried different combinations like all A records, all AAAA, 50/50 A/AAAA, maybe with CNAME or TXT records. Willem said yes, but that they don't have the results. Ralf Weber of Nominum asked if the queries were EDNS or just plain DNS, and Willem confirmed it was just plain DNS. Ralf commented that all queried records exist in the zone, and Willem agreed it would be better to include some non-existent records. J. Introducing Hedgehog Dave Knight, ICANN The presentation is available at: https://ripe67.ripe.net/presentations/245-dknight-ripe67-hedgehog.pdf There were no questions. K. ISC News Jeff Osborn, ISC/DNSco This presentation is not available online. Jeff gave an overview of recent changes in the the ISC organisation There were no questions or comments. L. Client-IP EDNS Option Concerns Florian Streibelt, TU Berlin The presentation is available at: https://ripe67.ripe.net/presentations/206-L-dnswg-Streibelt-ClientIP.pdf There were no questions. M. OTE’s resolver infrastructure/design/rollout Kostas Zorbadelos, Otenet The presentation is available at: https://ripe67.ripe.net/presentations/208-OTE-Anycast-DNS.pdf Antoin Venschuren, SIDN, noticed they do DNSSEC validation for their infrastructure name servers, but not yet for their customers, and asked about the considerations for that. Kostas replied that the major consideration is the performance impact. Antoin asked about plans for this, and Kostas said he could not give an estimate, but it's definitely on the agenda and they will try to accommodate that. He added that having DNSSEC validation in the infrastructure resolvers is one step towards introducing it gradually to end users. Dave Knight noted an issue in choosing an IGP to use with IPv6. He asked whether Kostas had considered using BGP, noting that L-root switched from OSPF to BGP and it works fine. Kostas asked whether Dave meant between the anycast nodes and the network and Dave confirmed that was the case. Kostas said they have thought about the issue. Dave said he used to use OSPF and switched to BGP because everything was much easier to debug. Kostas agreed it was easier, but said a major concern could be the failover times. Dave said he doesn't have any numbers on this, but the BGP approach works for L-root. Kostas said he hoped Hedgehog would be helpful for monitoring this. Jim Reid said the Working Group Chairs would like to get a bunch of operators together to share information such as this, and experiences when switching on DNSSEC in their networks, and hopes this can be done for RIPE 68 in Warsaw. He added that there is some anecdotal evidence that resolvers have switched this on and say they haven't noticed, which is surprising, so would like to get some real data. Kostas replied he is happy to share whatever they can. He said after OTE has migrated to the new platform they intend to enable DNSSEC validation in selective nodes, not the entire infrastructure. That way the introduction of DNSSEC validation could be controlled much more than would have been possible with the previous setup. Ondřej Surý said they are already working on ISIS for BIRD routing Daemons, and Kostas replied that they are really interested in this. An unidentified attendee from Forthnet confirmed that they saw no impact when they turned on DNSSEC for their customer resolvers in December 2012. Kostas said that in principle OTE have DNSSEC-enabled infrastructure. The attendee confirmed that is the case for their customers. An unidentified attendee from GRNET said they enabled DNSSEC validation for their customers and it had no impact at all, adding that currently 98% of their customers are doing DNSSEC validation and it's going fine. There were no further questions. N. DITL Data Analysis for ICANN gTLD Collision Study Jim Reid, RTFM LLP The WG ran out of time for this presentation. It is available at: https://ripe67.ripe.net/presentations/214-JR-RIPE-161013.pdf Z. AOB Peter Koch asked for feedback about the arrangement of the Working Group sessions as well as the content. He encouraged attendees to approach the Working Group Chairs with their feedback in person or send them an email. Jim Reid asked those who had switched on DNSSEC validation to please come and see him because he would really like them to come and talk about their experiences at the RIPE 68 Meeting in Warsaw. Peter thanked the RIPE NCC staff for scribing, chat monitoring and webcasting, along with the AV staff and the stenographer, and thanked everyone for attending.

1 0

New on RIPE Labs: NTP Reflections
by Mirjam Kuehne 01 Apr '14

01 Apr '14

Dear colleagues, After the recent amplification attacks involving NTP servers, John Kristoff, a researcher with Team Cymru, kindly agreed to publish an analysis of the history and timeline leading up to the attacks. Please find his contribution on RIPE Labs: https://labs.ripe.net/Members/mirjam/ntp-reflections Kind regards, Mirjam Kuehne RIPE NCC

1 1