DNS Operations (DNSOP) IETF-78 Meeting Tuesday, 27 July 2010, 09:00 Chairs: Peter Koch Stephen Morris (Numbers in parentheses are the time on the audio record: http://www.ietf.org/audio/ietf78/ietf78-ch6-tue-am.mp3) 1) Administrivia (07:20) Minutes: Wouter Wijngaards Jabber: George Michaelson, Wolfgang Nagle ------------ 2) Status Update (13:30) Status was distributed to the mailing list Four documents ready to go: * draft-ietf-dnsop-name-server-management-reqs is ready, and unless there is any comment brought to the attention of the chair, it is going to AD as an Informational RFC. * Three others are going in a bundle to the AD as they all reference each other: - draft-ietf-dnsop-default-local-zones (requires a minor edit following a discussion on the mailing list). - draft-ietf-dnsop-as112-ops - draft-ietf-dnsop-as112-under-attack-help-help. Other WG documents: * draft-ietf-dnsop-dnssec-dps-framework (currently at -01) needs another update. The chairs have concern about review; we need review from registries as well as potential operators of this framework. * draft-ietf-dnsop-dnssec-key-timing has been adopted as WG draft. Some edits will be made to align with the terminology in draft-ietf-dnsop-rfc4641bis. * draft-ietf-dnsop-dnssec-trust-history was adopted last February/March. There has been little feedback on mailing list, so the plan is to initiate discussion on the list with specific questions regarding the problem space, does this problem need a solution and what properties for the solution. Minor edits are in preparation. * draft-ietf-dnsop-rfc4641bis will be discussed later in the meeting. Expired WG documents: * draft-ietf-dnsop-resolver-priming: a -03 version is in preparation. The WG had advised editors not to recommend DNSSEC validation for the priming response, but discussion around root signing seemed to suggest otherwise, so this needs to be clarified. * draft-ietf-dnsop-dnssec-trust-anchor: a -04 version needed as document is expired, bit it is possibly a last-call candidate around September. * draft-ietf-dnsop-respsize: this may have been overtaken by events as the number of queries using EDNS0 is significant but far from 100%. WG may want this to be a historic document. Chairs would like to address this with lower priority - think it is valuable and could be published after a re-edit. * draft-ietf-dnsop-reverse-mapping-considerations: unable to get consensus, but cannot let it die - the issue of reverse mapping for IPv6 is coming up in multiple working groups. We need to work on it but with lower priority. ------------ 3) Active Drafts 3.1) DNSSEC Operational Practices, Version 2 (21:35) draft-ietf-dnsop-rfc4641bis-03.txt Olaf Kolkman About six to ten people had read the draft and about the same number the status update email published on the list. The presentation and discussion centred around the seven points in that email. * Point 1. Is the advice targeted to a specific set of operators? (22:53) Feedback was received from the last IETF that document was targeted too much towards a specific set of operators. The arguments have been rearranged (e.g. use of single key instead of KSK/ZSK split has been highlighted) so the question is "are these arguments complete and fairly represented?". Has the balance that the working group asked for last time been achieved? There was little comment so if there are no objections, the editor will assume the document represents the consensus of the working group. * Point 2. Give strong recommendations or give comprehensive arguments? (25:47) The document lays out choices for operating DNSSEC (e.g. key split, rollovers etc). It tries to highlight options but not give strong recommendations. However, this makes document long and difficult to read for someone new to DNSSEC. -01 was written based on first DNSSEC deployments, but the feeling is that there is a lot to learn and that we should leave recommendations to a follow-up document. As an alternative, we could create small documents for particular environments that reference this one; but the main question is whether giving a broad set of recommendations the right way to go. Antoin Verschuren: This is a good route. Not too specific about everything, but some things on which specific recommendations - about how to do things. Should separate encryption strength and what sort of numbers you use from the document. Suzanne Woolf: Supports straw man too. There are going to be recommendations appearing in other documents as well and people choose. Recommendations are less important than having a strong document on which to form a basis of those recommendations. We need to get it out soon, and strong recommendation text is not needed. Otmar Lendll: We need document describing pros and cons but also a document with concrete recommendations for people. Numbers are going to change. For long-term maintenance, it is better to have one with arguments and other small documents with the numbers that can be updated. Also support straw man. Ondrej Sury: Hear support for straw man. There is a NIST document about key lengths, and we could point to that. Olaf Kolkman: There are arguments for key lengths but no strong recommendation for any one. Chair (Peter Koch): pointing to the other document would still need needs consensus, thus the need for agreement on ranges does not go away. Wes Hardaker: Likes straw man. Conclusions are not the most important (although they are useful) part; the most important part of the document is how you got there and all the pros and cons, and that is the need and most valuable to the end reader. Olaf Kolkman: Wants to shoot for that and wants text. Alex Mayrhofer: Separation between TLD and enterprise domain might not reflect actual effort involved in management. There are some enterprises may be much better managed than a bunch of TLDs. Olaf Kolkman: Doesn't make distinction between enterprise and TLD, more about value and trade-off risks. Alex Mayrhofer: It may be unwise to link certain operational practices to certain type of domain name. Ed Lewis: Wants to back Ondrej about the NIST documents. This group will not have a lot to say about cryptography. But the document may say there is expertise in other areas, e.g. the NIST documents. Does not have to be NIST - if anyone has good documents we can use that. Crypto is not the bottleneck in DNSSEC security. Olaf Kolkman: Hopes he can close this with this version of the document. Document moving away from crypto to saying that there are a number of operational considerations and the last choice is then the crypto parameters. Doesn't say a lot about values, what it does say is e.g. Ecker's comment that there is not a lot of value in having a KSK much larger than a ZSK. Ed Lewis:, say in document that this is what early deployers have done and so on, not a crypto proof. Olaf Kolkman: Thought he did this in this version, if not, send text. Is it broad enough and honest enough about all the arguments, he needs feedback in specifics. * Point 3. Document is targeted towards authoritative side of the DNS equation. (39:46) It is aimed at the point after provisioning chain in terms of registrar/registrant/registry (RRR), where things have been put online in a zone file. It is dealing with zone content, key management and publishing, knowing there is a client side that operate recursors and applications. Is that okay? If we want to go to recommendations for recursors, that would be a much shorter document. Chair (Peter Koch): How many recursor operators in the audience? 15-ish. Olaf Kolkman: How many operate authoritative nameservers? A lot more, about half the audience. Chair (Peter Koch): Enough for review. Jelte Jansen: Agree that client side of the document very short. And with root news, client side may be even shorter. However, this document is already long enough, so client considerations should go into a separate one. Olaf Kolkman: Leave it to the chairs to find volunteers for such a document. Antoin Verschuren: We get four documents? Olaf Kolkman: No, only commitment for one document from me. Chair (Peter Koch): Others document being talked about are about other target audiences and recommendations for them. The question is whether the IETF is the right place for such recommendations, but it is easier to talk with a proposal on the table. Olaf Kolkman: Have decided that this is orthogonal to the document, so it makes it easy not to talk about it now. * Point 4. Is advice for 5011 too strong in the document? (43:57) One open issue is trust anchor configuration. The editor has tried to address that; people thought that the recommendation for 5011 was too strong, the hope now is that the text has been modified so that that is now not the case. Still advises 5011 - can the issue be closed? Probably can't say this now with the limited number of people who have read it. Not enough review, so not sure what to do. Moves it to later. * Point 5. Maximum and minimum signature validity periods. Is it complete.? (45:32) Question to the list as to whether the document should talk about the validity periods applicable and also differentiation between validity periods over different RRsets. Section 4.4.2 tries to address that - is it complete? It is fairly new, please give feedback. * Point 6. Drop Appendix B (a simple set of recommendations). (46:56) Suggests that it should be removed (couple of thumbs up seen). Will remove it from -04 unless strong argument otherwise. Wes Hardaker: Appendix B is zone key rolling. With tools coming out, rare that people need such help. But it is not documented elsewhere, right? Olaf Kolkman: Not that I know of. Wes Hardaker: It should stay - not long (only 3 paragraphs). Thinks the argument for leaving it in is stronger than taking it out. Olaf Kolkman: Follow-up question - is it complete enough? Wes Hardaker: Let you know after next week. Ondrej Sury: Appendix B is not enough in current state, so it is better removed. Olafur Gudmundsson: Appendix B is not fully in sync with section 4.1 (Olaf Agrees) so drop it. It is for one of the little documents. Olaf Kolkman: Will drop it. Chair (Peter Koch): Wants to go over the items after the working group meeting. * Point 7. Closing Open Issues (50:09) A number of related open issues that have been addressed over past version of the document. The editor believes that all have been addressed; this is a last call to go over them. Wants to close them and possibly reopen them. Version -04 got language improvement. Erratum published is addressed in the new version. Version -04 fairly shortly published and hopes ready for WGLC. Chair (Peter Koch): Based on feedback on -04. Please read the document. Olaf Kolkman: See if we can get to last call before Beijing. Ondrej Sury: How does key algorithm rollover go together with 5011? You need to sign the zone with all algorithms: if you roll with 5011 you deprecate one key and don't use it for signing. Matthijs Mekking: If you revoke the key you have to self-sign it. Olaf Kolkman: If you revoke the old algorithm, you still sign with that key, and you still need to sign the zone with the algorithm. This is a point, but do we need to spell out this very particular corner-case in such detail? How many people are going to operate a 5011-based trust anchor? We need to identify the issue and say that if you have a 5011-based trust anchor, make sure that in the rollover process you introduce the signatures. Ondrej Sury: At least it applies for the root zone. Mark Andrews: Text saying that the zone needs to be signed with every algorithm, was added so that you can prove you could validate based on set of algorithms in trust-anchor or DS record. When you add a new algorithm you are not yet at that stage, so should not have to sign everything. You should be able to add the key immediately and sign. Olaf Kolkman: This is not an operational problem, it is a protocol specification problem. Implementers have interpreted differently. Mark Andrews: Document interpretation is that this was done to prevent downgrade attacks, it was not the intent. Olaf Kolkman: Not saying that. Operational practices need to follow the requirements as set by the protocol specification. You are saying the requirements are not valid, but if you don't follow them you will break operationally and that's what we have seen. Mark Andrews: the intent of that text, was not to prevent downgrade attacks, it was to ensure that if you have a DS set with a set of algorithms in it, you could validate everything. Chair (Peter Koch): Editing at the microphone is not a good idea here. This topic makes document even longer, the question is, is it relevant to the target audience? Mark Andrews: Yes, it is how you introduce a new algorithm. Now it says RRSIGs. first, then key. And there is no need for that. Olaf Kolkman: There is, other some implementations break then. Ondrej Sury: But that is not what the RFC says: it specifically says that you have to sign with all DNSKEYs with different algorithms. Also says you must have all algorithms in the apex for every DS record. Mark Andrews: But that is not why it was put there. Olaf Kolkman: But that is in DNSEXT, and if we give advice that breaks it we are in bad shape. Mark Andrews: Where does it break? Olaf Kolkman: Ask Ondrej. Chair (Peter Koch): Can this be taken to the list? This does not help the document. Need specific text and judge whether it can be included in the document. (Mark is going to send text to the DNSEXT mailing list.) Ondrej Sury: We can close this with having a new issue about algorithm rollover in RFC5011? Olaf Kolkman: There is an issue with 5011 in context of algorithm rollover; needs a note saying make sure you do not cause problems. Perhaps we need a recipe, but this depends on length of the document. Matthijs Mekking: 5011 may not be included in the description of regular rollover in this document. Algorithm rollover similar - before removing the key publish a little longer and self-sign revoked. Is going to look more at it. Joe Gersch (via Jabber): clarification would be good, also what happens with someone doing 5011 and then transitions to a parent. May be relevant for people in .com after .com gets signed. Stephen Morris: How much detail about timings is needed? Perhaps a similar draft to the key timing draft covering timing in an algorithm rollover. Olaf Kolkman: Draft tries to sketch out the steps, but not in detail about the timing or why. Key timing draft is aimed at implementors. Underlying question is whether the tables with transition diagrams useful? Room: useful sounds. Andrew Sullivan: Thinks they are dead weight - eliminate tables because there is another draft doing it, and because the draft is long. Suggest that editors of timing document think about incorporate them. Jelte Jansen: If we remove both tables and text there is nothing here; the other document is for implementers of automatic systems. We do need something here - either the text or the tables. Also, one of the tables looks like it is in a different format. Chair (Peter Koch): Couple of tasks, Task for editor is to produce -04 after we've had a chat. Main task of working group is to review the document especially making comments to effect that advices was followed and tested. More Not so much adding more text and issues. Olaf Kolkman: Wants to close issues, feel free to reopen, but hope we are complete in the coverage of topics, can we have a last call before Beijing, chairs need to line up review and ask reviewers. Chair (Peter Koch): We find another way to address this. Is it useful to put timeline on issue. (Someone from audience): 15 September? Chair (Peter Koch): Not 15 September because DNSEXT uses reviewers then. Olaf Kolkman: Will close issues with -04. Give four weeks review time and see what comes back. Chair (Peter Koch): How much time to give comments? Olaf Kolkman: Will publish -04 at the end of the week and will produce -05 based on the feedback. ------------ 4) Other (non WG) Internet-Drafts (1:10:20) 4.1) Automated (DNSSEC) Child Parent Synchronization using DNS UPDATE (1:11:00) draft-mekking-dnsop-auto-cpsync-00.txt Matthijs Mekking (Presentation by Matthijs Mekking) Peter Koch: There is an issue about wide glue records. If you submit glue for nameservers outside the delegated domain (which happens in some TLDs and other domains), there are issues that need to be addressed in the security considerations section. Matthijs Mekking: (Asks for clarification) Peter Koch: If I insert a glue record that impacts sibling domains, there needs to be some authentication model in place. Mark Andrews: Does not believe that any TLDs allow to add glue under a different, unless you control the delegation the glue is under. Insertion is always narrow, use may be wide. Chair (Stephen Morris): This should be taken off-line. Doug Barton (via Jabber): In registry models there is no direct communication possible between registrant and registry. Wolfgang Nagle: This communication is suitable for direct and no-direct communication situations. Matthijs Mekking: Need TSIG credentials for child-parent synchronisation. Could easily be that registrar hands out the credentials. Could do implementation via the registrar. Ondrej Sury: Not sure it fits the RRR model. You are forcing that provisioning interface onto the registry and registrar. You are forcing the registrar to create transport from your draft to the EPP interface. Matthijs Mekking: People not forced but can use this. Onrej Sury: But customers will ask for that. Not sure it its good to have provisioning interface into the registry outside EPP. Joe Abley: Conflates two relationships, the RRR relationship and also DNS people involved - server operator and registrant and the zone signer. How many people know the TSIG key makes you wonder how secure is it. Matthijs Mekking: Three parties, DNS child operator, DNS parent operator, and the registrar. Joe Abley: And Registry and DNS service operation, and the registrant. Lots of other parties. In many registries, no relationship between the registrant and registry is possible - the registrar needs to be involved. Matthijs Mekking: Have covered that, we put that the registrar can control TSIG. Patrik Faltstrom: This draft needs to work much more on the parties and trust relationships involved. Mark Andrews: replaces the http session that people use today, replaces that webpage, and it signed with TSIG rather than SSL. It is no different. Can go to any port on any machine; does not have to go through a nameserver. Can be run by registrar not have to be run by registry. TSIG can be given to the person that updates those records, you can have different TSIG for DS, NS, A, AAAA if you want to be flexible. It is very flexible. Ed Lewis: This has many unfixable problems. There is no direct relationship. Problem in provisioning side, as a registry I want to track changes. Nameserver-nameserver means I may not have that. Matthijs Mekking: Update does not have to be on the nameserver directly, can have updated and logged first and then put to EPP or file then to nameserver. Ed Lewis: During DNSSEC testing we have people come direct to us avoiding registrars. Told that when other registries did early adoption testing, this caused problems with registrars trying to keep track with what their registrants have been passing in. Have to talked to any registrars? Matthijs Mekking: No - might need to go to RIPE. Ed Lewis: Summary - problems with direct contact between nameserver up to the parent. Wolfgang Nagle: Yes we talked to registrars, we do not do talking strictly in the DNS update path. Only replace when there is currently no standard to update NS records. This update message can go anywhere, including the registrar, you bootstrap with registrar you can use sig0 or TSIG. Send the registrar the update message and he can mangle it into whatever he wants, e.g. EPP update to the registry. If you have a direct relationship between registrant and registry, you might as well do it directly. Draft is only explaining the algorithm. Shane Kerr: In an early slide, you present reasons against pull mechanism, there is other draft about pull style thing. Thinks there is a lot of problems with the push mechanism. With a pull mechanism no need to add more infrastructure. Matthijs Mekking: You are talking about CDS record, but that does not cover all the cases, maybe we have a different goal in the drafts; here we can go through registrar. Shane Kerr: Problem statement is important, we don't have problem getting information into registries. With DNSSEC and the need to change security information, it is a different problem. Andrew Sullivan: But there are problems today; if you operate a registry you get calls about troubles. This will get worse because of key rolls. Appreciate problems with multiple parties involved, but if we don't have mechanism for DNS operators to get stuff into the parent, key rolls are going to get much worse. Antoin Verschuren: The pull mechanism does not solve the contractual relations stuff. We need a mechanism to get key stuff to the parent. Seems that people missed the section that says "Proxy", and it needs to be said better. Have a choice for child to get stuff up to the parent: one is to implement EPP in a nameserver - find it an ugly hack. This is proposing a lightweight protocol to talk to anybody to say I have an update, do you accept it - I have credentials for it. Can go to anyone. We need to describe where the update needs to go. Matthijs Mekking: This is the open issue about service discovery. Antoin Verschuren: Small zones won't implement EPP and I don't want a web-based interface different for every registry I talk to. We want automatic interface, what do we use for that. Chair (Peter Koch): Work to do, disagreement about path. Also, we have a solution but no problem definition. No-so nice way out is to ask people to write a problem statement. Which part of this DNS zoo needs to be addressed and add that to this document or a straw man proposal to mailing list. Have heard that we need communication between the zone maintainer and registrar, and that we should not try mess with RRR relationship. Is that useful, and is the WG agreeing with it? First we clarify who we are not trying to disturb, then who we are trying to help? Matthijs Mekking: There is a proxy section in the draft, maybe we should get things by name in there. Chair (Peter Koch): It may be that the text needs to be more explicit or taken to the front of the document. Mark Andews: We need a couple of examples of how you actually do it. Now it has how you do it to a nameserver in the parent. We also need an example in a registrar/registrant model. Chair (Peter Koch): Wants to move up abstraction levels - Matthijs has input to go forwards on this. ------------ 5) Current & New Topics (1:35:15) 5.1) DNS Server Selection on Multi-Homed Hosts draft-savolainen-mif-dns-server-selection-03.txt Teemu Savolainen Chair (Peter Koch): This is a document in the MIF WG - have invited author here to get feedback on DNS issues. (Presentation by Teemu Savolainen) Teemu Savolainen: The document is with the MIF WG - there are three questions: 1. Is this is out of scope of DNSOP, and is it OK to advance this in the MIF WG? 2. Does split DNS needs to be defined. 3. Any comments to improve the draft Mark Andrews: It is more about pre-sorting the namespace. Namespace information on particular servers. Teemu Savolainen: Yes. for same namespace, different DNS servers may give different results. Mark Andrews: having something like this is interesting, not sure how much is really needed, having a way to advertise it is a good idea; I'd choose the same option for v4, and would not change the format of the packet - would use the same for both dhcp realms. Ed Lewis: Wants to comment about the server selection for DNS. Different DNS servers may map a name to different addresses for a reason. You cannot shop for DNS servers like you shop for routing information, and that is a misunderstanding. With multiple interfaces, I know what interface I want to use first before I look up DNS. Teemu Savolainen: Current state is that interface is selected first and that makes applications behave like a single interface host. MIF is aiming that interface selection would not be made e.g. browser in multi-homed cosy; if browsing internet.corporate.com, it would choose to use the VPN. Ed Lewis: OK, a lot of this is not about DNS. Walter Jontofsohn: Nominally you have to resolve DNS before choose interface to go out. And then first which DNS server to ask. Difficult to decide which DNS server to ask. Should maybe ask more than one DNS server and decide later which one to use. Perhaps have preferences which you trust more. But to get an answer at all, ask more than one of the servers. And not in a way that you wait for, but ask simultaneously. Teemu Savolainen: That's one option but then you wait for the slowest to reply. Not nice when connected to corporate domains on VPN and Wireless LAN hotspot at the same time. Hotspot may be faster, but only VPN can answer for private names. Also causes issues with private names - receive NXDOMAIN. Walter Jontofsohn: Simultaneous is not so bad. Ed Lewis: You are concerned about which interface do you use. Outside scope of the DNS, of WG. So work anywhere you want. You must understand DNS and the way it work instead of assuming that the DNS works a particular way and trip up on it. Take the DNS as it is. Lot of issues but not DNS issues. Teemu Savolainen: yes we have also routing policy and other issues. Chair (Peter Koch): How many people follow MIF? 7-ish. Danny McPherson: IAB draft - evolution of IP model - has text that relates to this sort of configuration bootstrapping. May want to consider that. Ondrej Sury, you want to change the stub resolver behaviour for network preferences? Teemu Savolainen: Yes. Ondrej Sury: Not really DNS issue, more client, but do not think that it will work. Teemu Savolainen: Comments appreciated. Chair (Peter Koch): How many of those 7 people read this document or architecture documents of the MIF WG? His document? About 5-6 people. (to Teemu) Did you get contacts and input? Teemu Savolainen: Yes got pointers and DNSOP is happy for MIF to look at this. Chair (Peter Koch): the DNSOP chairs will talk to MIF chairs. Teemu Savolainen: proposing this topic for inclusion MIF charter. Chair (Peter Koch): We'll get it back for review for DNS considerations to WG please look at these issues - they are operational and there are pitfalls - remember RFC1535. Jinmei Tatuya: Several suffixes possible. How many normally? Teemu Savolainen: Yes, would like input on this. Jinmei Tatuya: No particular opinion, but including many has a scalability issue, and DNS is for managing scalability of many names, thinks that this is strange. Teemu Savolainen: Thinks that only a limited number of domain names would require that special treatment. Jinmei Tatuya: Maybe not even a concern but feels that it is good to describe the scalability concern in the document. Hui Deng (MIF chair): Arranging liaison statement from broadband forum. RFC4191 is similar to this scenario. Ondrej Sury: What is target audience? CPEs, mobile phones, OS vendors?. Need to get support in all of those. If I get information on my CPE modem, is it forwarded to my operating system, or do I rely on DNS proxy in CPE (which is horrible - many don't even support EDNS0). Teemu Savolainen: Coming from host community, from mobile world. Would be mobile phone or phone OS vendors. CPE side is the proxy that decides that. Ondrej Sury: And what if I use my own resolver not proxy? Lot of problems that need to be solved before this goes live. Teemu Savolainen: Have you read draft about multihoming without Nat6-6, they describe scenario for CPE case. Chair (Peter Koch): Thank you for presenting and we will be reviewing this document later. ------------ 6) I/O with other WGs Nothing else than the MIF. ------------ 7) A.O.B. Otmar Lendl: Graph about Port randomization, from servers in Austria. 2 years after first graph (immediately after Kaminsky). More are randomised, but there is another long tail. Last slide shows discontinuous jump when large ISP altered they software. Finished business at 11:00 and handed to root team. (2:07:00)