Last Modified: 2004-05-18
1. Define the processes by which Domain Name System (DNS) software may be efficiently and correctly administered, configured, and operated on Internet networks. This will include root zone name servers, gTLD name servers, name servers for other DNS zones, iterative DNS resolvers, and recursive DNS resolvers. 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 software.
2. Publish documents concerning DNSSEC operational procedures.
3. Publish documents concerning the IPv6 DNS operational procedures and DNS-related IPv6 transition and coexistence issues.
4. Publish documents concerning the operations of the root and TLD services, and DNS resolvers.
| Done | Submit I-D: revised Root Server Requirements. | |
| Done | Submit I-D: revised version of Key Handling. | |
| Done | Submit I-D: first version of Servers Sharing IP#. | |
| Done | Submit I-D: first version of Performance and Measuring. | |
| Done | Submit I-D: revised version of Key Handling. | |
| Done | Submit I-D: revised version of Servers Sharing IP#. | |
| Done | Submit Root Server Requirements to the IESG for consideration as Informational (BCP?). | |
| Done | Submit I-D: 2nd revised version of Servers Sharing IP#. | |
| Done | Distributing Authoritative Name Servers via Shared Unicast Addresses to the IESG for Informational | |
| Apr 04 | Submit Observed DNS Resolution Misbehavior to the IESG for Informational | |
| Jun 04 | Submit Identifying an Authoritative Name Server to IESG for Informational | |
| Jun 04 | Submit Requiring DNS IN-ADDR Mapping to IESG for BCP | |
| Aug 04 | Submit document describing the outstanding problems and issues with DNS discovery for IPv6 to the IESG for Informational. | |
| Sep 04 | Submit Requirements for Automated Key Rollover in DNSsec to IESG for Informational | |
| Sep 04 | Submit DNS Response Size Issues to IESG for Informational | |
| Oct 04 | Submit Operational Guidelines for 'local' zones in the DNS to IESG. Category to be determined. | |
| Oct 04 | Submit Operational Considerations and Issues with IPv6 DNS to the IESG for Informational | |
| Oct 04 | Submit Common Misbehavior against DNS Queries for IPv6 Addresses to the IESG for Informational | |
| Jan 05 | Submit DNSSEC Operational Procedures to IESG for BCP |
| RFC | Status | Title |
|---|---|---|
| RFC2870 | BCP | Root Name Server Operational Requirements |
| RFC3258 | I | Distributing Authorittative Name Servers via Shared Unicast Addresses |
|
Domain Name System Operations (dnsop)
WEDNESDAY, August 4, 2004 (1300-1500) ===================================== CHAIR(s): David Meyer <dmm@1-4-5.net> Rob Austein <sra@isc.org> MINUTES: Ted Lemon <mellon@fugue.com> ========================================== 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'tcovered, please speak up. Rob Austein: Documenting state of inconclusive discussion we've hadover 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: majordomo@lists.uoregon.edu 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. |