----------------------------------------------------------------------------- FINAL dnsop WG minutes for IETF 65, Dallas ----------------------------------------------------------------------------- WG: DNS Operations (dnsop) Meeting: IETF 65, Dallas Date: Tuesday, 21 March 2006 Time: 15:20 - 17:20 (UTC -0600) Chairs: Rob Austein, Peter Koch Minutes: Jaap Akkerhuis Jabber: xmpp:dnsop@rooms.jabber.ietf.org J-Scribe: Wouter Wijngaards J-Script: http://www.ietf.org/meetings/ietf-logs/dnsop/2006-03-21.html Audio: http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf65/ietf65tue05.mp3.2 WG URL: http://www.dnsop.org Material: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65 ----------------------------------------------------------------------------- 1) Administrivia - blue sheets - agenda bashing There was no change to the agenda itself. ----------------------------------------------------------------------------- 2) Status Update by chairs - RFCs published RFC 4339 "IPv6 Host Configuration of DNS Server Information Approaches" - Internet-Drafts in RFC Editor Queue draft-ietf-dnsop-ipv6-dns-issues-12.txt - I-Ds in IESG review draft-ietf-dnsop-dnssec-operational-practices-08.txt Approved by the IESG yesterday (2006-03-20) after a resolved discuss. - I-Ds in or past WGLC draft-ietf-dnsop-bad-dns-res-05.txt This draft passed Working Group Last Call, waiting for PROTO write-up. draft-ietf-dnsop-serverid-06.txt This draft is close to be done and was waiting for a corrected version (-07). It will then be sent to the IESG with a PROTO write-up. Since this will be an informational document, it depends on the AD whether there will be an IETF Last Call. draft-huston-6to4-reverse-dns-04.txt This document describes an existing service. This draft is still in need for review and the chairs are waiting for volunteers. The list of volunteers from last time got lost. Comments from George Michaelson (Proxying Geoff) about issues that came up: Although there had been no publicity at all, there are already over 185 uses of this service. This raises questions about the scalabilaty. Obviously it scales for the time being. Note that this service is designed for transition and not for infinite use. Q: It was raised why this wasn't done with with dynamic update? A: if you want that, write a proposal. ----------------------------------------------------------------------------- 3) Lingering Drafts & Review Process 3.1) draft-ietf-dnsop-inaddr-required Discussion of this draft needs more guidance, otherwise it is at danger of rehashing old issues over and over. Peter suggests to use the tracker, identify and discuss the issues and close them. Sam Weiler notes that the drafts is expired and wonders whether the editor is not really committed. Peter Koch explains that that is not the case and that by non foreseen circumstances the editor just missed the deadline for this meeting. 3.2) draft-ietf-dnsop-respsize Draft is expired, revised I-D needed Akira Kato-san reports that the draft expired by accident. A new version (03) is expected soon. At the meeting nine people volunteered to review the draft. ----------------------------------------------------------------------------- 4) WG Charter A draft charter was circulated to the mailing list in advance. Peter Koch gives an overview of it. It boils down to: 1) develop or review guidelines for choosing zone configuration parameters that affect inter-server or server-resolver communication, including but not limited to SOA RR parameters, TTL values, and glue information 2) develop or review guidelines for any DNSSEC specific operational parameters, such as key length or key validity periods 3) develop or review operational guidelines that address the specifics of IPv4/v6 coexistence and transition 4) review the use of existing DNS frameworks (SRV, DDDS) in other protocols, especially focussing on operational consequences and scalability Pekka Savola comments that operators needs are not addressed and wants to know whether 4 denotes only new things or also current. Peter: Interpretation what ever you like. Intention is current and upcoming, like ENUM. Pekka: so this not necessarily gives new action items. Austein: Grey area, sometimes issues are discussed with the DNS directorate. But sometimes some wider review is needed. Peter: Price for (4) is more reviews and more work! Generic Question: Is the proposed charter too broad/too narrow? Ed Lewis misses: (1) resolver issues (2) performance, measuring, etc. Point 4 adresses about protocols, 1-3 about servers, in general, the resolver part is missing. Ed clarifies the he would like to see measurements guidelines and methodology discussed in the group, but does not expect the WG to engage in actual measurements. Alain Durand wonders about terminology used. A lot of documents have problems with that. Peter agrees that this problem is important and needs to be solved. However, the DNSOP WG is not only the only game in town. Olaf Kolkman (DNSEXT co-chair) is asked for a comment. Olaf: as soon as such a draft exists as a personal submission he will let it land in DNSEXT WG. Some will be done somewhere and dnsext will at least review such a thing. Peter: Last Call on the charter will be done after comments are taken in and processed and actual milestones have been defined. ----------------------------------------------------------------------------- 5) Other Internet-Drafts 5.1) draft-krishnaswamy-dnsop-dnssec-split-view-02.txt http://www3.ietf.org/proceedings/06mar/slides/dnsop-1.ppt Suresh Presents: Goal is to demonstrate the need for this WG to deal with the subject. After the presentation it was questioned why 'split view' was needed in the first place and whether it is a 'good thing'. Reasons given included the existence of Firewalls/NAT and hidden names inside public names spaces. Suresh suggested that the WG should care because 'split views' could conflict with DNSSEC and offer various options of 'shhoting oneself in the foot'. He felt that the draft/the WG should offer solutions to enable coexistence of split-views and DNSSEC. Comments should go to the WG mailing list. Rob Austein asked whether this was the right document for the group. Some voices were raised in favor and eventually 10 people in the room volunteered to review the document. The document will not become a WG doc yet until this real review is done. 5.2) draft-andrews-full-service-resolvers-02.txt [slides available with agenda slides] Mark presents and Peter summarizes that this is AS-112 in a box. Two questions are raised: (1) Should there be an IANA registry for this? (a) how do you know your addresses are to get on the list? (b) how to get addresses off the list? After some discussion, the chairs ask for a humm in favor of either an IANA Registry or a hardcoded list in the document. The humm does not show a clear result either way Mark explains that one reason for a registry was the list of IPv6 address ranges, where things still are in flux. Olafur Gudmundsson asks whether anybody sees any harm in having a registry. Sam Weiler argues that he does not see a benefit, but would not object to a registry. Rob Austein adds that so far no one has argued for a registry maintenance policy weaker than 'standards action', so the actual work of updating the list might be the same with a registry and with a list carried forward in updated versions of the document under discussion. (2) Is initial list of adresses complete? Mark presents the list of address ranges subject to authoritative 'name error'. Peter asks why 255.255.255.255 appears instead of 255/8 Mark responds that this would cover to large of a /8 for just one address No further comments on the v4 list, further remarks should go to the mailing list. After presentation of the v6 list, Alain Durand raises the concern that anyone trying to use the listed addresses internally would encounter problems. Mark and Rob respond that the lists specify the default configuration and implementations must provide means to override these. Peter adds that a network administrator has to provide a consistent view internally. Alain volunteers to send explanatory text. Peter summarizes that the sense of the room is in favor of an IANA registry and the list presented. He suggests to ask the INT area and the 'addressing community' for review to avoid conflicts and surprises. Ten people commit to review the draft. This is not yet an official WG item. ----------------------------------------------------------------------------- 6) Current & New Topics [25 min][16:40] 6.1) Measurements on DNSSEC Validation Performance http://www3.ietf.org/proceedings/06mar/slides/dnsop-0.pdf [Jakob Schlyter][10 min][16:40] Jakob Schlyter presents performance impacts of DNSSEC validation for Nominum CNS and ISC BIND. One of the results is that the change in performance (answered queries/s) was larger for CNS than for BIND. For the ISP which gave traffic, it doesn't really matter. The audience, asked for feedback, considered this kind of testing useful. Jakob did not promise to produce a write-up of the tests. 6.2) "Open Resolvers" Discuss operational impact of "Open Resolvers" as mentioned e.g. in the thread starting Explore chances to work towards a BCP on resolver configuration and/or operational impact of potential counter measures. Peter Koch introduces subject: Lots of people heard about it. Is there work on a document? Configuration help? Should the WG produce a BCP? Several people agree that it would be good to have an IETF document, even given that BCP 38 already exists and is too widely ignored. Concerns are raised that the WG should not target a specific code base, but might want to include some configuration examples. It is also mentioned that not only open resolvers are abused, but also authoritative servers; others feel that still closing open resolvers is a good thing because they lower the barriers to entry compared to usage of botnets etc. It is noted that in some fora EDNS0 receives a bad press as being the enabler for the DoS attacks. Jinmei argues that there are some legitimate uses for open resolvers. There is agreement that resolvers should just not be 'open' by default. No one in the room argues against a BCP style document. It is also agreed that, to be useful and relevant, any such document has to be passed through soon, i.e. around the Montreal IETF. Peter is asking for volunteers to edit a document, pointing to the tight schgedule. Matt Larson, Joao Damas, Frederico Neves, and Roy Arends come forward as potential editors. Eight additional people volunteer as reviewers. Action on the chairs to select editors and define a schedule. ----------------------------------------------------------------------------- 7) I/O with other WGs [chairs][10 min][17:05] 7.1) EDNS0 for ENUM Patrik Faltstrom: As enum WG we have enough feedback already (with Liman) There are other things popping up. Let's continue the way is is now. ----------------------------------------------------------------------------- 8) A.O.B. Peter Koch (speaking as an individual) asks for review of draft-koch-dns-glue-clarifications-01.txt, dealing with "glue" terminology and policy. This is not a WG draft. Rob asks whether Peter would like to bring this to the WG. Peter responds that he'd like to have some guiding feedback first, since the draft covers various aspects, some of which are operational only. -----------------------------------------------------------------------------