Dear WG, > PS: Audio timestamps will be added for the final version.
the minutes for the DNSOP meeting at IETF70 have been updated. Please find the latest version at <http://www3.ietf.org/proceedings/07dec/minutes/dnsop.txt> and a diff attached below. -Peter
--- ietf70-minutes.txt 2008/01/04 18:48:45 1.2 +++ ietf70-minutes.txt 2008/01/22 22:24:59 @@ -16,10 +16,10 @@ 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.2 2008/01/04 18:48:45 pk Exp $ +Version: $Id: ietf70-minutes.txt,v 1.3 2008/01/22 22:24:00 pk Exp $ ----------------------------------------------------------------------------- -1) Administrivia [ 09:02 {audio 0:XX:XX} ] +1) Administrivia [ 09:02 {audio 0:06:38} ] <http://www3.ietf.org/proceedings/07dec/slides/dnsop-0.pdf> Tools website for latest documents: @@ -33,7 +33,7 @@ Thanks to jabber scribes (Antoin, Andrew) and minute taker (Shane)! -2) Status Update [ 09:05 {audio 0:XX:XX} ] +2) Status Update [ 09:05 {audio 0:08:35} ] <http://www3.ietf.org/proceedings/07dec/slides/dnsop-0.pdf> - RFCs published @@ -62,43 +62,40 @@ of undefined term ("centrally assigned"). Reason to have -04 is to submit clean document to IESG; typos and such. -3) WG Charter - <http://www3.ietf.org/proceedings/07dec/slides/dnsop-0.pdf> - - No progress, edited version to be WG Last Called - -4) Active Drafts [ 09:12 {audio 0:XX:XX} ] +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 were subtly different. - Peter: Will issue WGLC on these soon. + 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 + 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. 92%+ of queries have EDNS0 at one of JP servers. - Multi-homed servers section updated. Going to publish -09 + 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 + 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 @@ -106,20 +103,21 @@ Awaiting WGLC - 4.4) DNSSEC Trust Anchor Configuration and Maintenance + 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 + 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. No further - comments or discussion. + 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:XX:XX} ] + 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 @@ -129,10 +127,10 @@ <http://www3.ietf.org/proceedings/07dec/slides/dnsop-2.pdf> - {discussion of feedback from IETF Last Call} + {Discussion of feedback from IETF Last Call} Issue 1: Need to rephrase description of the attack to avoid formal - language and provide more prose. + 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. @@ -163,28 +161,40 @@ 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 themselves. + 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?" - clearly not! + recursive name server to support roaming users?" - clearly + not! If the question is: "Is it reasonable?", then it is a - balance between utility and risk, which is what the draft - is all about. + 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. AD DISCUSS asks us to consider strength of - recommendation. + 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. + 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) TSIG and SIG(0), 2) VPN (now in draft) + 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) @@ -192,19 +202,24 @@ Peter: Who is in support of the VPN option? - (A few hands) Who is opposed to it? - (No hands) - Peter asks the editors to incormorate the comments and resubmit + 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. -5) Current & New Topics [ 09:51 {audio X:XX:XX} ] +3) WG Charter [ 09:49 {audio 0:52:45} ] + <http://www3.ietf.org/proceedings/07dec/slides/dnsop-0.pdf> + + 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 Chcago it was agreed upon to form a design team to draw + 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. @@ -215,11 +230,11 @@ A mailing list has been set up with some initial discussion. - 5.2) Input to the Design Team Discussion [ 09:53 {audio X:XX:XX} ] + 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 input to the design team discussion. + 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. @@ -227,7 +242,8 @@ <http://www3.ietf.org/proceedings/07dec/slides/dnsop-1.pdf> Alexander Mayrhofer: Would suggest user-level configuration of a name - server also. Such as switching on and off caching functionality. + 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 @@ -259,7 +275,7 @@ 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:XX:XX} ] + 5.3) DNS Search Path Issues [ 10:10 {audio 1:13:50} ] Peter Koch <no slides> @@ -287,7 +303,7 @@ ACTION: Rob & Peter to follow up and appoint editor(s) -6) Other (non WG) Internet-Drafts [ 10:16 {audio 1:XX:XX} ] +6) Other (non WG) Internet-Drafts [ 10:16 {audio 1:19:30} ] 6.1) draft-licanhuang-dnsop-urnresolution-00.txt @@ -303,7 +319,7 @@ 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:XX:XX} ] +7) I/O with other WGs [ 10:18 {audio 1:22:10} ] 7.1) ENUM WG: Universal Deployment of EDNS0 @@ -315,6 +331,7 @@ 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 @@ -323,8 +340,8 @@ 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 Guomundsson: dnsext has a document inm preparation that - will address general DNS support in software. + 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 @@ -335,15 +352,16 @@ Olafur: Not optimistic about finishing it next year. Peter: Chairs need to discuss. -8) A.O.B. [ 10:26 {audio 1:XX:XX} ] +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 (tens of thousands). + 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: Do we want to work on developing guidance? + 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 @@ -370,5 +388,5 @@ would need to write a draft first. ----------------------------------------------------------------------------- -Z) Meeting closed [ 10:37 {audio X:XX:XX} ] +Z) Meeting closed [ 10:37 {audio 1:40:30} ] -----------------------------------------------------------------------------
_______________________________________________ DNSOP mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dnsop
