Last Modified: 2004-02-12
1. Define the processes by which Domain Name System (DNS) servers may be efficiently and correctly administered, configured, and operated on Internet networks. This will include root zone name servers, gTLD name servers, and the name servers of other DNS domains. As part of this effort, the group will produce documents explaining to the general Internet community what processes and mechanisms should be employed for the effective management and operation of DNS servers.
2. Publish (or assume sponsorship for) documents concerning DNSSEC procedures.
3. Publish (or assume sponsorship for) documents concerning the education of new/novice DNS "users" (FYI-RFCs).
4. Identify performance measurement tools and evaluate their effectiveness.
The group sees four main areas with related documents:
Root Name Server Operational Requirements draft-bush-dnsop-root-opreq-00.txt Editor: Randy Bush
Multiple servers sharing the same IP address
Editor: Masataka Ohta
Zone KEY RRSet Signing Procedure draft-ietf-dnssec-key-handling-00.txt Editor: Edward Lewis
Performance and measuring Editors: Randy Bush & Michael Patton
|Jun 99||Publish revised Root Server Requirements.|
|Jul 99||Publish revised version of Key Handling.|
|Jul 99||Publish first version of Servers Sharing IP#.|
|Sep 99||WG last call for Root Server Requirements.|
|Sep 99||Publish first version of Performance and Measuring.|
|Oct 99||Publish revised version of Key Handling.|
|Oct 99||Publish revised version of Servers Sharing IP#.|
|Nov 99||Submit Root Server Requirements to the IESG for consideration as Informational (BCP?).|
|Dec 99||Publish 2nd revised version of Servers Sharing IP#.|
|Jan 00||Publish revised version of Key Handling.|
|Feb 00||Publish revised Performance and Measuring.|
|Mar 00||WG last call for Key Handling.|
|Mar 00||WG last call for Servers Sharing IP#.|
|May 00||Publish revised Performance and Measuring.|
|May 00||Submit Servers Sharing IP# to the IESG for consideration as Informational.|
|Jun 00||Submit Key Handling to the IESG for consideration as BCP.|
|Aug 00||WG last call for Performance and Measuring.|
|Oct 00||Submit Performance and Measuring to the IESG for consideration as Informational.|
|RFC2870||BCP||Root Name Server Operational Requirements|
|RFC3258||I||Distributing Authorittative Name Servers via Shared Unicast Addresses|
Domain Name System Operations (dnsop) Minutes -- IETF 59|
Monday 03.01.2004 (1300-1500)
CHAIRS: David Meyer
Minutes recorded by Ted Lemon
o Administriva 5 minutes - Mailing list: email@example.com subscribe dnsop - Scribe? - Blue Sheets o Agenda Bashing 5 minutes o Status of WG Active Drafts 30 minutes - draft-ietf-dnsop-dnssec-operational-practices-00.txt Kolkman/Gieben 10 minutes - draft-ietf-dnsop-ipv6-dns-issues-04.txt Durand/Ihren/Savola 10 minutes - draft-ietf-dnsop-misbehavior-against-aaaa-00.txt Morishita/Jinmei 10 minutes o Expired WG Drafts 10 minutes - draft-ietf-dnsop-respsize 2 minutes - draft-ietf-dnsop-bad-dns-res-01 2 minutes - draft-ietf-dnsop-interim-signed-root 1 minutes - draft-ietf-dnsop-inaddr-required 2 minutes - draft-ietf-dnsop-serverid 1 minute - draft-ietf-dnsop-ohta-shared-root-server 2 minutes o Other Active Drafts 25 minutes - draft-guette-dnsop-key-rollover-requirements-00.txt Guette/Courtay 5 minutes - draft-kato-dnsop-local-zones-00.txt Kato/Vixie 15 minutes - draft-yasuhiro-dnsop-increasing-dns-server-00.txt Morishita 5 minutes o Object Now or Never Drafts 5 minutes - draft-warnicke-network-dns-resolution-02.txt 5 minutes o Milestone Update 30 minutes Austein/Meyer/All Categories: - IPv6 DNS Ops - DNSSEC Ops - ROOT/TLD/Other Systemic DNS opsMinutes
We decided we don't really need the Tuesday session. So there will be no Tuesday session.
Authors for some of the drafts aren't here.
Brief announcement (on behalf of Daniel Karrenberg, who was not present):
There's a study in progress trying to measure what fraction of DNS queries indicate support for EDNS0. This is a work in progress, nothing final yet, but those who are intereted might want to see
Rob Austein: This is the operational practices draft. Lots of good response initially, nothing recently. We need to keep pushing on this.
Pekka Savola: I stepped over this one because I received some encouragement from that I should send some text so I revised it twice. Since last revision no comments. From my perspective I would like last call pretty soon; otherwise waiting for nothing.
Rob Austein: anybody think it's not ready for WGLC? Object now if we shouldn't go to WGLC. [silence] Ok, will last call on the list.
Jinmei Tatuya: significant change on this revision submitted individual draft last June, based on comments we've revised this draft as a wg document. Most of the changes are historical. My understanding we are the core of this document is to publish as info rfc. In that sense I believe ready for WGLC. Will need to remove appendix talking about conflict examples (incomplete?).
Rob Austein: There is overlap between this and ipv6-dns-issues. Make sense to keep them separate or to merge them?
Jinmei Tatuya: No particular opinion. In general it would be better to merge two documents to single one. The less number of documents is usually better. Would like to merge in that sense, but don't mind either way.
Pekka Savola: ask at WGLC.
Itojun Hagino: I guess I like to see them produced as separate documents because latter one talks mostly about existing ipv4 misbehavior over existing ipv4 dns servers while former talks about slightly different issues.
Piet Barber: recently put in dnsop-bad-res draft just before deadline. I ask for any comments people have - it hasn't been brought up on the list. No comments other than from Rob Austein, eagerly awaiting more.
Rob Austein: how many have read? ... Not enough. This was a pretty good document a year or two ago, got kind of stale, would like to get it out while it's still fresh this time.
Piet Barber: I've added several more annoying things we've seen on root server. Lot more opportunity for misconfiguration which we see a lot more in com (common?) net. If you have operational experience with DNS, please get back to us.
Rob Austein: My preference would be to give people time to read this, but try to do WGLC before San Diego. Anybody think that's nuts? [no audible response]
[Pseudo-draft on resolver API, URL posted to namedroppers]
David Meyer: dnsop-resolver-app-interface - not actually an internet draft, just posted on a web site. Topic they're trying to bring up is one we ought to be discussing. Document is not anywhere near ready - straw proposal. Not sure it's the right way. We do need to think about semantics of interesting error cases we have, can't just use SRVFAIL and weird bits to indicate errors.
Sam Weiler: Don't bother reading it - just write something else.
Ohta-san: update is on the mobile [???] or section about experiment. Just an update this addition to clarify how redundancy can be achieved with anycast/multicast. There is some modification, want discussion here or on mailing list about this.
David Meyer: Anybody have comments on warnicke-network-dns-resolution? How many have read it? You have to read it to comment.
Rob Austein: If there is something really seriously wrong with this, we need to tell the IESG to tell RFC editor that it should not be published; otherwise we should leave it alone.
Pekka Savola: I have objections, but based on that classification it's probably not that serious.
Rob Austein: draft has been in front of wg before, declined to touch it, went individual path, we're being asked again.
Rob Austein: Plan was to have new version. Dog ate homework. Authors promised version in time for San Diego after dog incident.
Has this draft been overtaken by events? [silence]
Any comments? Do we want to bring this back?
Itojun Hagino - I think I have seen more operational troubles with ipv6 case reverse lookup case. Lack of IPv6 reverse lookup causes connection delays on stuff so I'd really like to see this published.
Rob Austein: remember, this is the one where the title is misleading - this is just considerations for whether to populate reverse tree, etc. Last time it came up wg insisted it was important, but didn't get traction on doing it.
Will somebody write text? Author has been pelted with rotten tomatoes so many times doesn't want to do it anymore. [This turned out to be incorrect, author is still willing, see discussion on mailing list.]
Itojun Hagino: I'll do it!
David Meyer: Suzanne Woolf has graciously...
Rob Austein: The ISC dog ate this homework too. If the update of this had come out, it would have backed down on proposal for new conventions that aren't in shipping software and mostly just documented existing hacks in existing software. The hack we have now is that some name server implementations have a magic query you can send that identifies the server. It's a kludge, the only advantage is that it's in the field. It's not really right for debugging things like anycast, because if anycast is flapping, there's no guarantee that the query goes the right place. Only way to solve that for real is a protocol extension that gives a mechanism for saying "server, please identify yourself" in the original query.
I have put together a straw proposal for how to do this as an individual draft which probably goes to DNSEXT. Motivation is still waiting for Suzanne's revision of draft-ietf-dnsop-serverid.
draft-guette-dnsop-key-rollover-requirements-00 has turned into draft-ietf-dnsop-key-rollover-requirements-00
Masen Tuci from apnic - dnsop key rollover requirement?
David Meyer: this isn't a wg draft.
Rob Austein: changed names.
Masen Tuci: accepted last IETF meeting, adopted by WG, authors submitted new version, asked for comments, didn't have any.
Rob Austein: is new version identical to previous?
Masen Tuci: I guess there were some clarifications and minor modifications.
David Meyer: has anybody read that one?
Masen Tuci: may I relay author's comment? Please read it and send comments!
Kato-san: sorry , have no time to update, objective trying to write something new by next Sunday meeting.
David Meyer: has anybody read this?
Yoshiro Yoneya: On behalf of Morishta: he is trying to update draft, has had no time, will do before San Diego.
David Meyer: When we are notified of that...?
Chairs: Ok, that was our list of drafts, what have we missed?
Pekka Savola: don't recall seeing v6 transport guidelines. [draft-ietf-dnsop-ipv6-transport-guidelines-01]
Rob Austein: Oops. That one already passed WGLC, it's waiting for some stupid thing. Thanks for reminder.
Pekka Savola: I think it's high-priority work.
Rob Austein: Should have been out a year ago, we (the working group chairs) blew it.
David Meyer: We're in the process of updating our charter. That process is going fairly smoothly. I wanted to let folks know where we're at. As you know, charter on website was outdated. We have a few issues that are critical to new charter.
1. DNS Discovery.
2. IPv6 DNSOPS
3. DNSSEC Ops
4. ROOT?TLD/Other Systemic DNS ops.
The issue here was we've gone around this issue more or less endlessly. In discussing it with our area directors, they asked us to write an issues document that describes what the issues are with the three approaches. Have that ready. Goal is to have it ready to submit to IESG as informational document by the San Diego IETF. So we're on a short leash. We've been informed that if we don't complete this work by that time, the DNS Discovery milestone will be removed from our charter.
Rob Austein: Point is we've been having this circular discussion, apparently we can't get consensus. So the idea is to write down the arguments in coherent form so that people can read them. I'm not sure we can settle it, but at least get them written down so people who have not been involved can form their own conclusions.
David Meyer: So to that end we really need to solicit folks who want to work on this, to be authors and/or editors. Unless we hit the ground running, it's going to be challenging to have doc ready for IESG by next IETF. I know that Jaehoon Paul Jeong has a five minute presentation on this, we can do that now if we like.
Rob Austein: Before we get to that, any other discussion on any other drafts? [silence] Ok, we're done with everything but DNS Discovery.
David Meyer: This is an issue we really need to solve, let's get five minutes from Paul.
Jaehoon Paul Jeong: hello everyone. I will talk about DNS Discovery issues. DNSOP decided to produce a document outlining the attributes of the three DNS discovery approaches. Document of DNS discovery will describe the problems and issues with DNS discovery. etc.
First alternative is RA option. This draft has been burst by four authors. First solution is RA DNS server option. Second is DHCP option. Stateless or stateful.
Last approach - well known anycase address. Can be pre-configured in IPv6 host.
Ordering between RA and DHCP option - M & O messages can be used to take order between two options. However, in this point, I don't know how to fly anycast with other solutions. Three options - WKA as last resort, when IPv6 host cannot get DNS server info through RA and DHCP.
Second option - IPv6 host can configure WKA as the most preferable in its conf file.
Last, can get explicit fact that WKA for DNS can be used in the site through RA Hint Option. Hint says WKA can be used. Can be implemented by RA DNS Server Option with knew flag.
I think we should resolve this in this meeting, we have a short time to do this document. Need input and comments.
Ohta-san: I think your understanding about mobile scenario has some misunderstanding. There is no requirement that all the mobile operators must provide DNS servers, which means if you don't have DNS servers at home, then if you sometimes lose access to DNS servers because no local available, that's not a very good environment. So with mobile environ ent one should have his own DNS server at home. Because mobile host needs some configuration about home such as home network address, it is not unreasonable requirement home dns server address should also be configuration. Mobile node must be somehow configured. So mobile environment should be dropped.
Jaehoon Paul Jeong: when we use mobile server, time can be optimized.
Ralph Droms: THe description you gave here brings up a thought about document Rob Austein talking about. Before authors dive in, ought to frame amount of discussion that goes into it. Every time we bring up here, has gone on to absorb all available space. So as a bit of advice, perhaps somehow this has to be limited in frame.
Rob Austein: I'm not sure either. One bit of advice I got from old IETF person is that, even if we are not going to get to the point where everybody agrees, we might get to the point where document describes issues enough that everybody can say "yes, that represents my position fairly, I think I understand the other positions also, even though I don't agree." Having watched Paul's (Jaehoon Paul Jeong) presentation, my initial reaction to it is it's a very good way of looking at it if we were trying to do all these things at once. Unfortunately, the WG has no consensus on that. Not going to be able to settle this in the document - just write it down fairly.
Ralph Droms: We hadn't talked about which comes first, which comes second. Do we want to try to frame it to tightly describing alternatives individually, or describe ways they could interact? It seems like a real rat hole.
David Meyer: My sense of what this document's supposed to do is solve the problem less than Paul's (Jaehoon Paul Jeong) presentation did. Describe technical attributes, etc. Describe disadvantages of not doing them. Qualitatively different than trying to solve the problem.
Rob Austein: We have our AD here. Is this what we're looking for?
David Kessens: It's correct and also the last part we'd like to know about possible interactions if there are multiple solutions. Document what the interactions would be. What would need to be coordinated.
Bob Hinden: Good proposal - one way to move ahead. Not sure what happens after neutral draft is done. Clearly proposal for RA option, have DHCP, what happens next?
David Kessens: We don't know yet. We will study the document, and look at it, and see what risks are of doing multiple solutions, make informed decision.
Bob Hinden: Written to advise IESG?
David (Kessens?): We hope to be able to get something out of this.
Rob Austein: This group was never going to do protocol work anyway - just try to figure out which way to go. It's possible that we won't be able to make a recommendation. This seems like the most profitable thing to do.
Ralph Droms: Can you give us a little more explanation of the WKA hints option? Why not just send WKA?
Jaehoon Paul Jeong: Indicates that WKA can be used. Without this option, we assume that address line have addresses of DNS server, however hint option we can explicitly indicate that WKA have been deployed. However, this is my suggestion, Ohta-san can suggest another way. This is my private opinion.
Ralph Droms: So independent of specific WKAs? What's different between sending WKA and WKA bit?
Jaehoon Paul Jeong: This option is just an indicator - RA option doesn't contain addresses.
Bob Hinden: One thought on how we might proceed. I won't say it if you don't want me to.
David Meyer: We're working on a charge from our ADs.
Bob Hinden: I'm trying to be polite and constructive. Making big fuss over a lot I don't understand. It seems like go ahead with DHCP-lite, RA looks straightforward. Didn't see any big technical issues. WKA clearly has issues but strikes me that it's really WKA not just for DNS but for a range of servers and as such needs to get discussed in WG with broader scope - discovery of services. Trying to be constructive, suggest we have DHCP, send RA option to IPv6 WG, then ask IESG to find a new home for the WKA approach.
Rob Austein: Our problem is picking one. If we want multiple mechanisms that's fine, but we can't even agree on that.
David Meyer: There's a similar situation that started in routing area, to do a similar thing, write a document that described choices between alternatives and their technical attributes.
David Kessens: We would like to have the input of this WG about DNS matters. Current thinking has been that some of the knowledge regarding this stuff has been lacking in some of the WGs, although they could already start on RA option. Would like document to see what issues are. Even if we decide to go ahead with multiple solutions, want to know issues. We know this has been going on a long time, decided we need a deadline.
Ralph Droms: I think I'm hearing a clarification, which is what the IESG is looking for is what we know about each of these solutions, but not a recommendation of one versus multiple. Just taken individually, here's what happens with each.
Rob Austein: If we'd gotten to the point where we could have made a recommendation with consensus, that would have been cool.
Ohta-san: Comment: WKA approach is a solution, but is not a mechanism. WKA is by no means discovery. So we should clarify our goal. In last meeting you made presentation that WKA has several problems based on wrong understandings - redundancy provided by anycast. Which is why I modified new draft. It would be good if there is five minutes of presentation time allocated this week about lack of redundancy of anycast.
David Meyer: I think that what the IESG is asking us for is pretty straightforward, and we have been charged with constructing this document, getting it before IESG by San Diego IETF. So I think that's what we can say. Parameterization (???) of that.
Bert Wijnen: Both ADS have been involved. All that you said is correct, with one additional statement: if this WG can't deliver this document, then this WG is not going to work on it. No other WG will either. If you're gonna get bogged down in whether you should or should not do recommendation, if you can't deliver document, we're just not going to do the work.
David Meyer: So that being said, we need author/editor.
Ohta-san: What is title of document?
Rob Austein: We'll drive off that bridge later.
David Meyer: People have to step up.
Itojun Hagino: I am not step up for writing it. This issue has been discussed for long time, so we shouldn't waste the result from there. Could reuse some of the results from discussion over there.
David Meyer: Who is interested in doing the work that needs to be done to get document?
Ted Lemon: I can help with.
Ohta-san: Section about WKA.
Pekka Savola: Volunteering.
Jaehoon Paul Jeong: Volunteering.
Rob Austein: Everybody who's signing up is agreeing to work with editors.
Bob Hinden: Unless this is successful, no further work chartered in this are. Part of that that bothers me is that the IESG has already let one of these solutions go through, so by not doing anything, it picks the outcome by not making progress.
Rob Austein: This is not the place to appeal an IESG decision.
Ralph Droms: I was going to explain why I was shaking my head, but it's out of scope. I'll volunteer to work on DHCPv6 sections.
David Meyer: That's the end of our end of agenda.
Ohta-san: can I make another presentation on WKA?
Editor's note: Ohta-san's made his presentation here.
Rob Austein: my recollection from five years ago is that we had two proposals for anycast root servers, hardy and ohta. hardy was non contentious, went through, is being used. I'm surprised to see section on experiment removed. What happened to that?
Ohta-san: I made almost no effort to do experiments, but my original belief was confirmed. If you want something about experiment I can.
Rob Austein: It'd be useful to write down the results.
Ohta-san: Should I write it?
Rob Austein: Yes, please.
Pekka Savola: One comment/clarification. You are making assumption that anycast address is property of node, not process. I think if we want to use anycast seriously we would have to have api that application would join some anycast group, if process dies, anycast membership is relinquished. The table is still there if process is buggy. Probably needed for serious use of anycast.
Rob Austein: I've actually seen how at least one of the anycast root servers does its implementation of this. In that case the way they're doing it is they have a separate interface. Process listens to that address. You're correct that at least in that case the server is listening to a specific address.
Ohta-san: a process may hang.