- dns-wg - mailman.ripe.net

indulgence satiated
by manning bill 05 Jun '14

05 Jun '14

Thanks All for taking the time to prod 2001:500:84::b Looks like it is reachable from many places… enough that we will proceed to augment the “B” root server with perhaps the last in a long line of IPv6 addresses that it has had over the last 15 years. Splay will increase over time. /bill /bill Neca eos omnes. Deus suos agnoscet.

4 7

WG comment on DNSMON changes
by Jim Reid 03 Jun '14

03 Jun '14

Colleagues, you might recall that last month the NCC announced a time-line for some changes to the DNSMON service. This was discussed when the WG met in Warsaw last week. In outline, the old service is based on TTM boxes which are due to be retired at the end of June. These are already beyond their anticipated life-span. The new version of DNSMON uses the Atlas probes and is already operational. It is possible some users of DNSMON may need to change their internal tools and processes when transitioning to the new platform if these depend on the data gathering done by the soon-to-die TTM boxes. If this affects you, please speak up now! I would be grateful if you could express your approval or rejection of the NCC's approach and proposed time-line. Details are at https://labs.ripe.net/Members/romeo_zwart/copy_of_proposed-time-lines-for-p…. There was little to no response by the WG to the earlier announcement. This makes both your WG Co-chairs and the NCC staff uncomfortable. After the WG co-chairs and NCC's DNSMON team discussed this last week, we agreed to set the end of this month as the final date for comments. Although we can work on the operating principle that silence implies consent, it would be better for all concerned if there were positive messages of support (or even ones of objection) on the list. Please respond. I'd appreciate it if you can comment on the list to indicate that you approve (or disapprove) of the current proposal and/or time-line. thanks in advance

7 6

crave your indulgence
by manning bill 28 May '14

28 May '14

If you wouldn’t mind a quick tracerooute - Can you confirm reachability to the following: 2001:500:84::b Thanks in advance. /bill Neca eos omnes. Deus suos agnoscet.

5 5

Provisional agenda for RIPE 68
by Jim Reid 07 May '14

07 May '14

Colleagues, my apologies for the delay in getting the agenda prepared and distributed for next week. At long last, here it is. Please note one or two items have not get been confirmed, so there may be some changes between now and next Wednesday. Although I don't expect there will be any, it would be unwise to make life-changing decisions on the assumption that the V1.4 agenda remains unchanged. Hope to see most of you in Warsaw next week. # # $Id: agenda,v 1.4 2014/05/07 11:00:29 jim Exp $ # PROVISIONAL AGENDA: RUNNING ORDER, TIMES & EVEN CONTENT MAY CHANGE [0] Usual Administrivia 5 mins Agenda bashing Minutes of previous meeting Review of Action Items [1] NCC Report 15 mins Stuckee, RIPE NCC [2] DDoS Forensics 25 mins Curon Davies, JISC RSC Wales As a result of daily attacks against a Further Education College in Wales, a connection was noticed between changing DNS entries and the attacked IP address. Using innovative DNS responses inspired by GeoDNS and logging all requests to the authoritative server, it has been possible to trace the source of DDoS and spoofed flood attacks. [3] Measuring DNSSEC validation deployment 15 mins Nicolas Canceill, NLnet Labs We have executed a research in which the RIPE Atlas measurement network was utilized to quantify the amount/percentage of resolvers that do DNSSEC validation. We were not only able to identify which resolvers do DNSSEC validation, but also which resolvers are security-aware (and to which level). Moreover, during the research some particular cases have been found: the existence of insecure fallbacks in case of missing signatures, and a troublesome issue with secure wildcard records. [4] Measuring DNSSEC from the end user perspective 30 mins Geoff Huston, APNIC The presentation explores the technique of measuring the characteristics of the DNS and its performance by posing a set of DNS questions to end users and observing the queries that occur at the authoritative servers in response. Using online advertising channels the tests can be undertaken at a level of high volume and broad spread across the Internet. The presentation will describe the use of this technique in measuring DNSSEC validation, DNS over TCP, DNS performance and similar. LUNCH [5] Report from Ad-hoc ccTLD group 10 mins Peter Koch, DENIC [6] Registry Infrastructure Transformation 20 mins Michael Daly, Nominet In the past 24 months Nominet the UK Registry have completely transformed the infrastructure that is used to deliver the UK Registry services. The infrastructure has been moved to be much more agile and highly available. This presentation will detail some of the choices we made and methods we used to deploy and manage our infrastructure. [7] Google DNS hijacking in Turkey 30 mins Stephane Bortzmeyer, AFNIC In March 2013, the Turkish government decided to prevent access to Twitter. It used some well-known techniques but also one which have not been documented in the real world before: using routing to hijack DNS resolvers such as Google Public DNS. What exactly happened and what could be done to prevent that? [8] DNSMON Developments 10 mins Stuckee, RIPE NCC [9] DNS Monitoring Common Practices/APIs Panel Session 15 mins To be confirmed [10] AOB 5 mins

