----------------------------------------------------------------------------- dnsop WG minutes for IETF 70, Vancouver, CA ----------------------------------------------------------------------------- WG: DNS Operations (dnsop) Meeting: IETF 70, Vancouver Location: The Westin Bayshore Resort and Marina, "Salon A" Date: Monday, 03 December 2007 Time: 09:00 - 11:30 (UTC-8) Chairs: Rob Austein Peter Koch Minutes: Shane Kerr Jabber: xmpp:dnsop@jabber.ietf.org J-Scribe: Andrew Sullivan, Antoin Verschuren J-Script: http://www3.ietf.org/meetings/ietf-logs/dnsop/2007-12-03.html Audio: http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf70/ietf70-ch5-mon-am-dnsop.mp3 WG URL: http://www.dnsop.org Material: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num =70 Version: $Id: ietf70-minutes.txt,v 1.3 2008/01/22 22:24:00 pk Exp $ ----------------------------------------------------------------------------- 1) Administrivia [ 09:02 {audio 0:06:38} ] Tools website for latest documents: Agenda Bashing. No changes. Posted at: All meeting materials on proceedings page: Thanks to jabber scribes (Antoin, Andrew) and minute taker (Shane)! 2) Status Update [ 09:05 {audio 0:08:35} ] - RFCs published -none- - Internet-Drafts in RFC Editor Queue -none- - I-Ds at the IESG [draft-huston-6to4-reverse-dns-07.txt] "DISCUSS" Not a WG documented, but individual submission, brought to the WG for review and comments. Ron Bonica (OPS AD): INT AD put a DISCUSS on it, should clear shortly. Document itself is fine. [draft-ietf-dnsop-reflectors-are-evil-04.txt] "Revised ID Needed" See (4.6) - I-Ds in or past WGLC [draft-ietf-dnsop-default-local-zones-03.txt] Rob recused, Peter feels there is consensus. Awaiting PROTO writeup Mark will submit clean new version (-04) by end of IETF70; First change is fix to example, second change is fix to remove use of undefined term ("centrally assigned"). Reason to have -04 is to submit clean document to IESG; typos and such. 4) Active Drafts [ 09:12 {audio 0:15:40} ] 4.1) AS112 [draft-ietf-dnsop-as112-under-attack-help-help-01.txt] [draft-ietf-dnsop-as112-ops-01.txt] Resubmitted with only minor changes to revive expired drafts Mohsen Souissi: Isn't it a good idea to make some dynamic reference somewhere? In case of prefixes we don't know today? Joe Abley: We had this conversation in Prague. There were some complications adding/removing servers, and this document explains what is done today. So changes to how it would be done in another document. Mark Andrews: My draft does create a registry, and does not require coordination between different sites. Peter: We decided to keep this issue separate, because the properties of adding/deleting of new address ranges were subtly different. Chairs will issue WGLC on these soon. 4.2) Referral Response Size Issues [ 09:17 {audio 0:20:18} ] [draft-ietf-dnsop-respsize-08.txt] Editors updated/revived the draft. Akira Kato: Most of comments have led to modification to text. After Chicago there was discussion around the deployment of EDNS0 92%+ of queries have EDNS0 at one of JP servers. IPv6 and multi-homed servers sections updated. Going to publish -09 just after IETF meeting, and then ready for WGLC. Will address comments received by 2007-12-10. Awaiting WGLC 4.3) Reverse Mapping Considerations [ 09:19 {audio 0:22:58} ] [draft-ietf-dnsop-reverse-mapping-considerations-05.txt] Andrew Sullivan: feels draft is essentially ready - a few nits received last week. Aside from that ready to go. Awaiting WGLC 4.4) DNSSEC Trust Anchor Config and Maintenance [ 09:21 {audio 0:25:03} ] [draft-larson-dnsop-trust-anchor-02.txt] Formal adoption pending. Discussion and review needed. 10-15 people had read the draft and supported adoption as a WG item. Confirmation to be requested on WG mailing list. 4.5) DNS Resolver Priming [ 09:22 {audio 0:26:14} ] [draft-ietf-dnsop-resolver-priming-00.txt] No progress. Some offline comments to be incorporated, some discussion on the mailing list. No further comments or discussion. 4.6) Recursive Nameservers in Reflector Attacks [ 09:23 {audio 0:27:18} ] [draft-ietf-dnsop-reflectors-are-evil-04.txt] The draft received 4 DISCUSSes during IESG review, including 2 from Security ADs. Joao Damas presents list of identified and open issues. Missed submission deadline for -05 revision, but URL for preview given. {Discussion of feedback from IETF Last Call} Issue 1: Need to rephrase description of the attack to avoid formal language and acronyms and provide more prose. Hopefully more understandable now. Issue 2: Overemphasis of BCP 38, need to clarify role of BCP 38 vs. role of operators of open recursive name servers. Authors still think that if BCP 38 was implemented the attack would not be a problem. Have changed focus away from BCP 38 to specific configuration of the resolver. DNS and network operators not usually the same people! Issue 3: Some reviewers believe ORNS are needed to support mobile users, especially to protect them from data capturing or modification in "hostile" environments (e.g., hotels) Editors suggest to introduce VPN as another option. To start the discussion Peter explains that one concern explicitly raised under issue 3 is that one needs to think about the implications and side effects when a service is disabled for security reasons. Roy Arends: Open resolving name servers are a very, very bad thing. I'm concerned that we need a hum or working group support to highlight that. People who have open name servers for mobility - do they also need open mail servers? Peter: Difference is a single open name server is not immediately harmful. A single open mail server can still do harm. Joao: Yesterday at the IEPG a presentation showed that there are 16 million open resolvers. Dave Hankins: Another difference between DNS and SMTP open resolvers. In SMTP clients can identify and authenticate themselves. Peter: Document already mentions TSIG and SIG(0), but their availability was questioned. Bill Manning: Concerned about the binary nature of open and closed. Resolver is only useful if open to some. Would suggest everyone ran their own caching entity. Joe Abley: If the question is: "Is it necessary to run an open recursive name server to support roaming users?" - clearly not! If the question is: "Is it reasonable?", then it is a balance between convenience and risk, which is what the draft is all about. Maybe should focus on how the wrong conclusion could have been drawn from the draft. Peter: If we recommend closing all open recursive name servers, then the option to use them for mobility would no longer exist. Following the SHOULD to the letter would leave the opportunity to continue this support of roaming users. AD DISCUSS asks us to consider strength of recommendation. Joe: IETF can't make a "MUST" when it comes to operational policy. Rob: Agree that "SHOULD" is the right word. Also, RFC 3833 already addresses the attack by the hotel provider. Mark: With hotels it doesn't matter where you try to direct the DNS queries, because they'll intercept your packets anyway! Frederico Neves: Two options: 1) local recursive name server 2) addition of VPN (now new in draft) Mohsen Souissi: Another option is to manually update the configuration during mobility. Joao: IP address based access control is mentioned already. Peter: Anyone in support of the objection? - (No hands) Who is not in support? - (Lots of hands) Who did not care? - (Couple of hands) Peter: Who is in support of the VPN option? - (A few hands) Who is opposed to it? - (No hands) Peter asks the editors to incorporate the comments and resubmit the draft as -05 in coordination with AD and PROTO shepherd. Shane: What is the expected next status? Peter: Shepherding AD responsible to make sure comments are addressed. 3) WG Charter [ 09:49 {audio 0:52:45} ] No progress, edited version to be WG Last Called 5) Current & New Topics [ 09:51 {audio 0:54:20} ] 5.1) Design Team Report: Requirements for a Name Server Control and Configuration Protocol In Chicago it was agreed upon to form a design team to draw a broader picture of name server management and to produce a list of potential work areas and requirements and non-requirements. Jaap Akkerhuis volunteered to lead the team. Jaap Akkerhuis: Hard to get people to understand they are supposed to follow IETF process. Task is to define requirements, hoped to have by this meeting. A mailing list has been set up with some initial discussion. 5.2) Input to the Design Team Discussion [ 09:53 {audio 0:56:45} ] Peter explained that due to the WG schduling the design team didn't have the chance to meet yet, so instead of a report the time slot would be used to provide public input to the design team discussion. Nothing is yet to be considered for adoption as a WG item and this should also not be considered design team output. Steve Morris: NSCP Progress Alexander Mayrhofer: Would suggest user-level configuration of a name server also. Such as switching on and off recursive or caching functionality. Mohsen: Thought goal of design team was to work on requirements. This seems like a mixture of solution and requirements. Roy: What you just saw is work we started with before. We have asked the chairs if we could present this, and they reluctantly agreed. There have been other ideas floating around, document is fairly short, not much comment, but will contain the work we have done. NOT an attempt to bypass working group. Rob: A little concerned by putting zone data into this space. First, we already have a mechanism to do this. Kind of wandered into this space with the DNS MIB a long time ago. Related observation, would like a management station that can do everything. That does not mean we need one protocol that does everything. Kurtis Lindqvist: Doing a requirements document is a much better way. Requirements first! If we designed protocols based on what vendors did we wouldn't have good protocols at all. Wes Hardaker: Netconf group is just now defining how to write data models. Have to be sure you track their work so end up with the same language. Joe: If we ignore the fact that this is a framework around netconf, this is perfect input to a requirements document. Data model is the important stuff. Lars Liman: I think the goal *is* to put everything in one basket. Peter: Can't speak for individuals on design team, the team has a charter to come up with requirements and make recommendations about what to address and what not to address. They cannot just change their mission. No action required, the design team is supposed to meet during the remaining IETF week. 5.3) DNS Search Path Issues [ 10:10 {audio 1:13:50} ] Peter Koch Different behaviour has been observed in mixed A/AAAA environments with respect to following a DNS search path and terminating the search. There is no written rule yet, so with increasing v6 and AAAA deployment, inconsistencies could be painful. Some implementations seem to continue path search for "A", even after "AAAA" has been found at that path expansion. Questions: Does anyone agree that this is a problem? Does anyone have a suggestion that anyone should do something about this? Rob: Probably implementors not understanding NXDOMAIN vs. NODATA responses. Maybe we haven't written it down clearly. Mark: Very old issue. Raised this in the IETF 8 or 9 years ago and was told, "there is no problem - go away!" Number of issues here, "does a CNAME make a name exist when it points to NXDOMAIN", things like that. Think we should be trying to formalize search methods. That we have one algorithm out there, so we get to the same node in the DNS. Rob: Anyone wants to write the draft? (Mark volunteers) Anyone will read it? (Some hands) ACTION: Rob & Peter to follow up and appoint editor(s) 6) Other (non WG) Internet-Drafts [ 10:16 {audio 1:19:30} ] 6.1) draft-licanhuang-dnsop-urnresolution-00.txt The author was not present and had not sent an explicit request for adoption to the WG. Rob and Peter ask people to have a look and send comments to mailing list or author. Mohsen: Have read but don't see anything related to dnsop work. {Others support that view} Rob: How many have read? (About 5 hands) How many think it is out of scope? (Fewer hands) Rob: Probably a good idea for people who have read it to explain to the author why they don't understand it. 7) I/O with other WGs [ 10:18 {audio 1:22:10} ] 7.1) ENUM WG: Universal Deployment of EDNS0 NAPTR records apparently require this. Maybe better if dnsop had a document when EDNS0 is necessary from an operational perspective, independent of specific application (i.e., ENUM). Also might need to address ENUM-agnostic devices ("middleware"). George Michaelson: Tried to perform measurements on use of EDNS0. Occasionally get comments that it is almost universal, 90%, we can use this. I see 50% attempts specifying EDNS0. "EDNS0 is ubiquitous" is not operationally feasible. This must be borne in mind! Peter: Intent was not to declare deployment of EDNS0 done, but rather to raise the awareness that EDNS0 has to be supported as of today. Rob: Agree with George's concern. Talking to people about wildly varying deployment, shows that our sampling techniques are not good. We don't really know what is going on yet. We need to do serious measurement work. Olafur Gudmundsson: dnsext has a document in preparation that will address general DNS support in software ("DNS profile"). Will write that EDNS0 MUST be implemented. Peter: So is there overlap? Olafur: Middleboxes will have their own separate section (or sections if there are many classes). Would be wonderful if this group came up with a short document saying you SHOULD deploy EDNS0 software everywhere. Peter: Any timeline for this document? Olafur: Not optimistic about finishing it next year. Peter: Chairs need to discuss. 8) A.O.B. [ 10:26 {audio 1:29:40} ] Antoin Verschuren reported that SIDN (NL TLD registry) sees small amounts of /24 which are doing 10x rest of world in traffic (>10000 q/s). What can we do about it? How much traffic can we consider "abuse"? These are name grabbers. Long list of names that they are querying. This is a policy issue. Rob: Seems not to affect only this name server operator. Do we want to work on developing guidance? Liman: Suggest name holder or maybe server operator can set policy for their own zone. So, say, "this type of traffic we would consider an attack". Andrew: Gets us close to the idea of classifying certain domains as infrastructure versus not infrastructure. Seen people saying, "we want to treat certain labels specially", which makes me nervous. But we have the same problem! Johan Ihren: Lots of strange things come into DNS lately. Is this really a technical or operational problem, or is this a business problem that has spilled over into technical space? Traditionally we are really really bad at solving business problems in the IETF. Bernie Hoeneisen: Is there a delay between when names appear in registry and when appear in DNS? Antoin: Grace period of 40 days that we will add. Because policies differ between registries, people move to ask the DNS. Bernie: How about a random grace period? Problem can be solved by telling them when domain names are free. Joe: Is it reasonable work for DNSOP to provide guidance for dealing with unwanted traffic? Like root-server guidelines, but for other operators. Kurtis: Presented something similar to that in Paris. Chairs suggest any such guidance would fall into the charter, someone would need to write a draft first. ----------------------------------------------------------------------------- Z) Meeting closed [ 10:37 {audio 1:40:30} ] -----------------------------------------------------------------------------