DNS Operations (DNSOP) Working Group - IETF-79 Meeting ======================================================= Chairs: Peter Koch Stephen Morris Date: Thursday, 11 November 2010, 17:40 Location: Valley A Ballroom, Shangri-La Hotel, Beijing (Numbers in parentheses are the time on the audio record: http://www.ietf.org/audio/ietf79/ietf79-ch6-thur-noon3.mp3) ------------ 1) Administrivia (11:46) Minutes: Rickard Bellgrim Jabber: Patrik Wallstrom, Suzanne Woolf Agenda changes: * No update for 4641bis as Olaf is not able to be with us today. * DNSSEC history project presentation will be brought forward as Steve Crocker is unable to stay for the entire meeting. ------------ 2) Status Update (15:40) * draft-ietf-dnsop-name-server-management-reqs Passed IETF last call. Aiming at Informational document. Two comments received, neither of which raised any issues. Wes has received some comments in private, and these are being considered. * draft-ietf-dnsop-default-local-zones * draft-ietf-dnsop-as112-ops * draft-ietf-dnsop-as112-under-attack-help-help The -05 version of as112-ops appeared today as minor changes were needed after the nits review. These three are now ready to be sent to the Area Director in a bundle. * draft-ietf-dnsop-dnssec-dps-framework New version this week. Everyone should read this and send comments to the list. Should be ready for WGLC in a few weeks. * draft-ietf-dnsop-resolver-priming Still expired but the authors are working on an update. Constant discussions about signing root-servers.net. Others outside IETF want that, but not the WG. * draft-ietf-dnsop-respsize Expired, but Akira Kato has informed the chairs that he is ready to submit an update. Will mention EDNS0. * draft-ietf-dnsop-dnssec-trust-anchor New version submitted. Went to WGLC last year, but the new version does have some substantive changes. Ask the WG to read it and comment. ------------ 7.1) DNSSEC History Project (20:10) Steve Crocker DNSSEC is now twenty years old and is finally being deployed. The DNSSEC History Project (https://wiki.tools.isoc.org/DNSSEC_History_Project) is an attempt to capture the history of DNSSEC, to credit the people, and to learn the lessons. Request for everyone who has contributed to add recollections, history, documents etc. to the wiki. The project just wants to gather information before it is lost. Questions: (25:52) Wes Hardaker: What are you going to do with the document when it's completed? Steve Crocker: No plan, as yet. Hope is that when we get a critical mass of material, other people will sort it out and put it in the appropriate format. Viewing it as an accumulation of source material at the moment. ------------ 3) Active Drafts 3.1) draft-ietf-dnsop-dnssec-key-timing-01.txt (28:25) Johan Ihren At the start the editors thought they had the subject matter named, however it has turned into an exercise of tracking something that is changing. Now trying to wrap up the work; a question on how to proceeds was posted to the mailing list and the answer was to publish now. If the document is published, what is the next step? Things that the document does not include are: * Gradual State Transitions * Rollover Centric Logic And Terminology * Common Signing Key Rollovers * Algorithm Rollovers * Layout changes - break it into separate documents? Is the document ready for WGLC? Should the editors aim for a -bis for the missing topics? Guidance is requested. Chairs (Peter Koch): How many have read the document? About 10. Questions: (40:40) Ed Lewis: Document is very deep. More variables than an operator understands and more detail than they need. Regarding CSK, are we jumping the gun? Only had 4 months of signed root, not a lot of experience of rollovers. Have had a couple of glitches in rolling keys. Don't think we are too slow in documenting it, we are still learning. Will find new modes of operation. Is it immature to write this much detail at this point? Johan Ihren: Agree with that. Document is not about how to do it, document describes alternatives for implementing software to do key rollovers. Have tried to document alternatives, but best practices are in 4641bis. Justification is that most people will use software to roll keys; good if software does not make same mistakes. Chairs (Peter Koch): Are you suggesting that software authors are target audience rather than end operator? Johan Ihren: Yes. Andrew Sullivan: What do you think the work rate on a -bis document would proceed? Some gaps in current document; would be nice to work on bis document, but not good for software authors for there to be an RFC that is wrong. If we need next round we need to start now - only useful if timely. (Andrew Sullivan is volunteering to work on the document.) Johan Ihren: Agree, but contest the idea that RFC would be wrong - the current draft is not wrong, it is just not complete. Andrew Sullivan: Agree, meant incomplete. Michael Graaf: Suggest that it is broken up into several documents and cover topics separately e.g. algorithm rollover, salt rolling. DNSSEC zone maintenance may be a better category. Johan Ihren: Do you mean current document? Michael Graaf: Follow-on work should be split. Richard Bellgrim: What do we get by publishing as RFC if we know that there is stuff missing? Johan Ihren: Main point is that people can refer to it (as opposed to referring to an Internet Draft). Also, no intent to remove chunks of stuff from a -bis document. Chairs (Peter Koch): We are aiming at Information here? Johan Ihren: Yes. Information, not BCP Chairs (Peter Koch): Of those who read it, should we do a last call and publish as a single document? About 8-9. Pending any comments on the list, this will be last-called soon-ish. ------------ 3.2) draft-ietf-dnsop-rfc4641bis-05.txt (49:43) Chairs (Peter Koch): Main editor is asking for guidance - chairs working on that. Will consult with Olaf once he's available. Document is more or less ready for last-call, although the intention is to wait until current discussion is settled. ------------ 4) Other (non WG) Internet-Drafts 4.1) draft-livingood-dns-whitelisting-implications-01.txt (50:56) Jason Livingood In whitelisting, the name server sends AAAA records to a resolver based on an ACL. Reason is that some impairment can occur if both A and AAAA records are published; traced back to range of operating system/home gateway issues, primarily related to transition technologies. Draft tries to catalogue all the potential implications and discusses possible solutions. This presentation has been made at several working groups, there is a need to decide where it should live. Questions: (1:05:00) Mohsen Souissi: We should forget about this this technique because it would be a real nightmare if its deployment is general. Johan Ihren: In slide 3, you query for www.example.com but you query for a domain name and type. Which is the type you query for? Jason Livingood: Just a an end host trying to discover an example. Johan Ihren: What type of query? A, AAAA, both? Jason Livingood: Just describing that if both A and AAAA are published, typically querying for both. Peter Koch: Not about query, it is about the responses. See the AAAA only if you ask for it. Johan Ihren: Still a server that sees a query and decides what response to send. Mark Andrews: If you do an A query or a AAAA query, the only one you will get back is the A. Diagram could be a bit clearer. Chairs (Peter Koch): How many people have read the document? 6 or so. (Unknown): Where is the draft going to go? Chairs (Peter Koch): Still to be determined - presented to three groups this week. Question to this group is whether there is enough DNS-specific work for it to be taken into DNSOP. Jason Livingood: Suspect it will end up in V6OPS Olafur Gudmunsson: It seems that there are two drafts in the document - the background information, and the possible recommendations. From the DNS side recommendations we should just say, you could do it, it's just when you will suffer the pain. We should say don't do it, it's better to suffer the pain now. Peter Koch: Is this DNS pain or V6 pain? Olafur Gudmunsson: Both. Peter Koch: How is this different from load balancing tricks? Olafur Gudmunsson: We can still recommend against them. The informational document should go out. Jason Livingood: Another document that has been suggested is one that describes all the impairments. Andrew Sullivan: No opinion on splitting documents. Thinks that this belongs in V6OPS; would be nice if we could get one or two people to follow this through V6OPS. Chairs (Peter Koch): How many people are regular attendees of V6OPS? 5-6. How many would follow this stuff? 5. Mohsen Souissi: Should we push it to V6OPS, should we recommend that it be split? Chairs (Peter Koch): That would be for the other working group. V6OPS have twenty-five documents on the agenda, this is not coming up before the next IETF. Ron Bonica is the area adviser for both WGs and has voiced an opinion in favour of V6OPS. ------------ 5) New Topic: Approaches to a Name Server Control Protocol (1:13:53) 5.1) Overview and NSCP preparation summary Chairs (Peter Koch): Nameserver Management Requirements document has passed IETF last-call and is with the IESG. Have seen two proposals for implementation - each will be presented by one of the authors. The questions to the working group are: * How do the proposals match requirements * How should we go forward - which one, a combination, something else? Jelte Jansen tried to get BoF running this IETF working on this topic, but it has ended up here. Jelte Jansen: There was an informal meeting last IETF with about 14-18 people to see if there was an interest in this area (as DNSOP had ruled this work out of scope). Got a mailing list (nscp@ietf.org) and discussed scope. One big discussion on whether scope should include zone contents. IAB/IESG directed us back to this working group as main proposal was based on NETCONF and this is not seen as a separate protocol. Also one other document using in-band data to propagate configuration. Chairs (Peter Koch): Work ruled out of scope because were still working on requirements document. Protocol work is not DNSOP business; for a long time the NSCP proposal was the only one on the table and it looked like too much overhead to set up BoF when there is a working group that could handle it if the charter was altered. 5.2) draft-kong-dns-conf-auto-sync-01.txt (1:19:40) Ning Kong This draft only focuses on synchronizations issues with the name servers using in-band DNS data. Reason because (a) there is a strong relationship between the configuration of related nameservers - extend functions of nameservers to include synchronisation of configuration data and (b) zone transfer protocol have ben proven to be effective. A configuration Record (CR) contains sentence or clause of the configuration; some fields in the DNS data are overloaded to achieve this. 5.3) draft-dickinson-dnsop-nameserver-control-01.txt (1:31:45) Stephen Morris Looks for a common way of controlling nameservers. To allow the clients to understand the server, the draft defines a common object model. NETCONF was selected as transport mechanism because it provides the necessary protocol superstructure as well as the basic operations needed to control naemservers. Also extensible via NETCONF capability. Solution does fit many of the requirements outlined in the nameserver management requirements document. Questions: Stephane Bortzmeyer: What about implementations of NETCONF? Stephen Morris: OpenSource implementation written by one of the authors. 5.4) Discussion (on both drafts): (1:41:22) Chairs (Peter Koch): Want comments, discussion, remarks. Question though, is this something that the WG would like to see done in one way, another or a combination. What is the WG's idea of following either path. Dan Romanscanu: There are also a number of non open-source implementation of NETCONF available, including commercial implementations. Wes Hardaker: Have have notion of development of protocols. When IETF develops protocol, at first they are not managed, then they get to the point where they can be managed by a management protocol. Eventually they get to point where amount of configuration needed goes down because management gets smart. Go from files to remote management to self-management. Say this because there are two problems to solve. Managing initial configuration of mater nameserver requires a lot of work. Slave configurations are simpler - can accept a lot of configuration from master. In summary, may need a blend of both solutions. Small devices may not be able to include NETCONF in the box; full featured master is a very different problem. Make sure you talk to smaller devices as well as bigger ones. Michael Graff: Why not RESTful interface as opposed to NETCONF/In-band solution? No answer expected - I'm a big fan of REST & think it's right for a lot of things. In response to Wes, not certain that master and slave are designations for nameservers any more. May want to promote slave to master and then it gets complicated. In response to using DNS as a transport mechanism, there is no encryption, so can't configure a TSIG key safely. Lot of people who want to use DNS protocol as solution for everything - DNS protocol is for DNS and configuration is out of scope for it. Configuring over same channel users are talking on is worrying. Also, more you throw a named.conf file into a DNS hierarchy, the more it become like XML - so why not use XML? Ed Lewis: Mentioned that server might become slave or master. Severs can be both. Two types of management - some people manage servers because they are hosts that do DNS, some because they are publishing a zone. E.g. "Allow Recursion" - would do that on a host basis, "Allow Dynamic Update" would be done on a zone-by-zone basis. So we have two competing ways of managing them. Need to break down options mean into who management them, how do we group them together. Have looked at draft-kong-dns-conf-auto-sync proposal and there are some reasons to do things in-band, but there are questions on how to do that. Do have authentication etc. and ways of passing stuff around - just a matter of formatting data. With XML there are more code paths - it's a toss-up as to which is the best. Mark Andrews: With EDNS tried to reuse existing fields - in reality we only need to keep first three bytes sane to talk on port 53 - after that you can do anything. Don't limit yourself to trying to fit in same record structure. Chairs (Peter Koch): How many have read the requirements document? An astonishing 27! How many have read the auto sync draft? 10-ish. How many have read the name server control draft? 10, not all the same people as above. Chairs (Peter Koch): We did not expect to come out with a real answer, but need to make some progress. Unless we have enough editors and reviewers to go both ways, we need to do a quality comparison of the proposals and hold them against the requirements. Both proponents have done that from their own perspective, but really need a neutral party to do comparison. Has also been said that in different environments both approaches might have justification - any comments? Andrew Sullivan: Clarification - high quality comparison or compare documents for quality? Chairs (Peter Koch): High quality comparison. Antoin Verschuren: Not clear what we are trying to solve here. Like the idea of nameserver configuration in nameservers, but if it is about scaling, should have a configuration system ruining already. Gets harder if you're crossing administrative borders. Is this a DNS problem or a DNS vendor problem - why has no vendor invented something? Looking for standard - is this true? Chairs (Peter Koch): During work on requirements documents, desire was to have vendor-independent interface that can be used with different products. Looking at two different proposals to go forward. Antoin Verschuren: Are we trying to solve network configuration issue or is it something that should be implementd in nameservers. Stephane Bortzmeter: Common to have nameservers in different domains so need to be able to cross administrative boundaries. (Audio Record Ends) Chairs (Peter Koch): No clear path forward. The authors should write pros and cons about their documents and post to the list. ------------ 6) I/O with other WGs MIF Chairs (Peter Koch): There is a new New MIF charter. How many are aware of this WG? - about 10. ------------ 7) A.O.B. None. Meeting Ends 19:40