----------------------------------------------------------------------------- *** DRAFT *** dnsop WG minutes for IETF 67, San Diego ----------------------------------------------------------------------------- WG: DNS Operations (dnsop) Meeting: IETF 67, San Diego Location: Sheraton San Diego Hotel and Marina, Room "Harbor Island III" Date: Friday, 10 November 2006 Time: 09:00 - 11:30 (UTC -0800) Chairs: Rob Austein, Peter Koch Minutes: Geoffrey Sisson Jabber: xmpp:dnsop@jabber.ietf.org J-Scribe: Wouter Wijngaards, Antoin Verschuren J-Script: http://www.ietf.org/meetings/ietf-logs/dnsop/2006-11-10.html Audio: http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf67/ietf67ch6-fri-am.mp3 WG URL: http://www.dnsop.org/ Material: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67#wg-dnsop ----------------------------------------------------------------------------- 1) Administrivia [09:09 {audio 0:14:24}] Minutes scribe and jabber scribes as listed in the header. Blue sheets were circulated. The agenda as posted on 30 October was accepted without changes. ------------------------------------------------------------------------------- 2) Status Update [09:13 {audio 0:18:04}] RFCs published: - RFC 4697 / BCP 0123 - "Observed DNS Resolution Misbehavior" - f.k.a. draft-ietf-dnsop-bad-dns-res-06.txt Internet-Drafts in RFC Editor queue: - none - Internet-Drafts at the IESG: - draft-huston-6to4-reverse-dns-07.txt - now an AD-sponsored individual submission - publication requested on 24 August as an Informational RFC - never formally adopted as a WG item, but received considerable WG review. Internet-Drafts in or past WGLC: - draft-ietf-dnsop-serverid-07.txt - Update expected - draft-ietf-dnsop-default-local-zones-00.txt - WGLC done, update expected (discussion below) - draft-ietf-dnsop-reflectors-are-evil-02.txt - WGLC had been extended to 2006-11-11 (discussion below) Responding to a question, Rob Austein clarified that there must be a minimum of five _positive_ reviews for a WG document to go forward. Peter Koch further clarified that these must be technical reviews, not just nits reviews. ------------------------------------------------------------------------------- 3) Active Drafts [09:19 {audio 0:24:10}] - draft-ietf-dnsop-default-local-zones-00.txt - draft-ietf-dnsop-reflectors-are-evil-02.txt - draft-ietf-dnsop-respsize-06.txt - draft-ietf-dnsop-reverse-mapping-considerations-00.txt ------------------------------------------------------------------------------- 3.1) draft-ietf-dnsop-default-local-zones-00.txt [09:19 {audio 0:24:57}] Editor: Mark Andrews Peter Koch noted that there had been a WGLC on this document. The WG chairs had not come to a conclusion. There were generally positive comments from the WG, but some opposing. The chairs will have to make a judgement on how to proceed. There will be an updated draft. One open issue: a more detailed explanation is needed of the effect that the new recursive resolver default config would have on resolution in isolated private networks (i.e., RFC 1918 networks with own root and reverse zones). Mark said he intends to change the "effects" section to make it clear that most configurations are not [negatively] affected by local zones. Bill Manning (in Jabber room) registered his concern about "hardcoded blackholes and alternate namespaces". The chairs requested he send his concerns on the mailing list if he had not already done so. Mark noted that he wants to make the list of blackholed name spaces hard to get into, because it will be very hard to get off of. Some of the possible IPv6 name spaces have been left off pending review by the v6ops WG. Peter said the chairs will probably ask for review by IPv6 community and addressing community before publication is requested. ACTION (chairs): after the update and last call summary, the chairs will circulate changes to mailing list, ask for external review, and then progress the document. ------------------------------------------------------------------------------- 3.2) draft-ietf-dnsop-reflectors-are-evil-02.txt [09:26 {audio 0:31:12}] Editors: Joao Damas, Fredrico Neves Joao reported that he is going to make additional changes to reference BCP 84 and to provide more explicit phrasing of recommendations, so there will be an -03 draft. Peter Koch said these changes should not warrant a second WGLC. ACTION (chairs): Extend WGLC to 2006-11-19 at the request of the WG. ------------------------------------------------------------------------------- 3.3) draft-ietf-dnsop-respsize-06.txt [09:29 {audio 0:34:49}] Editors: Paul Vixie and Akira Kato Akira said that Paul had made extensive changes since the last WG meeting, but believed -06 is stable. He found some minor bugs that will be fixed in -07, but he thought it was almost ready for WGLC. Peter Koch remarked that the status of the draft is confusing: at the previous WG meeting, the sense of the room was that -03 was ready for WGLC; subsequently were many changes. The chairs were unsure whether to ask author to back out changes or WGLC the -06 draft. The sense of the room was to continue with the -06 draft. Peter asked WG to have a look at QNAME length issues in the draft: - whether query size / response size is acceptable (depends on QNAME length). - some assumptions in the document may need consideration, e.g. averaging of the QNAME sizes. ACTION (WG): Review document carefully in line with above issues. ------------------------------------------------------------------------------- 3.4) draft-ietf-dnsop-reverse-mapping-considerations-00.txt [09:33 {audio 0:38:46}] Editors: Daniel Senie, Andrew Sullivan Slides: http://www3.ietf.org/proceedings/06nov/slides/dnsop-1.pdf Andrew reminded the WG that draft was previously known by another name, so not truly a -00 draft. Andrew briefly reviewed the closed issues, then gave a more detailed treatment of the open issues: Issue 4: Strength of recommendations: the editors will try to change from using "require" to "encourage", as it's unclear whether RIRs have the authority to require reverse delegations. Peter Koch asked how many in the room have read the latest draft. Around six. He asked how many recommended against taking out recommendations completely. None. Sense of room: take it out. Issue 8: Terminology: the editors will replace occurrences of term "IN-ADDR" with "reverse mapping" and add a more formal definition of reverse mapping. Issue 10: IANA considerations and RFC 3330 (RFC 1918) space: Daniel Karrenberg has just provided suggested text. The editors will send it to the mailing list. ACTION (editors): Send suggested text to mailing list. Issue 12: IPv4 vs IPv6 considerations: some in WG believe will be tricky to encourage reverse delegation with IPv6. Another complication is that draft-ietf-v6ops-scanning-implications-01.txt has conflicting recommendations. Need to reconcile. Peter noted that two conflicting BCPs would be suboptimal. ACTION (WG): Review draft-ietf-v6ops-scanning-implications-01.txt. ACTION (chairs): Send mapping-considerations to v6ops for review. ACTION (editors): Send scanning-implications conflict issue to the mailing list as a separate issue. Ed Lewis wanted clarification whether the document is intended to recommend reverse delegation, or simply to describe how and why to do it. Andrew replied that it is more the latter, but there is an implicit recommendation. Mark Andrews stated his belief that, for IPv6, creation of reverse zones should be encouraged at all points (RIR, LIR, and end site), but the end site may then decide whether to populate. George Michaelson remarked that "reachover requests" (where the end user requests delegation of reverse zone when their LIR hasn't) are particularly troublesome in IPv6. Peter asked him to forward his remark to the mailing list. Issue 13: Motivation for reverse mapping: the editors received a comment the that the motivation for the document has become unclear. Editors will clarify. Also, some additional cases in which reverse mapping may be helpful have been suggested. In response to one received comment, Andrew asked whether anyone knows of any case where a working reverse tree is useful in ENUM. No one does. Some suggested that the comment may be attributable to confusion due to the similarity of the ENUM tree itself to a reverse tree. Editors will omit any reference to ENUM. ------------------------------------------------------------------------------- 4) WG Charter [09:52 {audio 0:56:54}] Slides: http://www3.ietf.org/proceedings/06nov/slides/dnsop-0.pdf (slide 14) Peter Koch explained that the proposed changes to the WG charter need to be written up and submitted to the ADs. One tiny piece of progress: milestones list updated. Other documents that might be incorporated into the charter: - AS112 "basket": - draft-ietf-dnsop-as112-being-attacked-help-help (candidate for FYI) - draft-ietf-dnsop-as112-ops (Informational) - draft-ietf-dnsop-as112-changes [?] (Informational?) - Proposed milestones: Q2 and Q3 next year. - Infrastructure TTLs - [Discussed in last WG meeting.] - No timeline yet. ACTION (chairs): Come up with timeline for infrastructure TTLs work. ACTION (WG): Volunteers requested for work on infrastructure TTLs document. - Monitoring and measurement - [Discussed in last WG meeting.] - No timeline yet. ACTION (chairs): Come up with timeline for monitoring and measurement work. ------------------------------------------------------------------------------- 5) Other (non WG) Internet-Drafts [09:56 {audio 1:01:32}] - draft-otis-spf-dos-exploit-01.txt - draft-crocker-dns-attrleaf-02.txt ------------------------------------------------------------------------------- 5.1) draft-otis-spf-dos-exploit-01.txt [09:56 {audio 1:01:52}] Editor: Doug Otis http://www3.ietf.org/proceedings/06nov/slides/dnsop-2.ppt [ DRAFT NOTE: to be converted to HTML or PDF ] Doug Otis described how SPF and Microsoft's variant, Sender-ID, may be utilized to effect significant asymmetric DDoS attacks. In the worst case, the attempted delivery of a single message could result in hundreds of DNS transactions (100 transactions per domain name evaluated in message or message envelope) being performed by an SPF "script". Amplification is based on: - names evaluated per message (1 - ~3) - recipients per message (1 - ~20) - evaluation points per recipient (1 - ~3) In simple case (1 name x 1 recipient x 1 evaluation point), amplification may be 64:1. In worst case (3 names x 20 recipients x 3 evaluation points), amplification may be > 11,000:1. He estimated that 100,000 bots sending one message per minute could produce DDoS traffic as high as 8 Gb/s in and 10 Gb/s out at "no cost". Doug noted that SPF publication is currently not high: ~3% of domains with MX RRs are publishing SPF records, but seeing ~30% use by "higher-volume domains". The danger comes when more receivers actually start executing SPF "scripts". [Doug did not provide estimates for SPF-enabled receiver deployment.] Doug claimed that SPF attacks will be hard to identify: the DNS traffic will come from legitimate sources and it will be difficult to distinguish DDoS traffic from legitimate traffic. He suggested the best way to avoid SPF attack scenarios may be to "promote safe techniques [of SPF evaluation] with deterministic DNS overhead". Rob Austein asked whether a one-sentence summary might be: "don't execute scripts you got from strangers". Doug agreed. Peter Koch asked whether another summary might be: "the receiver of a spam message is abused to generate a high number of DNS queries targeted at the victim". Doug agreed. Debate ensued as to whether there are other worse attack vectors than SPF, and whether the attack detailed by Doug is a simply an example of a general DNS attack. Peter asked: - Does this WG see an issue with this attack? - Is there any indication that such attacks could be mitigated via the DNS? - Is it more in the scope of an application? - Do DNS operators have a need or opportunity to counter this attack? Olaf Kolkman asked whether there are "innocent" third parties who are affected, or if only consenting SPF publishers and SPF-enabled receivers are susceptible. Doug answered that completely innocent parties can be involved. The target may be someone who neither runs mail or publishes SPF records. Ed Lewis asked whether this is a problem that's generic to any time when I try to secure an application by looking stuff up in DNS. Would this happen in DKIM? In other words, is SPF just a special case of a general architectural problem? Michael Graff asks whether there is a fundamental mistake in SPF which permits this. Doug answers that there were a number of things that could have been done to minimize the effect, but there was no single error. Michael suggest guidelines on how do design records that will not exhibit this sort of symptom might be useful. Wes Hardaker noted that DNS caching may mitigate this attack, but Doug countered that the attack facilitates randomization, so caching could be rendered useless or even harmful. Peter summarized that Doug presented an attack that is application-level, and asked two questions: 1) Do we have a specific question to the WG regarding this issue? 2) Are these attacks being seen in the wild? Doug says he's seen indications but has no direct evidence, but that in any case it is a threat. Peter asked: "do we feel a need to, or are we able to, provide guidance to the applications area or specific applications protocol designers, how _not_ to make use of the DNS, but this time not `how not to design records', but how not to initiate DNS queries based on unauthenticated initiation". Peter concluded that "we're going to think about this a bit". One of the proposals to extend the charter was evaluating or providing guidelines to use of the DNS in other protocols. This work item might fit there. ACTION (WG): further discussion to go to the mailing list. ------------------------------------------------------------------------------- 5.2) draft-crocker-dns-attrleaf-02.txt [10:39 {audio 1:43:35}] http://www3.ietf.org/proceedings/06nov/slides/dnsop-3.ppt [ DRAFT NOTE : to be converted to HTML or PDF ] Dave Crocker prefaced his presentation with a warning that -03 is already underway with significant changes. Specifications exist or are in development that attach special semantics to names that begin with an underscore. An underscore name typically specifies a scope for specifying attributes associated with the parent domain. Typically used with SRV and TXT RRs. The document attempts to steer clear of judging the practice; instead, it attempts to document existing use of underscore names and create a registry for them. This incurred much more controversy than expected. The proposed registry specifies some RR types for use within a scope, and leaves others unspecified. Semantics are defined in respective RFCs, not in registry. Recent discussions have suggested a hierarchical model, with each right-most underscore label getting its own subregistry. Dave showed some sample registry entries. Olaf Kolkman said one thing that's important is that several of the scopes define ways to add new entries. IANA has to be told under which circumstances a new entry may be accepted. Rob Austein noted his concern that the table mechanism may be too complex for IANA to administer. IANA will need very clear instructions and hand-holding. Discussion ensued over whether a true registry is required, and whether it is a proper function for IANA. Dave remarked that a registry a) helps prevents collisions and b) helps people in the community find things. Peter Koch (no hats) noted his concern that establishing a registry before establishing architectural guidelines may be premature. (Guidelines for using underscore labels are currently under consideration in draft-iab-dns-choices-04.txt, which Olaf reported is currently blocked on draft-ietf-dnsext-2929bis-03.txt.) Dave agrees that when to use underscore labels is an important debate but doesn't see need to wait for draft-iab-dns-choices. Olaf suggested that there should be a normative reference to draft-iab-dns-choices in this document. Rob asked Dave whether he was wanted the WG to adopt this document or to keep it as an individual draft. Rob warns that even if submitted as an individual document it will probably end up as a WG document. Rob asked for a hum for whether to take this topic on as a WG item: "People who think that the WG ought to be working on this topic as a WG item, please hum" Room: [significant hum] "Opposed" Room: [silence] RESULT: strong support for taking this topic on as a working group item. ACTION (chairs): Confirm adoption of this topic on mailing list. ------------------------------------------------------------------------------- 6) Current & New Topics [11:11 {audio 2:16:20}] - AS112 - Classless Delegation (RFC 2317) experiences - DNS search path considerations ------------------------------------------------------------------------------- 6.1) AS112 [11:11 {audio 2:16:25}] - WG approved acceptance of this work basket on the mailing list. - -changes draft needs to be specified - Issue was raised as to why to do work on AS112 in the first place. May have to be addressed, but shouldn't block progress. There was some discussion of the last topic, to be continued on the mailing list. ------------------------------------------------------------------------------- 6.2) Classless Delegation (RFC 2317) experiences [11:15 {audio 2:19:54}] Peter introduces: Mark Andrews had commented on namedroppers that classless delegation (RFC 2317) needs a review. Some issues that could be addressed: - BCP that the server with the child zone should also serve the parent zone. - TTL synchronization - Clarifications of existing text Mark Andrews adds: - Make sure ISPs know that they're supposed to allow the parent zone to be transferred. ACTION (WG): Volunteers for editors sought, preferably having hands on experience with user services issues. Please let chairs know. RESULT: Come up with a proposal in Prague. ------------------------------------------------------------------------------- 6.3) DNS search path considerations [11:19 {audio 2:23:16}] Peter Koch explained that the DNS search facility has some drawbacks that are already documented in RFC 1535. This particular problem is still prevalent. Also, there are recurring proposals to use DNS as a discovery protocol. Finally, there are issues with some resolvers implementations in mixed IPv4 / IPv6 environments where there are inconsistencies between the treatment of queries for A vs. AAAA RRs. Mark Andrews remarked that libresolv is a "guilty party". He supports a recommendation document on search path as he cannot change the behavior of libresolv without an RFC. ACTION (WG): Send draft text (short of an I-D) to the mailing list and decide whether it should go forward as its own I-D or be incorporated into another clarifications document. ------------------------------------------------------------------------------- 7) I/O with other WGs [11:23 {audio 2:27:30}] - dnsext: DNS cookies operational requirements - dnsext: DNAME operational aspects - v6ops: draft-ietf-v6ops-scanning-implications-01.txt - mboned: draft-koch-mboned-mcast-arpa-00.txt - geopriv: draft-schulzrinne-geopriv-relo-01.txt ------------------------------------------------------------------------------- 7.1) dnsext: DNS cookies operational requirements [11:23 {audio 2:27:38}] Peter Koch noted that at the last meeting the WG agreed to come up with operational requirements / considerations for implementing a cookie-based DNS scheme described in draft-eastlake-dnsext-cookies-01.txt ACTION (chairs): Phrase the question and then take it over to the dnsext WG. ------------------------------------------------------------------------------- 7.2) dnsext: DNAME operational aspects [11:24 {audio 2:28:45}] Wouter Wijngaards said there were comments on draft-ietf-dnsext-rfc2672bis-dname-00.txt on namedroppers that some of the issues were more operational in nature, but not enough to merit a separate draft. Specifically, using DNAME to mirror one a part of the domain tree to another is very operational. ACTION (WG): review operational aspects of draft-ietf-dnsext-rfc2672bis-dname-00.txt on namedroppers Peter Koch noted that the document itself will remain a dnsext document and will be discussed solely on namedroppers. ------------------------------------------------------------------------------- 7.3) v6ops: draft-ietf-v6ops-scanning-implications-01.txt [11:27 {audio 2:31:27}] As mentioned earlier, Peter Koch encouraged the WG to review this draft, noted that it will be WGLCed in v6ops soon. RESULT: Peter asked for two volunteers to review this document. Andrew Sullivan volunteered. ACTION (WG): Additional volunteer sought to review this document. Please let chairs know. ------------------------------------------------------------------------------- 7.4) mboned [11:27 {audio 2:31:45}] draft-koch-mboned-mcast-arpa-00.txt: details migration of MCAST.NET to MCAST.ARPA (now adopted as an mboned WG document). Might want to review this here as it has migration issues. ACTION (WG): WG should keep an eye on this migration. ------------------------------------------------------------------------------- 7.5) geopriv: draft-schulzrinne-geopriv-relo-01.txt [11:28 {audio 2:32:17}] John Schnizlein explained that the text in draft-schulzrinne-geopriv-relo-01.txt is clearest statement of a general approach in geopriv WG to solve the problem of how a client finds its location server. The document proposes that clients find their location server using NAPTR RRs in the DNS. He described the technique in detail, and asked the WG whether this is a good use of the DNS. George Michaelson asked whether there is any meaning in a value returned from a higher delegation point, or if it's only meaningful if the result is for an endpoint? If the former, then RIRs may find they have to support data type in the reverse tree. Peter Koch clarified that the scenario is that something is sitting on a dialup or DSL line and is trying to find a server. ACTION (WG): Review of document encouraged. RESULT: Andrew Sullivan and George Michaelson volunteered to review this document. ------------------------------------------------------------------------------- 8) A.O.B. [11:36 {audio 2:40:05}] - none - meeting adjourned -------------------------------------------------------------------------------