Here are the minutes of the last WG meeting. Please speak up if there are any corrections. RIPE 65 DNS Working Group - Session I 26 September 2012, 11:00-12:30 WG co-Chairs: Jim Reid, Jaap Akkerhuis, Peter Koch Scribe: Daniel Quinn A. Administrivia Jaap Akkerhuis, DNS WG co-chair, opened the session and welcomed attendees. He announced that the minutes for RIPE 64 were online and no comments were received so he assumed it was safe to publish them as final. He reminded attendees to state their name clearly before asking a question. Jaap said that there would be some changes to the agenda and that the OpenDNSSEC and benchmarking effort presentations would swap. B. Software Reports DNS Benchmarking Effort - Shane Kerr, ISC https://ripe65.ripe.net/presentations/168-ripe65-dns-benchmarking.pdf Jim Reid, WG co-chair, asked if they had a mailing list or website where the public can see what was going on. He would like to see benchmarks and other forms of information. Shane said there wasn't and that although BIND is not developed in a committee-fashion, ISC is still interested in requests from the community. Daniel Karrenberg, RIPE NCC, asked which direction they were going and whether it was just local benchmarking or a more natural network setting with remote clients. He also asked if they were looking for realistic test loads that come from actual server operators. Shane replied that real world query traffic is important, but it is also important for people to be able to reproduce these benchmarks in their own environment. Also, privacy is a concern. Emilio Madaio, RIPE NCC, pointed out that there was in fact a mailing list: dns-benchmarking@lists.dns-oarc.net OpenDNSSEC Update - Sara Dickinson, Sinodun Internet Technologies https://ripe65.ripe.net/presentations/189-ripe65-opendnssec.pdf John Bond, RIPE NCC, asked if they were planning on continuing auditor development. Sara explained that it is no longer part of the product and would require a lot of work to maintain. It is unlikely to continue. C. RIPE NCC DNS Update - Romeo Zwart, RIPE NCC https://ripe65.ripe.net/presentations/179-RIPE65_RomeoZwart_NCC_DNS_update_.... Antoin Verschuren, SIDN, asked if it was possible to mandate that networks that have a local K-root node have to do validation. Romeo agreed that that was a good idea. Wilfried Woeber, Univie, pointed out that the RIPE NCC's current model of thinking will exclude networks that are built around ASes like his. Romeo acknowledged this and said that he'd like to make sure that the RIPE NCC approaches these settings on a case-by-case basis. D. DNSSEC Measurement-A slightly closer look - Geoff Huston, APNIC https://ripe65.ripe.net/presentations/177-2012-09-26-dnssec.pdf Lorenzo Colitti, Google, commented that the numbers of 8 and 15% are different for their various tests and experiments but that they always vary with the same range between them. He added that '3' is the number you can trust, which is 8-5. Jim Reid wanted to know if they were doing fingerprinting for software identification. Geoff replied that they were. Heather Schiller, ARIN, asked what record the IP addressess in Geoff's final slide were querying, remarking that if they belonged to her, she would have them fixed. Geoff said that they were querying the A record all the way down in that domain. Paul Vixie, ARIN Board of Trustees, commented that the version of BIND (8) that exhibited this behaviour is known to be susceptible to two stack smashing attacks. He suggested that publication of this information would encourage the managers of those machines to upgrade. E. Panel: Overcoming the “First Mover Loses” Paradigm for IPv6 DNSSEC Deployment https://ripe65.ripe.net/presentations/161-worldfitbday.pdf Panel: Patrick Falstrom (Netnod) Andrei Robachevsky (ISOC), Roland Van Rijswijk (Surfnet), Antoin Verschuren (SIDN) Jim Reid commented that validation may not be as painful as many may think. He suggested that better explanation might help with adoption. Patrik pointed out that what he's heard from others was that the process was so painless, they don't really have any comment on it. Roland said that it cost his organisation nothing, and made no money aside from offers to pay him for talking about it at conferences. He added that training costs should be small because all that's needed is a one or two-day course. Andrew Sullivan, Dyn, Inc., stated that he's more interested in making sure that endpoints are using IPv6 and DNSSEC. He's less interested in ISPs doing the work. He wants OSs and browsers to look into supporting this, rather than ISPs. Peter Koch, WG co-chair, said that this was a topic for another panel. Patrik said that it was good to focus on the "low hanging fruit": the ISPs, and work from there. Lorenzo Colitti, Google, said that the panel was ignoring the problems beyond the initial setup and training costs such as CPU load and the lack of information available regarding the results in different environments. Roland said that the process used for IPv6 migration was one worth repeating, and advocated for some pioneering ISPs and/or big providers like Google, Facebook, and Yahoo to setup DNSSEC for other networks to test against. Patrik said that there was not enough information yet to prove that CPU consumption was significantly increased as a result of DNSSEC, and suggested looking at Sweden’s results, comparing average growth of DNS records and CPU load vs. growth of DNSSEC records and CPU load. Andrei said that the low-hanging fruit isn't very meaningful because there isn't much to validate. DNS - Session II 26 September 2012 - 14:00-15:30 F. Interop & New Protocols Knot DNS - Marek Vavrusa, CZ.NIC https://ripe65.ripe.net/presentations/183-knotdns-ripe65.pdf Sara Dickinson, Sinodun, asked whether the remote control utility they built was using a proprietary protocol. Marek answered that it was and that there are not yet any plans to publish it. Dane: Killer App for DNSSEC - Warren Kumari, Google https://ripe65.ripe.net/presentations/180-Kumari&Sury-DANE-RIPE65_1.pdf There were no questions. RESTful WHOIS – the IETF WEIRDS WG - Olaf Kolkman, NLnet Labs https://ripe65.ripe.net/presentations/213-RIPE65-WEIRDS-WG-DNS.pdf Stanislav Petr, HOSTING90, asked know why they needed this new protocol. Olaf replied that this was an entirely different dataset and requirements. G. DNSMON Future - Romeo Zwart, RIPE NCC https://ripe65.ripe.net/presentations/202-RIPE65_RomeoZwart_NCC_DNSMON_futur... Joao Damas, ISC, wanted to know if these features would be open to all members and wanted more specifics. Romeo said that they would be open to monitor domains for members that want their domains to be monitored. H. Operational Considerations and Recommendations for DNS Response Packet Sizes - Roland Van Rijswijk, SURFnet BV https://ripe65.ripe.net/presentations/167-20120926_-_RIPE65_-_Amsterdam_-_DN... Rick van Rein, OpenFortress, asked if the problems he'd experienced were related to IPv4 or v6. Roland confirmed that the problem exists for both, but that it's much worse with IPv6. Joao commented that BIND was going to have a lot of work done on it soon and asked for Roland's opinion on best practice for DNS. He asked whether you compromise efficiency and performance for the sake of compatibility with poorly configured firewalls or do you leave people with broken networks with slower speeds. He asked if there was a middle ground. Roland referred to the differences between BIND and Unbound and how Unbound's method was more effective at getting a response faster for the user. He added that that, coupled with Geoff Huston's revelations from earlier that day that users are extremely impatient, meant that users are less likely to blame the zone operator for poor speeds, but rather they might blame the network operator who can't fix the problem. Joao asked if Roland, as a zone operator, was happy with the increase in TCP requests for DNS. Roland replied that that metric wasn't in the stats, but that they did monitor for an increase in TCP and there was no statistically significant increase for TCP fallback. Paul Vixie asked if the total number of UDP queries go up when he dropped the buffer size. Roland explained this was not monitored specifically, but that there were no spikes indicating an increase in extra queries. He added that they could look at it specifically. Paul said that he wrote RFC2671, and as the author he would like to apologise for mistakes he made in its initial writing. Lars-Johan Liman, Netnod, asked how the recommendations would be conveyed to the community. Roland replied that a draft RIPE Working Group recommendation is open to suggestions from this point. An audience speaker commented that DNS operators generally don't like being told how to run their servers. Jim Reid said that what was important was that there was something documented that could serve as an example. The speaker agreed and asked that this be considered in the decision process. Eric Osterweil, Verisign Labs, objected to the hard limits on either side of the equation and noted that establishing standards like this are a slippery slope leading to telling people how to write their code. Roland agreed, stating that a lot of people have limited understanding regarding how to configure their own resolver. I. Panel: DNS Amplification Attacks: BCP38, mitigation, reputation or what? Panelists: Olaf Kolkman (NLnetLabs), Paul Vixie (ISC), Andrew Sullivan (Dyn), Xander Jansen (Surfnet) Joao asked if the solution was something that couldn't come from the people in this room and whether it be meetspace law? Olaf said the problem was enforcement, the overhead in tracking as well as international treaties, as well as the "arms race" and RFC 3514. Paul said that it comes down to enforcement and that as a victim, you are either being used as an amplifier and reflector or you are being attacked by others. He encouraged anyone in the audience that may be a target of such attacks to contact him privately, as they have access to data that they can share about the attack. They would be contributing to a global effort to track down people conducting these sorts of attacks. Jim Reid noted that by the time the attacking packets have reached him, the perpetrator is already gone, and suggested that BCP38 may be the solution to this. He suggested that core internet exchanges might offer discounts or fatter pipes to ISPs implementing BCP38. Andrew Sullivan said he agreed because it reversed the equation of who has terrible bandwidth: people who act poorly suffer on lower network speeds, as opposed to people who are being attacked. He admits that this is not an ideal solution, but he wasn't sure of a better alternative. J. AOB Anand Buddhdev, RIPE NCC, announced that the RIPE NCC wanted to make the name server attribute mandatory in the RIPE Database, as well make some minor changes to the syntax. He encouraged everyone to look into the archives of the DNS Working Group mailing list and to comment there.