-------------------------------------------------------- RIPE DNS WG minutes for RIPE 57, Dubai -------------------------------------------------------- WG: DNS Meeting: RIPE 57, Dubai Time-1: Tuesday, 28 October, 14:00 - 15:30 Time-2: Wednesday, 29 October, 09:00 - 10:30 Minutes: Arno Meulenkamp Jabber: J-Scribe: Mark Dranse J-Script: Audio: WG URL: http://www.ripe.net/ripe/wg/dns/ Material: Agenda: http://www.ripe.net/ripe/meetings/ripe-57/agendas/dns.html -------------------------------------------------------- New actions: 57.1 RIPE NCC (Anand) to consider pros and cons of submitting the trust anchors of zones signed by the RIPE NCC into ISC DLV 57.2 Peter Koch will document the WGs advice that the old forward DNS zone domain objects in the RIPE DB should be deleted and liaise with the DB WG -------------------------------------------------------- A. Administrative Matters B. Review of Action Items 48.1 Collect experiences with lameness problems due to vanished customers or AXFR sources Status: with help from the CENTR secretariat a survey was performed and it seems there isn't really an issue, TLD registries do not see a noticable number of thrid party requests. Suggestion is to close the action after a report of the survey is sent around, as it seems this isn't as big a problem as was perceived. 49.2 DNS Server Migration Status: there seems to be a lack of interest in this document, so the suggestion is to declare this dead. The document in its current form will be published on the mailing list by Jim Reid. If there is interest, people can bring it back to the working group. 51.4 RIPE203bis Status: there has not been much progress on this since the last meeting. A draft has been published, the comments need to be incorporated. Peter Koch will add comments to the draft before the next meeting. The expectation is that it can be closed then. C. ICANN/IANA Update - Kim Davies, IANA Peter Jansen from EURid asked clarifications on the ccTLD extensions for IDN, if there would be only one IDN or multiple? And if that would contain full names or abbreviations. Kim Davies and Barbara Roseman of ICANN made it clear that there wasn't one rule for all countries, but that it would be in-country rules. The ITAR keys for resolvers should be available by now. Alireza Saleh from IRNIC asked about confusingly similar characters. Kim Davies clarified that confusingly similar TLD names will be avoided and that in such cases the first applicant will get their delegation. D. Discussion on NTIA DNSSEC NoI Jacob Schlyter gave a quick presentation on the options for a response. Jim Reid argued that the RIPE community should take the opportunity given by the NTIA for having public involvement. Olaf Kolkman mentioned that there are several other proposals, it is not limited to the 2 proposals that were discussed. Lars-Johan Liman mentioned that it might be better to state that the RIPE community communicate the properties of the solution wanted, rather than discuss the actual proposals. After some discussion it was decided that an impromptu group, consisting of Jim Reid, Patrik Faltstrom Daniel Karrenberg, Peter Koch, Lars-Johan Liman and Joao Damas would write down the concerns of the working group in a document, to be presented during the next WG session (Wednesday). E. Etisalat DNS Operational Experiences - Abdulla Bushlaibi, Etisalat There were no questions after the presentation. F. A Versatile Platform for DNS Metrics with its Application to IPv6 Penetration - Stephane Bortzmeyer, AFNIC The site for the tool, DNSwitness is here: http://www.dnswitness.net/ Mohsen Souissi and Stephane gave some extra information after the presentation, such as the reason for choosing python (simplicity and the existence of a good DNS library written by nominum) and they specifically mentioned that they are willing to share the data with other TLD operators, in order to get a better global picture. close of meeting 15:55 -------------------------------------------------------- Session 2 Wednesday, 29 October. 09:00-10:30 Salon I-III -------------------------------------------------------- G. IETF WG News Update - Lars-Johan Liman, Autonomica Update on the following: -resilience against kaminsky attack -rsasha256 -update of extended dns, edns0. (this draft is currently expired) -deprecation of md5, which is considered weak. There's an issue with registering code points and requirement levels in the IANA registry. -A clarifying document on zone transfers, Ed Lewis will write a document on that, but there is not much discussion currently. Steve Crocker proposed a mechanism to signal which algorithms a server is able to handle, there is currently no sign of adoption by the wg. Another request is for an update to RFC1123, because it expects labels to be alphabetical, which does not work with IDNs. There is not much movement on this yet. A document will be written on dynamic zones and DNSSEC. Mark Andrews is looking for help on creating this document. More resilience work, with wg chair urging adoption of new measures that only just passed draft status. And there is discussion on dns 0x20 (hex20) which would increase "randomness", as an extra defence against the Kaminsky attack. {The the power came back, but no network...} After the presentation, there was a quick update from the IDNAbis wg. They are trying to update the IDNA standard. Both docs are stable and there is consensus they are done. There is still some discussion on the protocol doc and what standards track it should go into. These issue are about to be clarified. No questions. H. RIPE NCC Update - Anand Buddhdev, RIPE NCC 09:30 There was a question about how to get the trust anchors for the RIPE NCC domains. Anand explained that they could be found on the secure website . Anand was asked to look into DLV, which would make keeping track of key rollovers easier. ACTION: NCC (Anand) to consider DLV for the Trust Anchors maintained by the NCC I. Discussion on Stale Domain Objects - Peter Koch, DENIC 09:49 There are forward DNS zone domain objects in the RIPE DB. There was some question on what to do with those. Since enough time had passed since TLDs had been told that the RIPE DB was not the right place for those objects the WG decided that the old objects should be deleted. around 25 hands in favour of deleting no one against deletion ACTION: Peter will document the WGs advice that the old forward DNS zone domain objects in the RIPE DB should be deleted. J. .org's Next Steps with DNSSEC - Lance Wolak, PIR Shane added some info on the deployment. Most inhouse things are ready, work now on customer facing interfaces. This is a NSEC3 deployment, which is interesting, BIND can only now do NSEC3. NSD is also used, it can do NSEC3 for a while. This deployment is probably one of the first NSEC3 deployments, so odd things might happen. It will be put on the live servers in the next few weeks. People that want to take part in the beta can configure the keys and such in their verifier. Contact Shane for more info. K. IDN GCC Trial Project - Amani Mohammed Bin Sewaif, Etisalat Olaf Kolkman wondered if it was an interim solution or more permanent. Amani explained that it was a trial and that it showed a need and that it was actually working and that the next step would be actual deployment. L. Followup on NTIA DNSSEC NoI 10:40 The impromptu group produced the following set of points for consideration as the WG or RIPE response to NTIA: a: DNSSEC is about data authenticity and integrity and not about control. b: The addition of DNSSEC to the root zone must be recognised as a global initiative. c: Addition of DNSSEC must be done in a way that the deployment of DNS is not at risk. d: Deployment should be done in a timely but not hasty manner. e: Any procedural changes introduced by DNSSEC should be aligned with the process for coordinating changes to and the distribution of the root zone. f: Policies and processes for signing the root zone should make it easy for TLDs to participate. g: There is no technical justification to create a new organisation to oversee the process of signing of the root. h: No data should be moved between organisations without appropriate authenticity and integrity checking. i: The public part of the KSK must be distributed as widely as possible. j: The organisation that creates the zone file must hold the private part of the ZSK. k: Changes to the entities and roles in the signing process must not require a change of keys. l: The solution has to balance various concerns, but must provide for a maximally secure technical solution and one that provides the trust promised by DNSSEC There weren't many concerns for point a, b, d, e, f, h, j and l, though some felt the ordering or priorities of these points needed to be re-arranged. At point c: There was some discussion on how to not use too strong a language and that it should not focus on just resolvers. For point g: There was some discussion of whether the point was necessary at all, as it mentioned certain organisations. The main feeling was that adding DNSSEC shouldn't change the current model. The introduction of a new entity should be separated from the current discussion. On point i: There was some discussion on the word "minimal", as DNSSEC is not a small change. Again, the point was to reiterate that the introduction of DNSSEC should not cement the current model and that changing the current model is orthogonal to adding DNSSEC. At point k: Not everyone was happy with this point. It basically talked about principals, not about something concrete. There was no agreement on how to change the text. With that, WG decided that the text could go to the plenary for possible endorsement as a statement on behalf of the RIPE community. If no consensus was reached there, the statement would be submitted to NTIA on behalf of the WG. Z. A.O.B./General Discussion No AOB End of session 11:10 --------------------------------------------------------