Colleagues, here are the minutes from our meeting in Amsterdam last year. My apologies for the unacceptable delay in getting these circulated.
Please let us know if there are any errors or omissions. DNS WG - Session 1 RIPE 70 13 May 2015 WG co-Chairs: Peter Koch, Jim Reid, Jaap Akkerhuis Scribe: Emile Aben A. Administrivia Peter Koch opened the session and the minutes of the previous meeting were approved. B. RIPE NCC Report - Anand Buddhdev and Romeo Zwart, RIPE NCC https://ripe70.ripe.net/presentations/75-RIPE70_AnandBuddhdev_DNS_Update.pdf Lars Liman, Netnod, noted that the old scripts won't go away even if visualisations were removed. Romeo answered he was aware of that. George Michaelson, APNIC, expressed interest in query rates for AS112, He was surprised by seeing 10% of queries over IPv6. Anand said he saw similar numbers for other authoritative servers. Jim Reid suggested putting a 'this is going away' sign on the old DNSMON visualisations. Romeo responded that was already done, and said the plan is to make landing page for old DNSMON a redirect to the new DNSMON. C. IETF Report Peter made the room aware of a virtual interim meeting of the IETF dns-ops group. Minutes of this meeting are available online: https://www.ietf.org/proceedings/interim/2015/05/12/dnsop/minutes/minutes-interim-2015-dnsop-1 D. Knot DNS 2.0 - Status Update - A New Major Version Introducing Updated DNSSEC - Jan Vcelak, CZ.NIC https://ripe70.ripe.net/presentations/71-ripe70-vcelak-knot.pdf Olafur Gudmundsson, Cloudflare, asked if key management is time driven or predicate driven. Jan said they plan to provide hooks so external scripts can do various checks. Jan further explained that if a key server is down, steps in key management are postponed. Patrik Falstrom, Netnod, said he likes to have callback mechanism so it's possible to have external software react to key management events. E. Test Cases for Validating a DNS Delegation - A Step Towards Best Practice - Sandoche Balakrichenan, AFNIC https://ripe70.ripe.net/presentations/83-TRTF-RIPE2015.pdf Sebastian Castro, NZRS, said they have code ready for a discovery check, and wanted to clarify if only compliance checks were wanted, or also discovery checks. Sandoche responded that if there was code and consensus that this should be added, it would be added. Jelte Janssen, SIDN, commented that he liked the effort and said it's probably good if tool sets can have slightly different focus. F. DNSSEC ECDSA Algorithm Use and Acceptance - Olafur Gudmundsson, Cloudflare https://ripe70.ripe.net/presentations/85-Alg-13-support.pdf Anand responded to Olafur’s presentation with the promise that for next meeting all resolvers will have ECDSA support. Anand asked if Cloudflare could contribute in making validating with ECDSA faster. Olafur responded they have code for OpenSSL to speed things up. Geoff Huston, APNIC, said he kept on hearing there is no DNSSEC out there, but he sees 25% of users do validate. He also said that lack of ECDSA support went from one in three last September to one in five now, and thanked Olafur for the efforts in making that happen. G. DLV Sunset - Jim Martin, ISC https://ripe70.ripe.net/presentations/81-RIPE-DLV-timeline-20150513.pdf George Michaelson suggested a shorter time line for the DLV sunset. He also asked what the resolver side failure mode is when the server stops responding. Jim Martin said it was SERVFAIL if you are running BIND. Warren Kumari, Google, thought that because of Jim's presentation the number of DLV participants would drop and would be interested in seeing the number of participants on 14 May. Jim Reid said he found the time line for sunset quite reasonable with regards to software packaging, and thanked ISC for bringing about the long overdue death of DLV. He also brought up the issue of DLV code in BIND and suggested ISC remove it from the next appropriate BIND release. Jim Martin responded he would take that suggestion to the developers at ISC. ———— DNS Working Group - Session 2 RIPE 70 14 May 2015, 9:00 WG Co-Chairs: Jim Reid, Peter Koch, Jaap Akkerhuis Scribe: Florian Obser H. Knot Resolver – A More Thorough Introduction - Marek Vavruša, CZ.NIC https://ripe70.ripe.net/presentations/121-knot-resolver-ripe70.pdf Ed Lewis, ICANN, asked if the resolver can learn a new trust anchor for the root zone. Marek answered that he didn't talk about DNSSEC because it doesn't validate yet. Jim Reid asked when the software will be released for general use. Marek said that he wants to have it production ready by the end of the year, maybe earlier and that there is a release plan on the web site. I. Network-Tuning for DNS Zone Transfers in (lossy) Long Fat Networks - Marco Prause, DENIC https://ripe70.ripe.net/presentations/123-TuningZoneTranfers4LFNs.pdf Ed Lewis asked what kind of records are in the IXFR and if they are mostly to be removed RRSIGs. Marco confirmed that this is the case. Matthijs Mekking, Dyn, said that he looked into improving IXFRs by not transferring huge amounts of deleted signatures but he couldn't find real live scenarios that suffer from this. Lars Liman, Netnod, asked if other kernels besides Linux have implementations for different TCP congestion control algorithms. Marco said that the congestion control algorithm can be changed in FreeBSD but he wasn't sure if TCP-Hybla is available. Jim Reid asked if there was any other way to improve performance. Marco said that he was changing the TCP window size and other kernel parameters but real improvement were only achieved with changing the congestion control algorithm. J. Root Zone KSK Rollover - Ed Lewis, ICANN https://ripe70.ripe.net/presentations/86-DNSOARCRIPE70slides-submission2.pptx.pdf Marek Vavruša, CZ.NIC, asked if there are any plans to change the key parameters or do a algorithm roll over or just roll the old key. Ed responded that yes, algorithm roll over was considered and that he's not saying no to anything at this point and is open for all suggestions. Marek pointed out that he is concerned about increased response sizes. Geoff Huston, APNIC said that his presentation will address that. Sam Weiler, Parsons, wanted to make sure that people look at CDS (RFC 7344). Jim Reid asked how people can make further observations or comments known to ICANN. Ed said that the formal way is the public comment period. The design team is meeting and will produce a document. The formal way is to respond to that. Jim then asked what if someone wants to give comment to the design team while they are working. Ed responded that anyone can speak to the design team and they are on the relevant mailing lists. He continued that this is an informal way of taking part in the discussion and consulting the community. The formal approach will be via the public comment period. Matthijs Mekking said that the rollover had been discussed at DNS-OARC and that the discussion there has been archived. Peter Koch, DENIC, observed that people in the Working Group are aware of RFC5011 and if they are not running it they can either manually change their trust achchor configuration or migrate to RFC 5011 aware resolvers. He asked what the vision is for the long tail that might be affected by the root key rollover, Ed responded that RFC5011 is only one tool. There are other options, for example the IETF has published a trust inchor Internet Draft. He said that ICANN are trying to understand who is consuming root trust anchor information. Ultimately there is stuff out there that will break and he said that ICANN won't know how to reach the person that will responsible for that stuff. He continued that at one point it is hard to know how much responsibility we have to make sure that everybody is perfectly upgraded. He said that they don't even have tools to test. He said he can't find out if a person has the new trust anchor without breaking that person's setup and that person then complains. And he doesn't want that ability. He said that this is an open question. Peter Koch pointed out that this is as much a communication exercise as it is an engineering exercise. Ed agreed with this. Peter also pointed out that we need to be careful because if too much stuff breaks this could lead to further DNSSEC push back. Stephan Lagerholm, speaking for himself, asked if there is any work being done to mitigate against additional risks known since Snowden. He gave several examples of mistrust against DNSSEC in the community and asked if there is anything that can be done during this key roll over to help restore trust. Ed responded that the design team was looking at different algorithms but more from the size perspective. He thanked Stephan for bringing this up because the design team might not have looked at mitigations for this particular problem space. Warren Kumari, Google, responded to what Peter said by pointing out that there was supposed to be a public outreach since at least 2013. Ed remarked that a time machine was under construction. K. Tyre-kicking the DNS - Geoff Huston, APNIC https://ripe70.ripe.net/presentations/130-2015-05-14-dns-xpmts.pdf Alain Durand, ICANN, asked what the reason for IPv6 enabled resolvers querying over IPv4 is. Is it the same thing as with eye ball software that tries IPv4 and IPv6 and goes with the fastest answer or is it hard coded? Geoff said that he doesn't see exploratory round trip probing and that he thinks that it is hard coded. He went on to say that he couldn't find this in the DNS resolver code but the behaviour indicates a solid preference for A before AAAA. Alain pointed out that there are only a few resolvers people are running and if Geoff asked the resolver implementers what they are doing. Geoff said he hadn't done this yet and pointed out there are resolver implementers in the room. An unidentified attendee said they prefer IPv4 for resolution. Jared Mauch, NTT, said that in many networks there is no traffic engineering for IPv6 so if resolvers were doing RTT probing they would find that the IPv6 path is slightly shorter. He went on to say that resolvers probably have the IPv4 answer cached already and then go with that. Geoff said that during DNS-OARC it was mentioned that resolvers like to run red hot. So when IPv4 answers are already cached this becomes a self fulfilling prophecy. He continued that this seems to be a safe thing to do since everybody is scared about IPv6 path MTU problems. Marek asked what happens if one changes the order of glue. Geoff responded that he only tried IPv6 only. He said that he played with glue ordering in previous experiments and the experience was that IPv4 seems to be hard coded preferred. Marek said that some resolvers fetch the IPv4 address first. Geoff asked what the knot resolver is doing. Marek responded that knot fetches both and then decides on the round trip time. Z. Wrap Up - WG Co-Chair Appointment Process Jim Reid said that all Working Groups have been trying to come up with a process for appointing new working group chairs. The DNS working group has reached a point with some kind of silent consensus for a proposal that has been put out a week ago. He said that it would be helpful for people to voice their support rather than relying on the principle of silence implying consent. He continued to say that if the working group doesn't speak up it will be adopted in time for RIPE 71. People who are interested in standing for as co-chair should speak to the current group chairs. Jim thanked the NCC staff, the scribe, the person taking care of the chat room and the stenographer. With that he closed the session.
