Dear WG,
thanks to Geoff Sisson for providing the San Diego minutes already a couple of
days ago. Find the draft version below and also at
<http://www3.ietf.org/proceedings/06nov/minutes/dnsop.txt>.
The IETF67 proceedings have a deadline of December, 27th, so please send in
comments during the next two weeks (2006-12-21).
-Peter
-----------------------------------------------------------------------------
*** 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:[EMAIL PROTECTED]
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
-------------------------------------------------------------------------------
_______________________________________________
DNSOP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dnsop
