-----------------------------------------------------------------------------
dnsop WG minutes for IETF 69, Chicago, IL USA
-----------------------------------------------------------------------------
WG: DNS Operations (dnsop)
Meeting: IETF 69, Chicago
Location: Palmer House Hilton, "Monroe"
Date: Tuesday, 24 July 2007
Time: 09:00 - 11:30 (UTC -0500)
Chairs: Rob Austein, Peter Koch
Minutes: John Kristoff
Jabber: xmpp:dnsop@jabber.ietf.org
J-Scribe: Jaap Akkerhuis, George Michaelson
J-Script: http://www3.ietf.org/meetings/ietf-logs/dnsop/2007-07-24.html
Audio: http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf69/ietf69-ch8-tue-am.mp3
WG URL: http://www.dnsop.org
Material: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=69
Version: $Id: ietf69-minutes.txt,v 1.1 2007/08/24 20:40:16 pk Exp $
-----------------------------------------------------------------------------
1) Administrivia [ 09:02 {audio 0:11:08} ]
Tools website for latest documents:
Agenda Bashing. No changes. Posted at:
All meeting materials on proceedings page:
2) Status Update [ 09:05 {audio 0:14:00} ]
- RFCs published
RFC 4892 "Requirements for a Mechanism Identifying a Name Server Instance"
Was .
Thanks to Suzanne Wolf and David Conrad.
- Internet-Drafts in RFC Editor Queue
-none-
- I-Ds at the IESG
[draft-huston-6to4-reverse-dns-07.txt]
Not a WG documented, but individual submission, brought to the WG for
review and comments.
Describes services by the Number Resource Organization (NRO).
There were four DISCUSSes, 1/2 DISCUSS and a COMMENT. Working
on resolving these with Geoff Houston (author) and George Michaelson
(implementor). Problems primarily due to age of document and history
it has had within the IETF. Particularly the alleged view that
this was another 6to4 transition mechanism, which it is not. Chairs
are confident outstanding issues will be cleared up. The two
DISCUSSes related to security section are also being worked on.
- I-Ds in or past WGLC
draft-ietf-dnsop-reflectors-are-evil-03
Passed WGLC. One more revision, -04, needed to incorporiate
nits and some wording changes are needed. Not submitted in time
for the last Secretariat update, but as soon as the next round
goes out it should be ready for the IAB and IESG and on towards
becoming a BCP.
draft-ietf-dnsop-default-local-zones-02
Passed WGLC. Waiting another editing round, clarifications and
language changes.
draft-ietf-dnsop-respsize-07
In WGLC, ends 2007-08-22 (see below).
draft-ietf-dnsop-as112-under-attack-help-help-00
In WGLC, ends 2007-08-22 (see below).
3) Active Drafts [ 09:11 {audio 0:20:23} ]
3.1) AS112 Work Basket
draft-ietf-dnsop-as112-under-attack-help-help-00
Editors: Joe Abley, William F. Maton Sotomayor
WGLC ends 2007-08-22.
draft-ietf-dnsop-as112-ops-00
Editors: Joe Abley, William F. Maton Sotomayor
Some editorial suggestions and wording changes suggested. Some
comments about making examples more general rather than all UNIX
specific.
Joe reported that there has been some discussion about extending
AS112. It is unclear from Prague what do do about IPv6 transport
for current zones and new zones whose traffic might be sunk by
AS112 (e.g. in ip6.arpa.). General apathy, but no disagreement
thus far about taking these on. Do we need a document, IANA
prefix assignments for IPv6 capable name servers? Do we add
other zones such as those in draft-ietf-dnsop-default-local-zones?
AS112 are not well coordinated. Loosely coordinated through a
mailing list. Would all AS112 operators be able to add a full set
of zones to their servers? Looking for guidance.
Rob Austein suggested listing the possibility that new zones may
be neded in the future, but zones should not be added preemptively.
Wait til traffic becomes a problem, then add them.
Akira Kato felt the term "IPv6 transport" in the draft is not clear.
Rob Austein suggests "carriage of DNS over IPv6".
Dave Hankins, delegate new zones to to an IPv6 addresses so that
new service would only appear to servers bound to that address.
IPv4-only hosts would not be able to get this service however.
Joe, this is an answer for a subset of services, related to IPv6,
but not all the services in the default-local-zones draft.
Mark Andrews, hard part is adding new zones. IPv6 transport
is a non-issue. As long as you have one serviceable address
we'll be fine.
Stephane Bortzmeyer, do not delay the draft with new zones, just
document the current AS112 effort. Start new work item for
designing better AS112 services after this document is done.
Joe clarifies that he wasn't suggesting these new zones for
the current draft.
Lars Liman argues for preemptive handling of zones before they
become a problem.
Peter Koch, there was some discussion on this in Prague. Would
anyone object to move changes for IPv6 to a separate document?
No objections. Would this need review in another WG, GROW for
instance?
Joe, wouldn't hurt to ask, I'll get their opinion.
3.2) Reverse Mapping [ 09:24 {audio 0:32:31} ]
draft-ietf-dnsop-reverse-mapping-considerations-04
+ contributions from draft-anderson-reverse-dns-status-00
Editors: Daniel Senie, Andrew Sullivan
Major changes between -02 and -03, thanks to those that commented,
very helpful, lots cleaned up. Fixed NXDOMAIN to name error and
eliminated terms like "useful". Added history section to address
problem of it not being clear why we are talking about reverse
mapping as a secuirty measure. Added general recommendations
section. Added section to talk about undue burden of net operators,
this is not intended to add undue burden to operators.
Peter Koch, make sure this is archived.
Andrew, yes it is in the minutes from last time.
Andrew, apologies. We missed someone's feedback in -03, became
issue 17 in the tracker, regardling the term "in use". Issued
-04 for this. RFC 1912 suggests all hosts should have a name,
because issue 18. Issue 19 confusing example, just removed it.
Still remaining controversies. This still imporses too great a
burden on operators. Question for WG. Does it? Suggestion
that there is an MTA "thing" that requires reverse mapping, but
couldn't locate it. Please tell me if you find it. BCP 30
suggests you can use forward/reverse mapping to reduce spam. Do
we need to refer to BCP 30? Contribution of reverse-dns-status.
RFC 1788, Experimental, suggests a different way of doing the
reverse mapping. Is this appropriate to incorporate? Section
3.6 reverse-dns-status, says delegate all addresses in the block
and do not assume Ethernet. We believe we say what amounts to
same thing, but please comment if you feel we should it include.
Appreciate comments, this has been a WG item for a long time.
Chairs cautiously optimistic most everything is addressed.
Matt Larson, no need to reference RFC 1778. Editors have been
very patient, accommodating for a particular invididual.
Rob Austein, Dean did ask the correct question, he submitted an
alternative properly. It is a fair question to ask, no matter
what people think, who has read the draft? 12-15 hands go up.
Of those who have read it, who thinks it should be adopted as a
alternative WG item? No hands. No one contests.
Stephane Bortzmeyer, RFC 2025 is now 8 years old and issues
have changed significantly since then. Do not give it too much
importance.
Andrew, if we add it, just a general remark that says RFC 2025
says do it this way.
Stephane, can refer to other groups such as ISP and RIR policies.
Andrew, can add a general remark that says ISPs may refuse service
without a mapping. Removed RIR references, because they change all
the time. Anti-spam policies change frequently, difficult to point
to them.
Peter Koch, anyone in favor of reference to RFC 2025? One hand.
Andrew will propose additional text for history section. Next
version (-05) should be published before Vancover and go for WGLC.
No one uncomfortable with that.
3.3) Referral Response Sizes [ 09:40 {audio 0:47:59} ]
< no slides >
draft-ietf-dnsop-respsize-07
Editors: Paul Vixie, Akira Kato
WGLC ends 2007-08-22. Akira thanks those who commented. This
document is about large resource records such as TXT or DNSSEC.
They are out of scope. This documents deals only with
authoritative servers, not stub resolvers or recursive servers.
If EDNS0 is available, this document does not add value, however
only a portion of the servers advertise EDNS0. Additionally,
some devices such as firewalls filter response sizes > 512 bytes.
May result in repeated queries to authoritative servers. We may
put some text into the document regarding this issue. Do people
support this?
Iljitsch van Beijnum, did you say you always see 1/3 of requests
with EDNS0 enabled?
Akira, yes in one trace, other statistics was slightly more than
1/2.
Iljitsch, I seem to recall seeing the statistic 80% elsewhere.
Very different figure. People shouldn't reject > 512 byte
messages when EDNS0 in use and we shouldn't give them a work
around. Either don't do EDNS0 or do not reject.
Akira, EDNS0 usage varies a lot by network/region. Just want
to make sure it's not 100%. If near 100% then we wouldn't have
to work on this draft.
Jim Reid, we have a draft in ENUM WG
related to EDNS0 and this issue. It's been suggested that we
split that draft in two. Perhaps we could roll part of our
draft into Akira's draft.
Peter Koch, there is something coming to us from ENUM?
Jim, not ENUM, suggestion came from area director. Jon Peterson
thinks our draft should be split in two and one part should come
from somewhere other than ENUM.
Rob Austein, comments I've heard about this draft (respsize),
it is an old draft and can we finish it already. Should we
defer anything else to another doc and just get this out? In
favor of getting finishing this as quickly as possible, hum.
Fair amount of hums. Hum to further explore new issuess. Not
much hums. Seems like people want to get it out there, but not
entirely clear.
Peter Koch, we have issue of EDNS0 deployment and ENUM WG needs
EDNS0 in service and in middle boxes. IETF is bad at saying thou
shalt support this everywhere. What are the appropriate protocol
elements to support today? Personal view seeing non-EDNS0 queries
in the wild, there is a need for this document.
Olafur Gudmundsson, EDNS0 should not be added to this doc. Draft
is basically done. If we want to create a "DNS profile" for what
implementations should do, that is another doc, a major undertaking.
Jim Reid, agrees with Olafur, we can go back and revisit EDNS0 in
another draft.
Peter Koch, two ways to go. Add a reference to EDNS0, that this
doc might become obsolete when EDNS0 is universally supported, but
get the draft out the door. Other option to discuss EDNS) and
middle boxes, dive in.
Jim, do not do all that work with this draft.
Peter, hum if you think we should just reference EDNS0. Fair
amount of humbs. Hum if you think we should do EDNS0, nearly
quiet. Hum in favor of getting this out the door.
Olafur, are you going to repeat this question on the mailing list?
Chair said of course.
3.4) DNS Resolver Priming [ 09:53 {audio 1:01:40} ]
draft-ietf-dnsop-resolver-priming-00
Editors: Peter Koch, Matt Larson
Peter Koch, this document was accepted by this WG after Prague.
This is more or a less a copy of the original individual submission,
with additional consideration for TTLs. There is a desire to add
AAAA records into the root-servers.net zone as well as glue in
the root for IPv6-only resolvers. The priming process is not
formally specified (no BCP). Do we want DNSSEC validation of the
root servers' addresses in the priming response? Attacker could
spoof root server addresses during priming. With DNSSEC this
could be detected, but some say this is expensive error detection.
Could protect crucial part of the whole resolution process. Con
is that we've never done that. Referral (glue) isn't signed.
Editors thought this might be worth treating as a special case
to make sure process isn't interfered with at the top.
Rob Austein, why is this a special case? It is just resolution.
Peter, it starts at the top, you could trick resolver at start up.
Rob, I don't understand the distinction.
Mark Andrews, problem is .net for root-servers.net isn't signed.
Even if you did sign root-servers.net, you'd need the trust chain
or you need two sets of trust anchors.
Peter, I'm not at that issue yet.
Mark, the addresses in the additional section for root will have
sigs if root-servers.net is signed. Assumption about glue not
having sigs, but root additional is not glue. This is not a
referral response.
Peter, do we expect the whole trust chain to be available,
what is the easiest way to get there?
Rob, thought experiment, if all root stuff is in root zone,
what is magic about the process of resolution. Peter is looking
nervous, what is the issue? There is an operational problem
that you have to jump through the .net zone. But no magic.
Mark, there is no magic here.
Peter, question of .net trust chain is a different issue and we
are coming to that. Given priming, do we expect the resolver to
set OK bit on priming query and validate the response. Priming
queries are predictable and an attractive target to attack. If
there is no trust anchor, this doesn't work, only helps DoS
attacks.
Rob, what happens to a non-DNSSEC priming query?
Peter, I give you a malicious set, this change is not making
things worse.
Olaf Kolkman, if root name server hands me bad things, I have
DNSSEC to catch that. What you'd protect is non-DNSSEC signed
data. There is a circular dependency here too, but not sure what,
don't think priming or root should be special. What is special
about the root zone from the perspective of the protocol?
Peter, no delegation. It comes out of the hints from the priming
query.
Olafur, yes and no. Does it does it make a difference if it is
sent? Ask the question again, resolver should not rely on this.
It might not fit into packet. Not a special case.
Peter, that is a different consideration again we come to on
later slides. Don't assume current setup.
Bruce Campbell, will this increase adoption of DNSSEC?
Rob, probably neutral, probably no difference, but depends on
resolver. Thought I was hearing people agree there is no magic.
Hum if you think there is no magic (signficant hum). Hum if
there is magic (no hums).
Peter, what do you mean by magic? It doesn't cause harm to
validate addresses?
Rob, it doesn't cause harm, but to do DNSSEC validation here is
no different than anywhere else. It is just a query, that is
what I meant by no magic.
Peter, what would this mean for selecting parameters for the
priming query? What should the recommendation to the resolver be?
Set the OK bit? If yes, what should the resolver do with the
response?
Rob, same as any other query. Set if you were going to, if you
going to validate, then do so.
Peter, if I need to validate, how do I follow it?
Rob, that's the unsigned glue problem, not the only place you have
to do this. Leap of faith to follow validation.
Peter, normal case we do not validate name server addresses, no
chain, just responses. If we've been tricked we can tag this as
an error. This would call for not validating the answers here
and if that's the sense of the room that's fine.
Rob, didn't follow, you do do the validations, but you have to refer
it.
Peter, no point in validating after referral, because you've used
it.
Rob, not true, you can tell you've been spoofed and remove cache
entry.
Peter, perhaps we should take this offline. Continuing...
Should priming response be self contained? Should all the
information (full trust chain) be in the priming response.
Mark Andrews, no. We do not need DSKEY records being primed.
Resolver will go get them itself.
Olaf, if you want to deal with trust relation between you and root
server name sets expliciting, you should probably configure those
keys as trust anchors. I feel we're heading the wrong way with
this.
Peter, skipping questions 3.1 and 3.2, don't make sense right now.
Drop DNSSEC stuff, might be OK and that's it.
Matt, to summarize priming, you get the info you need in one
query and one response. Would there be any way to prime and
keep that same attribute (one query, one response), if you
asked for that key would you get everything you need? Thought
it might be a clever optimization without doing any protocol
changes.
Mark Andrews, one query, one response is an accident of history,
resolver should be able to get ns rrset and ask for each of the
addresses. Bind 8 is broken, doesn't handle priming properly.
Not going to get fixed, should be able to get A RRs separately.
Rob, some ancient history, 1035, root wasn't magic, no priming
process documented, there was a safety belt set of addresses you
sent when you had no other idea what to do. Simplest place for
safety belt was the root. You usually just sent a "ok, where is
the root".
Olaf, priming process is a matter of careful implementation.
Implementation note may be beneficial. dnssec experiences draft
by Sam Weiler, maybe it could go in there?
Peter, challenging the adoption of this document, saying it is
useless?
Olaf, yes.
Matt, priming mechanism is useful and should be documented.
Olaf, if that is the case, then then I support clarifying what
is going on. Drop this document and clarify what happens now.
Rob, may not be in scope for this document, 1) existing practice,
how is this done. Not documented when I wrote code, critical to
get it right in implementation, worth documenting, 2) if we have
recommendations on how to do better that is fine, 3) Thomas Narten
reminded me that this conditional/leap-of-faith thing with glue
is not written down anywhere. Might be worth writing down how to
do the priming process, priming using DNSSEC would probably make
reference to that document.
Andrew Sullivan, Let's not focus on DNSSEC, just how we do
priming.
Matt, if we're going to do such a doc, we shouldn't rule out
optimizations.
[ note: Jabber down ]
Rob, option A, get it out as soon as possible, plain IPv4,
no DNSSEc, priming. Option B, A plus optimizations. Option C,
include DNSSEC. Little to no hum for Option A. Fair amount of
support for option B. Some support for C, but fewer if louder
than B. Room seems to favor leaving out DNSSEC. Anyone object
to follow-on work for DNSSEC?
Peter, will take remaining to list and re-focus.
4) WG Charter [ 10:30 {audio 1:38:39} ]
Peter, some milestones open and from last year. For the sake of
time let's move to section 5.
5) Other (non WG) Internet-Drafts [ 10:31 {audio 1:39:03} ]
5.1) draft-sato-dnsop-anycast-node-requirements
Editors: Shinta Sato, Takayasu Matsuura, Yashuhiro Orange Morishita
Shinta, requirements/suggestions for authoritative name server
operators who want to use anycast themselves. Mainly for ccTLD
operators, but not limited to them. Who is interested in this
draft? Roots, TLDs, RIRs, others? IETF dnsop may not be a good
place for this?
Peter Koch, how many have read draft? About 10 hands.
Joe Abley, there is overlap between RFC 4786. Other document
didn't have much DNS-specific text, what is missing from it?
Geoff Huston, seems contentious to mention anycast and DNS,
which the GROW document do. I think you should boldly go further
and say more about DNS on anycast.
Joe Abley, wasn't saying this document has no value, just that
it should focus on the DNS part and make use of references for
the more general text.
Peter Koch, chars will discuss with Shinta and focus. We won't
ask for adoption here. Will come up with a question/propsal for
the WG. We appreciate the hints towards certain appeals activities,
we will keep that in mind, but we are fans of the process. Cannot
make a decision right now, not enough people have read the draft.
Ed Lewis, being there are certain objections to DNS and anycast,
you'll find many people in this room have had success with DNS and
anycast. dnsop is a good place to get input and give to support
to going forward with this document on the basis of operational
experience with DNS anycast.
6) Current & New Topics [ 10:39 {audio 1:47:37} ]
6.1) DNS2DB & Data Gathering Protocol
Presented by: Niclas Rosell
Niclas presented a prototype tool first created in the summer of
2005 sponsored by .se. It collects statistics about DNS traffic
from servers and manages the data in a database. It uses a SQL
back-end. Code was recently migrated fro Perl to C. It reads
pcap files and stores summary data into the database. GUI
written in Adobe FLEX. Can import a 85 MB pcap file in about
45 seconds on an HP GL380G4. Runs on Linux/FreeBSD with an Apache
web server. uses PHP and pdo_sqlite. Flash required on the client.
.se outsources the operation of their TLD and would like to access
the data using a stanard XML API in the future. Web site for
software:
Standardization of API is an open question.
6.2) Name Server Control Protocol [ 10:52 {audio 2:00:55} ]
Presented by: John Dickinson
John presented the idea of developing a common control protocol
that can manage multiple different name server implementations
through a common interface. It should have access to all the
modern features without dictating which features an implementation
would support or what data can be returned by a name server. It
would be extensible to allow implementors to add new objects and
methods. Format of the data would preferably be XML and use
XMLRPC on top of TCP/SOAP. There should be a secure channel and
user authentication. It would be preferably implemented in the
name servers, but for now an agent on each server that is a
wrapper to local implementation that could emulate functions
and zone management. Currently writing the requirements, gaining
operational experience and building a wish list. Plan to have
a protocol draft ready for IETF 70.
Questions and comments deferred until next topic.
6.3) Name Server Management next steps [ 10:59 {audio 2:06:30} ]
Presented by: Working Group Chairs, Stephane Bortzmeyer
Peter Koch, last time we asked for volunteers for a design team.
We have opportunity of having all the know-how, but not the
right place to re-design underlying network management protocols.
We need to phrase what the operational requirements of these
protocols are for, but do not preclude individuals from submitting
their own drafts. Identify someone who can oversee the team and
is not directly involved, come up with something in the next 8-10
weeks by Vancover. Volunteers are in minutes from last IETF.
Stephane Bortzmeyer, agrees with plan and volunters to work in team.
Too early for deciding on NETCONF or XML. Only at discussion
stage.
Nominet (Roy Arends) and Sparta (Russ Mundy) would like to work
with the design team.
Rob Austein, ISC has been thinking about this space so I recuse
myself.
7) I/O with other WGs [ 11:09 {audio 2:18:19} ]
7.1) DNSEXT leftovers
Olafur Gudmundsson reports that meetings for this WG are suspended.
Rechartering, no new items except for updates to old documents.
Please send comments for dnsext-forgery-resilience-00, will go last
call soon. Cleaning up DNAME operational aspects. Will have a new
way to suppress the CNAME synthesis if the resolver says it knows
about DNAME.
7.2) HTTP & cookie validity [ 11:12 {audio 2:21:12} ]
Peter Koch, this effort has now been submitted to the HTTPbis BoF
and this WG should hav a close look on this work, because it
discusses DNS and makes some assumptions. Also keep an eye on DKIM,
which also makes some assumptions regarding DNS.
8) A.O.B. [ 11:15 {audio 2:23:00} ]
Ed Lewis, two things. Last couple of items outside of the IETF about
dns operations to be aware of. RIPE operational group issued statement
wanting the root signed. Have we (IETF) made it clear enough that this
is a good idea to do? Two, putting AAAA RRs in TLDs. NANOG asked
about getting AAAA glue in a TLD. Why haven't people been able to pick
up IETF technologies and do them? Let's make sure we've done our work
for the community.
Peter Koch, should we do outreach?
Ed, I have been seeing operational criticisms about the way DNS is,
are we sure we're covering all the operational angels? If it's outreach,
maybe we do that. All the good work we've done is not being used in
practice. Something is missing.
Mark Andrews, not aware of any edits outstanding for my draft.
Will talk about it later with chairs.
Meeting close at [ 11:18 {audio 2:27:43} ]
-----------------------------------------------------------------------------