DNS Operations (DNSOP) IETF-80 Meeting Friday, 1 April 2011, 13:00 CEST ======================================================================= Chairs: Peter Koch Stephen Morris Date: Friday, 1 April 2011, 13:00 Location: Grand Ballroom, Hilton Prague, Prague (Numbers in brackets are the time in the audio record: http://ietf80streaming.dnsalias.net/ietf80/ietf80-ch5-fri-pm.mp3) ------------ 1) Administrivia [1:31:10] Minutes: Sebastian Castro Jabber: Ray Bellis, Shane Kerr Agenda changes: None ---------- 2) Status Update [1:35:43] * draft-ietf-dnsop-default-local-zones * draft-ietf-dnsop-as112-ops * draft-ietf-dnsop-as112-under-attack-help-help Documents sent to the Area Director. as112-ops draft requesting publication as Informational, as112-under-attack-help-help draft as a FYI, and the default-local-zones draft as BCP. * draft-ietf-dnsop-name-server-management-reqs Publication requested last time, some issues resolved thanks to the AD and Domain Document editor. In RFC Editor queue right now, should be published in the next few weeks. * draft-ietf-dnsop-dnssec-dps-framework None of the editors present in the room. Editors arranged a small survey among CENTR[*] members to find out how many ccTLDs have/may used the DPS draft to design or phrase their own DPS. There was a couple of responses and feedback, the editors and chairs are working to prepare a summary of this out. Then the document should be ready to go pending on any issues or feedback. The current users of this document (TLD registries) consistently left out one section, might be advisable to review the document one more time to reflect that implementation reality. [*] Council of European National Top Level Domain Registries * draft-ietf-dnsop-dnssec-trust-anchor Currently sitting on Peter Koch (chair) desk to address some of the WG chair reviews, taking it back to the authors to have a revised document, in order to ship it to the IESG. * draft-ietf-dnsop-respsize It has been revised and a message sent to the working group. There was some discussion that the size considerations on referrals responses may be affected by events. Editors have provided evidence of the contrary, it should not be a big deal. The chairs are preparing an schedule for WGLC, this document should be considered in there. Non-working group documents: * draft-dickinson-dnsop-nameserver-control Author has revised the document, seeks for comments on the mailing list. * draft-koch-dnsop-dnssec-operator-change Potential contribution to 4641bis, no intention to discuss here. No further action requested right now, will look for feedback from the mailing list. * draft-licanhuang-dnsop-distributeddns No request from the author or further advice. * draft-mekking-dnsop-auto-cpsync No request from the author or further advice. * draft-ietf-dnsop-resolver-priming Authors will have more time now to work on the document given their obligations about signing their zones are almost complete. Hoping to revive it and ship it to the IESG. No questions about these documents. ------------ 3) Active Drafts 3.1) DNSSEC Operational Practices, Version 2 draft-ietf-dnsop-rfc4641bis-06 Matthijs Mekking [1:43:22] Moving from version 5 to version 6. Improved consistency of the document, style and better wording. Added a paragraph on algorithm rollover. Added a section on stand-by keys. Added clarification text on non-cooperating operators. Went a little bit deeper on the algorithm rollover. Discussion about how to interpret section 2.2 of RFC4035, for every algorithm in the DNSKEY set you should have a signature. Validators interpret it differently, leading to different algorithm rollover mechanism. One approach is conservative, first pre-publish the signatures if not it might break, on the other hand, a more liberal approach. Draft includes description and motivation for both approaches. Added text for the stand-by keys. Added text on the non-cooperating case when changing DNS operators. Closed some of the issues because discussion stopped, so editors assumed no further action was needed. No feedback, author indicates the document is ready. Chairs (Peter Koch): How many have read this or previous versions? About 15-ish Chairs (Peter Koch): Will anyone dare to comment on Matthijs's issues? Andrew Sullivan: We should publish this thing, do it! Chairs (Peter Koch): Anyone would like to say anything? Olaf Kolkman, co-editor: - it should go out of the door. - the title indicates is a version 2, and should be Informative, not elevated to BCP level, Willing to work on version 3 in three year from now if so necessary. - DNSSEC operations is in flux. We think is a good guidance, but it might change in the future because industry is taking up on DNSSEC. Chair (Peter Koch): Thanks. Consensus is towards Information, not covering every case in perfection. Living document, we cant start on Version 3, but we need to have something done. Russ Mundy: Wants to emphasize is specially important to get the updated guidance out, a lot of the people out in the world don't know there is a set of ideas is being updated. There are some important changes between this and previous one. With .COM being signed today (applauses in the room), that would get a lot of people attention, they will start exploring and will read the published RFC. Let get this out of the door. Chair (Peter Koch): The obvious lack of opposition/issues people have with this document supports the fact it stand highest priority in the last call queue, given the length of the document (roughly 55 pages) we'd like to have an extended WGLC period, four weeks instead of two. Does anyone feels otherwise? Anything else can be handled in the mailing list. Highest priority, be prepared. 4) Other (non WG) Internet-Drafts 4.1) Establishing an Appropriate Root Zone DNSSEC Trust Anchor at Startup draft-jabley-dnsop-validator-bootstrap-00 Andrew Sullivan (on behalf of Joe Abley) [1:53:15] Problem statement: DNSSEC needs trust anchor if you want to do validation, there is a case were embedded devices boot up and they don't have a proper trust anchor (TA), how are they going to get it. It's possible this is going to be used for other cases. There is an error in the document about the date when the root zone was signed. Lots of discussion on the mailing list, people was surprised to find out you need to do NTP first before trying to get/update TA. Gives you a hint of how far we are from deep understanding how are we going to do this validation. Focus in how to get the TA for the root zone. One trust anchor is good enough for most people. Private views/split horizon is out-of-scope. Observations: - Accurate sense of time. The time sync is a important issue, the draft covers it. - Trusted copy of the trust anchor. The draft has a proposal for that. - Some suggestion that the trust history draft is not universally accepted, a lot of people find it objectionable. Based on Joe's reading, they are not going for it. They'll find something simple that can agree on. - Take advantage of existing vendor supplied secure infrastructure. Vendors already have mechanisms by which appliances/operating system can retrieve trustworthy patches. - There are other ways to do this, but this seems to be a practical low-cost alternative - Four states in the proposal (state model) 1. You don't know/have anything, therefore you can't validate 2. You got accurate time 3. Once you have accurate time, you can get a trust anchor 4. Having accurate time and a trust anchor, you can validate - Validation is possible only at the end of the process, but resolution is possible at any stage. - Out-of-band mechanism, not inside the DNS. Uses XML parsing, there is people don't like that, but there are standard toolsets. Questions to the room: - Is it a problem that needs a solution? - If it is a problem looking for a solution, should the work be done here? - If it is work to be done here, is this one of the possible solutions? Chairs (Peter Koch): Thanks Andrew, comments please. Russ Mundy: the problem space is something important that the WG should look at. It's a "reasonable" approach, perhaps not the best. The space, the question is very appropriate for DNSOP to undertake. Andrew Sullivan: Could you say a little bit more about what would be a better answer? Russ Mundy: There are a wide range by which you can do this sort of things. The other draft (trust-history) it's a reasonably one. Expresses concern about the approach, seems to be circular in establishing where are you going to begin your entire tier of trust. Not confident the mechanisms are in place to ensure the final status was obtained in a trustworthy manner. Andrew Sullivan: It's obtained with the key you got from your vendor. It's the same thing that got your operating system. If that's compromised, this won't work. Russ Mundy: That's why you want to think a little bit more. Might be fine, this is some sort of first impression. Shane Kerr: it's a problem that needs a solution, although it needs a solution when someone's system is compromised. We could probably defer the solution indefinitely. The important thing here is to describe the problem, not a good idea to propose a specific solution. Vendors probably want to include whatever existing mechanism they have to deal with this problem, for example, operating system updates. Embedded system don't do that today, probably DNSSEC is not going to be the thing that breaks security badly enough to require a solution. Whatever solution proposed by DNSOP probably won't be adopted by the vendors. They are going to need to solve it at some point, so having a description of the problem as the exact output may be it's the best way to move forward. Andrew Sullivan: Part of the inspiration for this was a discussion on the mailing list, we had a fairly large vendor who was astonished to the question: "How do you recover a device that has been on the shelves for two years", answering "Gee, that's a good question". Shane Kerr: but that's not a DNSSEC question, if you are using X.509 certificates, those have an expiration date too. That's how we keep things secure, make sure the people don't use things after the sell-by date. Johan Ihren: Agrees with Shane. It's a problem, needs a solution. The solution won't be defined in here. DNSSEC is sort of taking off, the larger community and vendors are not ready to pick this ball up yet. On this interim environment, not doing anything will be a mistake. It belongs in here for now, we shouldn't aim for the ultimate solution. We should design something that's workable for a couple of years. Olaf Kolkman: Most operating system have the wrong mechanism for updates, those are tight to keys that have the same lifetime as the operating system. We haven't zoomed in into the lifetime of a TA. We don't have experience, perhaps TAs will have a longer lifetime compared to a piece of software/operating system. The shelf problem is something that needs some thinking in terms of time-scale. There is a little of a standarization issue here. The key is actually pulled from the same organization that maintains the DNS root key, there is some agreement on what you send and what you get, documenting that is good. Not sure this is the final solution. Mark Andrews: Definitely we need to look into this area. We don't have a mechanism to publish for how long a TA should be valid for. It is part of the reboot problem here, if you lose trust, you don't know when. There is something we should be looking at. Andrew Sullivan: the mechanism this depends on tells you that, when you download the XML you got a list of all the things that happened to it. You can find that out, assuming you can get the XML file in a trustworthy way. Mark Andrews: We are looking for the key for the root, but it would be nice to have a more generic approach in terms of getting it. Sam Weiler (from Jabber): This looks like another level of indirection. Bootstrap is an interesting problem, this is the problem to work on it. I don't think this draft is the right starting point. Chairs (Peter Koch): Thank you. I think we have a couple of statements here. Let's get a sense of the room, we'll ask these questions and ask for hums. Four questions. 1. Do people believe there is a problem? good hum Sam Weiler (from Jabber): Requests for holding the hum a little bit, there is a 25-second lag on the audio feed, give a little time to catch responses. 2. Is this a problem to be solved in the IETF? 3. Do we think the problem is actually narrowed down enough to start work on it? 4. Is the working group willing to address this. We've been discussing similar problem by means of a different document, the theme has come up many times now, how do we address it? Andrew Sullivan: How many people have actually read this? Chairs (Peter Koch): Like 10-ish Andrew Sullivan: May be closer to 12-15 Chairs (Peter Koch): How many people think there is a problem? good hum Chairs (Peter Koch): How many people think the problem is well enough phrased to answer the following questions? No hum You believe there is a problem and you understand the full extent of the problem? Good hum Do you think this is work for the IETF to do? good hum, bit noisier than Question 2. Do you think should not be done in the IETF? Silence Comment from the audience: We don't know the problem, but we do know we are going to work on it. Assuming there is a problem, even we don't know what problem really is, do you think this draft a starting point? So we do have two options, we could try to adopt this document or could wait for someone to come up with a more concise phrased problem description. If you think adopting this document is the right way to proceed, please hum now (low hum). If you do not think is the right way to move forward: silence. George Michaelson: should we work on a problem statement. Chairs (Peter Koch): Yes, we'll continue from there. We need to take this back to the list to get consensus on what the problem statement is. Thanks to Joe Abley and Andrew Sullivan for taking this problem to the WG attention. 4.2) AS112 Nameserver Delegations for IPv6 draft-michaelson-as112-ipv6-00 George Michaelson [2:12:45] We all know there is stupid DNS out there. We are getting an increasing stupid DNS with IPv6. It's time to find a way to quench this while IPv6 is still small, if we wait until replaces IPv4 that's too late. The problem is: it's expensive to deal with negative answers, they get much bigger when you are doing DNSSEC. How bad is this going to get? Depends if you know what the stupid questions are. (George shows some DSC graphs with the distribution of response size based on the response code). George jokes around green is the international code for bad (because NXDOMAIN responses are noted in green on the graph). Bad signed answers are in average 800 bytes, Good answers (in red) tend to smaller sizes. Lots of bad answers. There are essentially things we think we didn't see, because there are some drafts that say: don't ask about this addresses, but we see them. What we are seeing? - We know about handling queries for private addresses - IPv6 adds 6 more cases: link-local, site-local, multicast, unique-local assigned, tunnels (teredo, 6to4). At the moment, 7% of the queries in a day are related to V6. We have 341 million queries a day due to V4, George believes one day v6 will succeed, they'll have 341 million queries for v6. That's the problem, if we get so more v6, probably this bad queries are going to scale linearly. Evidence: they grow as v6 grows. ULA related queries: 200K a day on 2009, 1.4M a day on 2011. Never meant to be globally routed. I'm not saying someone is giving a ULA into the wild, but someone is reverse querying for it. Scoped addresses: below 500,000 queries a day, now over 2.5M a day. Why would you do a DNS request against a scoped address? Tunnels: Graph in log scale, queries for tunnel addresses queries exceed global-unicast queries by one order of magnitude. We dealt with tunnels by doing a delegation for 2002, we can't do that for Teredo. Teredo is an ad-hoc per point-to-point relationship, there is no basis to map the entire v4-v6 address mapping thru each ad-hoc tunnel. These are tunnels being attempted, not being used. This is not scaling to live tunnels, but to accidental tunnels. Mapped IPv4 addresses, brilliant, it's improving. We are only doing 3.5M a day. To the point: 100x times more stupid questions than useful questions. If currently v6 is only 7% of reverse DNS, what we can expected when we get to the point is a 100% of reverse DNS. How many more stupid questions are we going to see. This is what essentially I'm trying to document: Dear IANA, can we delegate the stupid questions space into AS112. This is not a pack saying: "we are all doomed, v6 won't work". This is a pack saying: "If v6 succeeds, we are all doomed". Input on version 00 - Screwed up some RFC references, that has to be fixed. - I don't understand some of the delegation state, we have to clean what we actually ask for. - Multicast should not be included, there are sensible mappings that could be usefully managed, a registry should be created. No particular problem with that, something like AS112 should have a framework to say "actually we should undo this delegation". This raises operational concerns, but we should think about it. - there is mechanism to do AS112 management, other people is dealing with that, documenting how to manage AS112 - Instead on trying to cap a problem, shouldn't we find the software and deal with it. We should find out where this questions come from. The problem: this won't fix anything, by experience, stupid broken software lives forever. - We should make sure AS112 has a v6 prefix in the anycast cloud, is currently v4-only. In the glorious v6 future, we won't be able to reach it. This should not be fixed in this document, that should be done properly as a IANA request for delegation. Summary: I really do think this a potential problem, horrendous number of stupid queries. Work in parallel find the code and fix it, do the locally assigned zone management, and also set aside. 40 slides in 5 min (applauses from the audience) Chairs (Peter Koch): Not much time for questions. Three persons at the microphone. Mark Andrews: wonders a little bit early for this. We just sent my draft upstairs. George Michaelson: That's a really good point. Chairs (Peter Koch): The point actually is we were late with that draft. We are not too early with this one. Thanks you Mark for phrasing the question so politely. George Michaelson: I think there is a point to be made. if you send a draft upstairs that has an outcome, it's worth considering a measurement of the outcome. That's a fair observation. Andrew Sullivan: it would be better to have multiple layers and do it now. This is only going to get worse. We don't have many DNS64 deployed now, yet you can bet the well-known prefixes are going to show up in this crap. George Michaelson: That's a really fine point, that contradicts the observation that Mark made. Yes I agree. William F Maton Sotomayor (National Research Council Canada): co-editor/author of the two other AS112 draft, I applaude this work. I hope the WG adopts as one of its own. I'm seeing a lot of junk on my own DNS servers across the National Research Network because they do a lot of 6to4, I see weird Teredo traffic and a lot of attempted traffic, it's not actually completed. George Michaelson: The attempts is the important thing. People looks at the Teredo success rate and says: that can't be a problem here, but there are some much more attempted. William F Maton Sotomayor: Thanks for bringing this forward. Also raises some other operational issues, but that's better discussed in the as112-ops mailing list. Chairs (Peter Koch): Sorry Mark, we need to close the mic, we have one more draft to go. How many of you have read this document: 10-ish. Adoption to be confirmed on the list. How many people think this document should be adopted as WG item, please raise your hand: 15-20 How many people think we SHOULD NOT adopt it as WG item: no raised hands We will confirm with the jabber and take it to the list, but consensus from the room seems pretty strong. Thank you George. Chairs (Peter Koch): Finally, Matthijs. 4.3) DNSSEC Key Timing Considerations Follow-Up draft-mekking-dnsop-dnssec-key-timing-bis-00 Matthijs Mekking [2:23:15] I've been writing a personal document on the key-timing consideration, mainly because I'm interested in this topic, I'm doing development and I had some issues with the current draft. I just wanted to have it on my own language and my own terminology. Current state of the key document: it's targeted to software developers, I've heard it is incomplete because it doesn't cover single-type signing scheme or algorithm rollover. It's ready for WGLC, only minor changes allowed. Totally agreed with that, major surgery will lead to a different document. This document is basis for OpenDNSSEC design for the enforcer part. I've taken large parts of the current draft and merge it into my draft, 'cause large parts I'm actually fine, good rollover description, timings are good, I can reuse that. Added my own terminology. I've been contributing with the editors, I see this as an evolved version, not an alternative. The differences are around rollover and key. Who have read the current draft? Chairs (Stephen Morris): How many people have read the key-timing draft?, please raise your hand. Less than 10. How many people have read Matthijs draft? One Chairs (Peter Koch): For the sake of time we can't go through all the details. We have the current key-timing document, it's on our schedule to be last call and published. Would you want to do both, or do you suggest to change the key timing approach here? Please re-state that Matthijs Mekking: I don't want to change thing on the current key-timing draft, this is a new document. It's a bis version? Second approach. People think this is a good base for a bis document and put it in the WG. Chairs (Peter Koch): Can we get some reviewers to be willing to read both key timing documents? So we can have an informed decision. Andrew, Ondrej, Mark, Sebastian, Alfred. I hope the minute taker and jabber scribe have caught the names so we can catch the people. We'll ask these people to read both documents and get some recommendations for the collective wisdom of the WG. Nobody suggests to wait for last-calling the key-timing document that we currently have. Nobody feels otherwise. We are not going to wait the last call, independently the WG may or may not consider depending on the reviews, if address open issues or if it's the basis for a bis document. Matthijs Mekking: I didn't expect people to read because I didn't post it to the mailing list, thanks for reading this. Currently also working on a -01 version, got good feedback from Stephen, will make document much more clearer. We'll send it out very soon. Chairs (Peter Koch): Thanks Matthijs, send the document to the mailing list with a request for review when you publish -01 version. Almost on time. 5) Current & New Topics [Scribe note: included on the agenda, not mentioned during the meeting] 6) I/O with other WGs [2:29:04] Chairs (Peter Koch): Couple of UNS has been revisiting different working groups .... couple of uses of the DNS. Proposal on MIF. Asks for help to Andrew on the details. Andrew Sullivan: Proposal to detect if you are in a NAT64/DNS64. Their current proposal seems to go in the direction of registering a well known name and then you would do a AAAA-query for that. If you think it's a bad thing, you may want to read those. The other place we are seeing a lot of weird ideas is in BEHAVE, always a source of delight. Chairs (Peter Koch): We will have someone to send pointers on the mailing list asking for DNS-based reviews of some drafts. The chairs like to register volunteers on the mailing list to do that. Andrew Sullivan: I'll send the details to the list. 7) A.O.B. No other business, thanks for coming. Closing the session on time. [2:31:05]