- dns-wg - mailman.ripe.net

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

DNSMON beta update
by Chris Amin 26 Mar '14

26 Mar '14

Hi all, During the alpha phase of the new DNSMON, we sent periodic updates to the alpha testers about new features and bug fixes. For the public beta, we intend to continue in the same vein by announcing on this list, although hopefully we won't spam you too much now that the product is more mature. Since officially going "public" last week, we have made many changes to the widget. In particular gestures and feedback are drastically improved. Specifics include: * a new feature to group servers/anchors has been introduced. Now all the servers are grouped by hostname and all the anchors by country; * improved the time navigation and perception; Moving in time now provides real time feedback for a faster interaction; * the auto update function has been made more robust; * included instructions on how to include DNSMON in your own page (see "Embedding DNSMON in other pages" in the "About DNSMON menu"). URL reminder, in case you need one: https://atlas.ripe.net/dnsmon/ Regards, Chris Amin RIPE NCC

1 0

Relative response time graph
by Ben Choy 21 Mar '14

21 Mar '14

Hi all, Since this is beta testing I assume this list is where to report possible bug. Looking at Relative response time graph, the limit time check doesn't seems to work, the lower limit is ok, but the high limit doesn't show the correct colour. [hkirc] Benjamin Choy Project Manager (System & Network) Hong Kong Internet Registration Corporation Limited (HKIRC) http://www.hkirc.hk<http://www.hkirc.hk/> http://互聯網註冊.香港<http://互聯網註冊.香港/> Hong Kong Domain Name Registration Company Limited (HKDNR) http://www.hkdnr.hk<http://www.hkdnr.hk/> http://域名註冊.香港<http://域名註.香港/> Tel: +852 2319 1313 / Fax: +852 2319 2626 / Direct: +852 2319 3819 / Email: ben.choy(a)hkirc.hk [cid:image002.png@01CEAE2D.C3DA7B80]<http://www.hkirc.hk/> The information in this email is confidential and may be legally privileged. If you are not the intended recipient, please notify the sender immediately and then delete this e-mail entirely. You must not retain, copy, distribute or use this e-mail for any other purpose not intended by this email or disclose any of its content to others. The recipient should check the email and attachment for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. PROTECT OUR ENVIRONMENT - think before printing!

1 0

Global Vs local node data in www.root-servers.org
by Anurag Bhatia 17 Mar '14

17 Mar '14

Hello everyone! It seems like http://www.root-servers.org/index.html has been updated after quite sometime. Seems like data about local Vs global for many of root servers nodes is incorrect. E.g for Netnod i root all nodes are marked as Global nodes. As far as I understand it means that routes announced by these nodes are announced to transit links as well to make routes visible globally. Likely that is not case here right? Same seems with L root and few others. Do we have webmaster of the project on mailing list? Thanks. -- Anurag Bhatia anuragbhatia.com Linkedin <http://in.linkedin.com/in/anuragbhatia21> | Twitter<https://twitter.com/anurag_bhatia> Skype: anuragbhatia.com PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2

8 9

Call for contributions: DNS-WG at RIPE68
by Peter Koch 08 Mar '14

08 Mar '14

Dear DNS WG, the RIPE meeting in Warsaw is 10 weeks away and we would like to compile a preliminary agenda soon. The DNS WG has been assigned the usual two slots, this time on Wed, 14 May, around lunch. That's 1100-1230 and 1400-1530 in proper figures. Please submit suggestions for presentations to <dns-wg-chairs(a)ripe.net>. There's a lot going on in the DNS world and whatever you or your colleagues have done, please consider sharing. We are definitely interested in operational matters, as well, so do not hesitate to submit the "tiny idea" that's explained in five to ten minutes. We will echange information with the OARC program committee for their (our) workshop taking place the weekend before RIPE68 to mitigate collisions (no pun). -Peter (for the wg co-chairs)

1 0

the seven people who hold the keys to worldwide internet security
by Jim Reid 04 Mar '14

04 Mar '14

Sigh. Just sigh. http://www.theguardian.com/technology/2014/feb/28/seven-people-keys-worldwi… Well at least the article has a photo of Rick Lamb in a suit and tie, so it's not all bad... :-)

10 20

Re: [dns-wg] the seven people who hold the keys to worldwide internet security
by Michele Neylon - Blacknight 03 Mar '14

03 Mar '14

Jim Yeah - I'm shocked that the expenses aren't covered already. I assumed that they were Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Domains http://www.blacknight.co/ http://blog.blacknight.com/ http://www.technology.ie Intl. +353 (0) 59 9183072 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 -----Original Message----- From: Jim Reid [mailto:jim@rfc1035.com] Sent: Monday, March 3, 2014 2:59 PM To: Michele Neylon - Blacknight Cc: RIPE DNS WG Subject: Re: [dns-wg] the seven people who hold the keys to worldwide internet security On 3 Mar 2014, at 14:52, Michele Neylon - Blacknight <michele(a)blacknight.com> wrote: > Doesn't ICANN / IANA cover their expenses?? No. The TCRs must pay their own way or get their employer to pick up the travel costs. IMO this should change.

2 1

Re: [dns-wg] the seven people who hold the keys to worldwide internet security
by Michele Neylon - Blacknight 03 Mar '14

03 Mar '14

What? Doesn't ICANN / IANA cover their expenses?? -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Domains http://www.blacknight.co/ http://blog.blacknight.com/ http://www.technology.ie Intl. +353 (0) 59 9183072 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 -----Original Message----- From: dns-wg-bounces(a)ripe.net [mailto:dns-wg-bounces@ripe.net] On Behalf Of Lutz Donnerhacke Sent: Monday, March 3, 2014 2:40 PM To: dns-wg(a)ripe.net Subject: Re: [dns-wg] the seven people who hold the keys to worldwide internet security * Kim Davies wrote: > I actually think the story does a great job of making a deathly boring procedure interesting and accessible. It's not only boring. It's expensive, too. The participants have to pay for the fame.

3 2