Domain Name System Operations (dnsop)
WEDNESDAY, August 4, 2004 (1300-1500)
=====================================
CHAIR(s): David Meyer <[EMAIL PROTECTED]>
Rob Austein <[EMAIL PROTECTED]>
MINUTES: Ted Lemon <[EMAIL PROTECTED]>
==========================================
David Meyer: Suggests authors look at xml2rfc.
Agenda bashing.
Olaf Kolkman: dnssec-operational-practices
Very few differences between the initial submissions,
except we did a major language (style, spelling)
review. Content-wise very little changed. A few recs
from this group such as turning the recs we made
more into tradeoffs.
Since there is code around, we would appreciate it if
people could test what we've described as operational
practices and see if what we've said makes sense. We'd
really like feedback. Now there is code and a stable
spec so people can really give us feedback.
David Meyer: One other thing I'd like to ask authors, let us know
what they would like WG to do with their document.
Ready for WGLC or still outstanding issues.
Rob Austein: Right, and in this case we need more readers before we
proceed.
David Meyer: inaddr-required draft, very little activity.
Rob Austein: This one's come up before. One issue is that some
people never get past draft filename. If you look at
the title it doesn't match that. We have one extremely
vocal opponent of this draft who tries very hard to
trash the discussion of it - if he does that again we
will kick him off the list.
David Meyer: (consensus call)
Rob Austein: Looks like people want to go forward with this.
AD (Kessens): Do you have a plan to make progress with it?
Rob Austein: We're ready for WGLC unless someone has some other
issue.
David Meyer: With the exception of the individual who's been
resisting it, there has been no discussion.
Someone(??): Take out the normative language.
Suzanne Woolf: draft-ietf-dnsop-serverid-02.txt
This draft was allowed to expire after going through
most of the process, dunno if it went to IESG, but
history is that this document is mechanism for finding
out which server you're talking to, perhaps in a
load-balancing or anycast cluster.
Hostname.bind appeared specifically to support
anycast. The draft was to document the existing
practice and suggest a different name. Specific
mechanism was send query QTYPE CHAOS hostname.bind TXT
and get server name. Proposal was to change bind to
server. When documenting, people noticed problems.
Some concern about namespace abuse as it's an entire
TLD in class not used for a whole lot. Also
implementation specific. Most serious drawback
operationally, requires a separate query because it's
not in-band with query that's being answered. Some
consideration of DNSOP coming up with requirements so
DNSEXT can go do something. Obvious requirement -
needs to be in-band. Easy to configure, for dumb
administrators. Interoperable. Not
implementation-specific. Preferred if it doesn't
commit namespace abuse. 02 submitted last week,
documents this initial set of requirements. People
have suggested, up to WG to decide, needs to be easily
extensible. Able to support clients that might want
to offer information. Should be difficult to disable,
in interests of encouraging people to share info about
their servers. Initial attempt at solution submitted
as individual draft to dnsext, uses EDNS0/OPT
pseudo-RR. There are some gaps, need to think about
what we want to put in that field. Comments for this
document, discuss here. Solution to be discussed in
DNSEX. tomorrow. Anything on current requirements?
If you have opinions, send them in.
Matt Larson: draft-ietf-dnsop-bad-dns-res-02.txt
Let me say there's a problem with versioning.
Submitted -03, came out as -02. No idea
why. Submitting new version to address what comes out
of this and subsequent ML discussion, so hopefully
academic.
Can I ask who's read the draft. It's been out a
couple of years.
Upshot: draft discusses 11 specific issues that cause
varying amounts of problems with .com and .net. Not
worth going over this in detail, but it all adds up to
some number of extra useless queries that we see.
What do we do next?
Should we modify protocol. A bunch of these have been
fixed. There are some other things up here that I
think are worth having. Some are crossing line from
ops recommendation to something that should be
codified in protocol. On authns side, if you leave
off trailing '.' on NS record, authns server can
figure it out, emit a warning. 0 TTL on NS records can
have detrimental effect on your parent, so becomes
philosophical question what an implementation should
do. Anybody who operates name servers high up can
feel pain of aggressive dynamic update clients. Ought
to be two-step process, probe with NS-aware query and
only then send update. One thing we see a lot of is
queries for domain names that look a lot like IP
addresses. 1.2.3.4 rather than ptr query. What do
you do about that to remove that noise. One
possibility: delegate all numeric TLDs to separate set
of servers. That in a nutshell is the draft and its
recommendations. Encourage folks to read it. Ask
co-chairs for next steps.
Rob Austein: Topical document, looking for WGLC soon. Suspect that
the way to handle protocol changes are to write it as
here are the operational problems we've seen, we think
appropriate fix is this, but don't actually specify
changes. We don't do that.
Pekka Savola: In a related similar subject when we forwarded
something like this to IESG got feedback back that
proposed fix, even though good idea, if it hadn't been
taken up in protocol working group, there might be
some pushback.
Rob Austein: We want to document the requirements. Don't care
which working group. Ask the AD.
Matt Larson: So take out recommendations?
Rob Austein: Lots aren't protocol changes. Maybe one or two are.
Olaf Kolkman: If you have protocol recommendations put them in
another I-D, submit to dnsext.
Matt Larson: Appreciate comments from WG on things in the draft
that rise to level of protocol changes.
Olaf Kolkman: I don't see anything in there that goes beyond
implementation guideline except for creation of new
TLDs which is ICANN problem. So I don't think we are
going to be upset if this goes forward.
Rob Austein: Path forward: a couple of people, I'll be one, should
go through this, if we find stuff that's crossing
line, discuss with chairs and AD. Don't want to lose
any of these suggestions.
Rob Austein: Ready for WGLC. (lots of hands.)
Rob Austein: Readers who think not ready for WGLC:
Jinmei Tatuya: I basically have no objection to having WGLC, but want
to make one comment, previously I made comment on the
issuing of queries to name servers, got response from
???, have not responded to comment, (joseph?), because
have not found enough time, but am willing to make
response. Probably can just do that during WGLC.
Rob Austein: Yes, sounds fine.
Matt Larson: Would like to push out quick revision, is that good?
Rob Austein: Doesn't matter if it's before or after WGLC.
David Meyer: On to key roll-over requirements.
Francis Dupont: Please read -00 draft, we will be doing 01 soon.
There is still something unclear needed about
emergency rollover. In case key known by too many
persons. Section about it, perhaps you can review it,
don't know exactly what to do. We know we need to do
something fast to keep the chain of keys. We received
no comment. As soon as there is no more issues or
details to explain, etc, perhaps we can do a WGLC.
Please help with MIP6 WG, trying to explain what
DNSSEC is doing, asks for help to rewrite the DNSSEC
subsection which I called . piece of DNSSEC bashing.
Route Optimization Security Design Background
document. Contact me or Gabriel Montenegro.
Olaf Kolkman: Haven't read in very long time, most people who were
involved with DNSSEC have not done so. This very
topic has been getting a lot of attention recently.
We have had a few discussions on automatic key
rollovers recently in DNSEXT. I will do it soon, ask
others to do it as well.
G. Montenegro: We have this document, it's a back grounder for MIPv6,
we have a section on DNSSEC, really need some help
from this WG. Either email me or Francis.
Johan Ihrens: Once upon a time I thought that rollover stuff will
certainly not require protocol changes and therefore
DNSOPS would be place for discussions. However, it
may well be that we end up with protocol changes which
is why those other drafts on rollover are being bashed
out in DNSEXT. My brain isn't large enough to cover
this topic in two different WGs. Keep it all here or
push it all into DNSEXT. Can't have requirements doc
in one group and proposed in another.
Rob Austein: We usually do.
Francis Dupont: For solutions, perhaps these are some already in
DNSSEC.
David Meyer: So how many people have read this?
Rob Austein: Not much of a showing. Of those who read it, how many
thing we need to work on this. Is this something WG
don't want to work on, or something WG does want to
work on?
Russ Mundy: Think that that's true. We need to read it, need to
attack the operational requirements. Don't remember
content anymore.
Rob Austein: We need to work on key rollover requirements. We
don't know this is the right doc. First step is to
read it.
David Meyer: Moving right along, increasing dns server.
Rob Austein: Olaf just reminded me that we have another WG that
could use some help. MARID. They're talking about
using DNS to hold stuff dealing with whether or not to
accept mail from SMTP senders. Very interesting and
somewhat loud topic. Some have interesting ideas about
DNS. They have another meeting.
Schnitz: In DNSOP, years ago, producing informational RFC
addressing what the rest of IETF needs to know about
the DNS. Abby offered copyright protection for using
parts of her book. Did anything come of that?
Olaf Kolkman: Interesting. One issue I want you to address in
testing - if there is any preference for any of the
servers in the query pattern. Like, first one gets
most. Biggest reason for deploying this not mentioned
in draft. Glue for net zone requires thirteen
signatures. We could shrink to five. Signatures are
big. NS and A records are small.
Yasuhiro Morishita: Is this a DNSSEC issue. I think that we need to
testing in DNSSEC environment.
Rob Austein: Particular issue for signatures is whether this is a
good idea or not. Number of RRsets matters.
Paul Vixie: When we looked into doing this at the time that Bill
Manning first proposed that we switch to
root-servers.net, reason we did not go with smaller
numbers of names has to do with the way the recursive
and stub clients handle SRVFAIL. In event of SRVFAIL,
no other address for that name server will be tried.
Timeout will stimulate retry. We thought that it
would be bad if there was no fallback in event that
single server did not have zone loaded. So the two
suggestions I have are first that some minimum number,
like two or three names, be used, each with small
number of records, and second that this be considered
for TLDs but not roots at this time.
Yasuhiro Morishita: Root and TLDs not be amended be applied.
Rob Austein: Not done yet, right?
Yasuhiro Morishita: Right.
Rob Austein: I assume folks think this is useful work, I certainly
think so. Anyone else. That looks like good support.
David Meyer: I looked at id-trackers, generated list of other
drafts, this stuff is already at IESG. misbehavior
and ipv6-dns-issues are at IESG but in ad followup.
Pekka Savola: Been revised a couple of times since it went through
IESG, some comments from Thomas Narten, would like to
get feedback. Least important one is whether you
believe there are some documents that should be
normative references but are not. Second is whether
we need to do extra. (loud feedback. So feedback
would be appreciated. It has some connection to
protocol work, so feedback. from there would be
welcome. Last issue - split off some parts of
document into separate documents. E.g. forward and
reverse DNS updates.
Rob Austein: Have you sent list of questions. Might want to resend.
Jinmei Tatuya: In my understanding authors can just wait for feedback
from IESG. I would like to make sure that the authors
there is nothing for them to do in ad-for-ops status.
David Meyer: We have to look at if there are discuss comments
against it, or you can look. We can show you how.
David Meyer: ad-is-watching - second draft is expired. this is
local-zones. So I'll talk to AD to see what gives.
Rob Austein: Paul, want to say anything about respsize doc?
Paul Vixie: I know that one person actually read this and found
clownish commentary I put in draft. Nobody flamed me.
There is a very controversial comment in this draft.
Peter Koch: Have one question or remark. We had funny discussion
about what is allowed length for domain name. 255,
256, 253. It'. a bit late now to discuss this
because this is very basic DNS stuff. Nothing to do
with your draft, but obviously some basic questions
yet unresolved. Anything we can do in this or another
WG to resolve this?
Paul Vixie: It is certainly the case that in respsize draft I
should not have mentioned any numbers because it's
easy to look in other specs. Should just refer to
standards. That's how I plan to fix the problem in mu
small corner of ocean. In larger context, it would be
interesting to see results of survey of what people
think is max length of domain name on wire. but for
myself would be more interested in seeing results than
doing survey.
Peter Koch: So by deferring this somewhere else, I beg to differ
you, you ignored the problem. So what can we do about
that? Obviously there is one.
Paul Vixie: I don't know that there really is one. May be sleeping
dog. People don't design their businesses/projects
around ability to use names > 250 chars. If you are
interested in subject, you are speaking words that
normally precede the statement "I volunteer."
Peter Koch: To volunteer is a transitive word in IETF. You are
probably right, so may or may not be academic
problem. In your draft, and in other docs, there are
consequences out of max length. If there is corner
case, the one single octet that is missing or not, I
would like to have the discussion before hand, so we
don't wind up where Mary did solving basic DNS
problems in midst of IETF meeting.
Paul Vixie: Wasn't at Mary because of lack of strong wind. If
someone is using query name that is really that long,
difference will be there will be very few glue records
in the delegation area. Seems unlikely that difference
of opinion of one octet is going to change planning
very much. The fact that someone can concoct an
experiment where really long name breaks model,
doesn't matter. When people are asking for names that
really do exist, you care if they got enough glue. So
for my part only thing that matters is that I take out
the number and reference 1035. Until someone writes
critique of 1035, that's good enough for me.
Olaf Kolkman: Second argument for all you ever wanted to know about
DNS but were afraid to ask, would be handy to have.
Paul Vixie: In terms of process, I do not think this draft is
ready to progress, because no-one complained. So until
I have some feeling that someone other than me has
seen this text, I will say it's not ready to go
forward.
Rob Austein: So given that we had a number of people claiming this
was important work, suggests that there is some work
to be done in terms of reading doc that hasn't
happened yet. You're all slackers. Go read the document!
David Meyer: On to the Non-WG documents...
Pekka Savola: There was one WG doc that has expired a long time ago
which hasn't been discussed - don't publish
unreachable draft. Should work on it or not?
Rob Austein: The author has in fact said he has no time to work on
it anymore. thought we had a volunteer, have to check
notes, have not made obvious progress on it. Do
people still feel it's useful? Itojun wanted it. I
dropped ball on this one, will consult notes.
David Meyer: So these were the other drafts that had expired. A
couple of them have been updated since I made these
slides. Not sure there's anything to say about them
other than that they're expired, we've been through
these a couple of times, wanted to know if anybody
thought this was work that needs to be brought back or
let it die (dynreverse, interim-signed)
Tim Chown: I think dynreverse is important.
Alain Durand: Thank you for volunteering to work on it with me.
Rob Austein: Protocol change?
Alain Durand: Depends on what you call protocol.
Rob Austein: Change to whole bunch of deployed code. Dubious about
this one fitting here.
Alain Durand: I don't care about this particular draft, way of
solving problem, but do care to have one solution for
what to do with reverse DNS. In v4 ISP used to do
prepopulation, would like to see solution. Don't care
what it is.
Tim Chown: I'm not saying this document is the perfect way, but this
is important topic.
Rob Austein: You're volunteering.
David Meyer: What I had on agenda next was IPv6 config opts. Would
like to leave for last. Let's go on to Peter.
Peter Koch: Would like to ask WG question regarding an idea. Using
SRV records in DNS to do something that has nothing to
do with DNS. At the moment we have four regional
internet registries, you ask for IP addresses, receive
some information, who to contact for that
address. Which whois server do I query. Would like
client to figure it out.
Suggestion on table - draft-sanz-whois-srv-01.txt.
Pekka Savola: Can we assume that hte division between different
registries will be forever on first byte boundary?
Audience: no.
Pekka Savola: Does it work if we can't assume that?
Peter Koch: No we can't know forever, but where's the problem at
the moment. Currently the RIRs receive more than /8
worth of address space. If we have non-octet
boundaries, could take it down the path, distributing
it on the next level.
Paul Vixie: First, the SRV records in question would have to be at
apexes of delegated part of tree, not in in-addr zone,
because can't have anything at point above zone cut. A
query for these would be referred to authority zone
for these, which is actually a good thing. With regard
to CIDR allocations, ipv6 tree, we really need to be
looking at RFC 1101 as far as networking certainly the
bind resolver has been able to look up RFC 1101 info -
getnetbyaddr, this works even in case of RFC 2317 or
other CIDR delegations. Unfortunate that it requires
lookup of A record to find mask, but can be done. If
you were to cast this in terms of additional data to
go into RFC 1101 network naming schema, this would be a
wonderful thing.
Peter Koch: So you are saying that this is only useful in
conjunction with RFC 1101?
Paul Vixie: Yes. We have to be able to cover that whole area. This
is an odd form of label stripping. May be a particular
WHOIS server for 193.10. Start by looking at /32
level, don't have to check every bit. RFC 1101 gives way
to find netmask for closest enclosing network. This is
a good idea, excellent convention, I know that it
needs to be done in bottom up fashion rather than
top-down fashion. This is a better solution, but
requires RFC 1101.
Peter Koch: I again beg to differ. What I was afraid to suggest
was as you suggested, there may be a more specific
responsible whois server for /32. So sure you could do
that, but don't see where RFC 1101 comes into the
thing there.
Paul Vixie: RFC 1101 gives you way to discover that there is a /15
or a /27 or something.
Peter: You still have the closest enclosing delegation on
octet boundary.
Paul Vixie: Most frequent use of this other than data mining and
spamming is complaining about them, need to go to
closest enclosing.
Russ Mundy: We're co-chairing a project that's been underway for
short length of time that focuses on getting DNSSEC
deployed. Trying to provide a structure/org that's a
program office for facilitating things that need to
happen for DNSSEC to get out there. Need to identify
what needs to happen. Trying to collect peoples' views
on what needs to happen. Steve has web site,
dnssec-deployment.org. We look forward to having folks
join in, provide criticism and information, working
with everybody.
Steve Crocker: You covered it pretty well. I would emphasize is that
focus is on post-ietf process. What do you do after
specs are done. There's a host of little problems,
chicken-and-egg. Who holds the root key. What if you
ask for signed, get back unsigned. Verisign has
created its own DNSSEC consortium. I imagine there
will be other specialized groups that focus on stuff.
David Meyer: Pekka, come up please. We have three more agenda
items. RIPE survey, DNSSEC, EPP if Scott is
here. Brief review of DNS config options work.
Pekka Savola: David Malone asked me to present this. IPv6
lookups. This misbehavior towards certain kinds of
queries, esp. IPv6 lookups. Took quite a bit of logs
and found over 20k DNS servers, did a query looking up
how many had AAAA records or how many had problems
looking up them. Not sure if this shows, but the thing
was that 0% have AAA records, 80% have misbehavior.
So there's a big problem for IPv6 hosts. Something
needs to be done about it. What to do is good
question. Should we set up hall of shame?
Scott Hollenbeck: Author of EPP. Work of provreg WG. This doc is
individual submission, tracking progress of EPP and
DNSSEC. (reads notes)
Rob Austein: The way Scott phrased it, I think interval is
recommendation.
Russ Mundy: I'm not sure if it's a work item for this WG because
it's part of a space that WG hasn't dealt with in the
past. I think it's very important work that needs to
be done whether part of this WG or not.
Rob Austein: I asked Scott to bring this here. This is not DNSEXT
work because it's not DNS protocol. Not really EPP
work. This is really about what does DNSSEC need. So
this seems like the right place to come to get
help. Don't care if WG adopts it.
Ed Lewis: Its a good thing to discuss here. One operator said
would like to see registries (?) in common. EPP is
primarily used in one set of registries, but not all
registries. Would be good forum for operators to say
how all registries should treat ???
Scott Hollenbeck: Quick note to ML. Will do.
David Meyer: DNS configuration options draft. Advisory doc to
IESG. Wanted to see fi there were solid objections to
what's in draft, if not, WGLC. Let me remind you of
the three things. If you've been asleep for last
couple of years, these are the three options. RA,
DHCP, WKA. What we want is to move this doc through
WGLC, get it to informational, if you have any
objections, sense that some issue that you have isn't
covered, please speak up.
Rob Austein: Documenting state of inconclusive discussion we've had
over and over again. If it covers all issues
adequately, we are done. If there is something
missing, tell us now.
David Meyer: Should really get it to informational (after all, this
is the third time draft has been written).
David Kessens: Major issues only. No nit-picking please.
David Meyer: Reminder: this is not a proposal - just documenting
what has been proposed.
Erik Nordmark: Seems to make some performance claims based on
unstated assumptions. E.g. claims that RAs are
better. Sending this stuff many times a day in case it
changes. Seems like wasting bytes. Don't know what to
do about performance claims. Seems to need a bit more
rigor.
Rob Austein: Needs more eyes on that part of text. It's just bytes
in a message that's going out anyway.
Erik Nordmark: May be a lot more bytes.
Rob Austein: Right, so we should back it up.
Jinmei Tatuya: Not making objection, but my understanding there are
several substantial comments on previous draft. There
are significant changes from previous version, should
issue last call again. Make solid consensus. Not
necessarily going to push this idea if you are
particularly in hurry.
Rob Austein: We're in a hurry because in order to get this done we
had a deadline. The AD can speak for self. AD will be
cool with taking more time for WGLC if we're making
serious progress by doing so. Don't want it to drag on
forever.
David Kessens: I can go for it.
-----
AGENDA
o Administriva 2 minutes
- Mailing list: [EMAIL PROTECTED]
subscribe dnsop
- Scribe?
- Blue Sheets
o Agenda Bashing 5 minutes
Meyer
o Review and status of work items 55 minutes
Active Drafts
-------------
draft-ietf-dnsop-dnssec-operational-practices-01.txt 5 minutes
Kolkman et al
draft-ietf-dnsop-inaddr-required-05.txt 5 minutes
Senie
draft-ietf-dnsop-ipv6-dns-issues-07.txt 2 minutes
Durand, et al
IESG Evaluation::Revised ID Needed (Informational)
draft-ietf-dnsop-ipv6-transport-guidelines-02.txt 2 minutes
Durand, et al
RFC Ed Queue (BCP)
draft-ietf-dnsop-key-rollover-requirements-00.txt 5 minutes
Guette, et al
draft-ietf-dnsop-misbehavior-against-aaaa-01.txt 2 minutes
Morishita, et al.
IESG Evaluation::AD Followup (Informational)
draft-ietf-dnsop-ohta-shared-root-server-03.txt 1 minute
Ohta
draft-ietf-dnsop-serverid-02.txt 2 minutes
Woolf
draft-ietf-dnsop-bad-dns-res-02.txt 15 minutes
Larson/Barber
Expired WG documents
---------------------
draft-ietf-dnsop-resolver-rollover-01.txt 2 minutes
expired (Kolkman)
AD is watching
---------------------
draft-ietf-dnsop-respsize-01.txt 5 minutes
expired (Vixie/Kato)
draft-kato-dnsop-local-zones-01.txt 5 minutes
expired/no WG document
Non-WG Documents
------------------------
draft-durand-dnsop-dynreverse-01.txt 2 minutes
expired
draft-ihren-dnsop-interim-signed-root-02.txt 2 minutes
expired
draft-yasuhiro-dnsop-increasing-dns-server-01.txt 5 minutes
expired
o DNSSEC Deployment Activity 5 minutes
Steve Crocker/Russ Mundy
o IPv6 DNS Configuration Options 15 minutes
draft-ietf-dnsop-ipv6-dns-configuration-01.txt
Jeong, et al
o RIPE survey 10 minutes
draft-ietf-dnsop-misbehavior-against-aaaa-01.txt
http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-malone.pdf
Savola, et al.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