2 1

Program in Warsaw?
by Stephane Bortzmeyer 05 May '14

05 May '14

I find nothing on this list, or on <https://ripe68.ripe.net/programme/meeting-plan/> (note the menu has all the WGs but DNS) The group was shut down while I looked elsewhere?

3 3

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

sub-/24 "delegation" [2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4)]
by Peter Koch 28 Mar '14

28 Mar '14

Dear DNS WG, people on this list might be interested in one aspect of the proposed policy <http://www.ripe.net/ripe/policies/proposals/2014-01>, <http://www.ripe.net/ripe/mail/archives/address-policy-wg/2014-March/008638.…>, when it comes to (sub-)allocations smaller than /24. Note that BCP10/RFC 2317 is not necessarily the or the only solution to the problem. Also, in the interest of keeping the policy discussion focused, we might want to strictly focus on the reverse mapping on this list and make sure some "sense of the room" as well as all other aspects get discussed on address-policy. -Peter (DNS WG co-chair) ----- Forwarded message from Tore Anderson <tore(a)fud.no> ----- From: Tore Anderson <tore(a)fud.no> To: Carsten Schiefner <ripe-wgs.cs(a)schiefner.de>, Rob Evans <rhe(a)nosc.ja.net> Cc: address-policy-wg(a)ripe.net Subject: Re: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) Date: Thu, 27 Mar 2014 09:34:20 +0100 In-Reply-To: <5333CABF.1070609(a)schiefner.de> * Carsten Schiefner > No, not really. I feel this being only loosely coupled at best. My > proposal enables the transfer of allocations of *all* sizes and the > conversion of PI assignments of *all* sizes into allocations. > > Whether sub-allocations can be made from *all* these (new) > allocations or "just" from those being at least a /24 appears as a > separate question to me. Even more so, as the the sub-allocation > mechanism has been applied or used very rarely only so far. > > And having the "one thing at a time" principle in mind: if this > impossibility is of concern to the community, then this should maybe > be handled by a separate policy (modification) proposal. Hi Carsten, I'm just of the opinion that removing one without the other leaves the policy in a counter-intuitive state. To me it would appear appropriate for a proposal titled «Abandoning the Minimum Allocation Size for IPv4» to remove all flavours of the minimum allocation size, including the one specific for sub-allocations. Besides, one of the two stated reasons for having the minimum sub-allocation size («[/24] is the smallest prefix length that can be reverse delegated») is quite simply false, given RFC 2317, and if we also accept the rationale for 2014-01, then we've essentially rejected the other reason too («allows for a reasonable number of small assignments to be made»). So I'd ask you to consider removing that paragraph as well before going to review phase. Note that since we're still in the discussion phase, doing so doesn't have to slow down the progress of the proposal, you can go straight to review with updated proposal (modifications at a later stage are much more cumbersome). Just my €.02...your proposal, your call. ;) Tore ----- End forwarded message -----

4 4