2.4.3 Domain Name System Operations (dnsop)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-06-27


Dave Meyer <dmm@1-4-5.net>
Rob Austein <sra@hactrn.net>

Operations and Management Area Director(s):

Bert Wijnen <bwijnen@lucent.com>
David Kessens <david.kessens@nokia.com>

Operations and Management Area Advisor:

David Kessens <david.kessens@nokia.com>

Mailing Lists:

General Discussion: dnsop@lists.uoregon.edu
To Subscribe: majordomo@lists.uoregon.edu
In Body: subscribe dnsop
Archive: http://darkwing.uoregon.edu/~llynch/dnsop/

Description of Working Group:

The DNS Operations Working Group will develop guidelines for the
operation of DNS software servers and the administration of DNS zone
files. These guidelines will provide technical information
relating to the implementation of the DNS protocol by the
operators and administrators of DNS zones. The group will
perform the following activities:

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

4. Publish documents concerning the operations of the root and
      TLD services, and DNS resolvers.

Goals and Milestones:

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
Done  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
Done  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
Done  Submit DNS Response Size Issues to IESG for Informational
Done  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
Done  Submit Common Misbehavior against DNS Queries for IPv6 Addresses to the IESG for Informational
Jan 05  Submit DNSSEC Operational Procedures to IESG for BCP


  • draft-ietf-dnsop-inaddr-required-06.txt
  • draft-ietf-dnsop-bad-dns-res-04.txt
  • draft-ietf-dnsop-serverid-04.txt
  • draft-ietf-dnsop-ipv6-dns-issues-11.txt
  • draft-ietf-dnsop-respsize-02.txt
  • draft-ietf-dnsop-dnssec-operational-practices-04.txt
  • draft-ietf-dnsop-key-rollover-requirements-02.txt
  • draft-ietf-dnsop-ipv6-dns-configuration-06.txt

    Request For Comments:

    RFC2870 BCP Root Name Server Operational Requirements
    RFC3258 I Distributing Authorittative Name Servers via Shared Unicast Addresses
    RFC3901 BCP DNS IPv6 transport operational guidelines
    RFC4074 I Common Misbehavior against DNS Queries for IPv6 Addresses

    Current Meeting Report

    DNSOP Working Group
    Meeting Minutes
    Monday, 01 Aug 2005

    Chairs: Rob Austein
    Scribe: Ted Lemon

    Domain Name System Operations (dnsop)

    MONDAY, August 1, 1030-1230 (Morning Session II)

    CHAIR(s): David Meyer
    Rob Austein

     o Administriva						   5 minutes
       - Mailing list: majordomo@lists.uoregon.edu
         subscribe dnsop
       - Scribe(s)?
       - Blue Sheets
     o Agenda Bashing					   5 minutes
     o Review and status of work items			 
       Newly Approved
       draft-ietf-dnsop-ipv6-dns-configuration (Info)	   5 minutes
         Jeong, et al.
       AD Followup
       draft-ietf-dnsop-ipv6-dns-issues (Info)		   5 minutes
       AD is watching    
       draft-ietf-dnsop-dnssec-operational-practices (Info)    5 minutes
         Kolkman, et. al
       Active Drafts
       draft-ietf-dnsop-serverid-04.txt                       10 minutes
       draft-ietf-dnsop-bad-dns-res-03.txt			   5 minutes
       draft-ietf-dnsop-inaddr-required-06.txt		   5 minutes
       draft-ietf-dnsop-key-rollover-requirements-02.txt	   5 minutes
         Guette, et al.
       draft-ietf-dnsop-respsize-02.txt			   5 minutes
       Expired Drafts (gauge interest)
       draft-kato-dnsop-local-zones-00.txt			   5 minutes
       draft-huston-6to4-reverse-dns			   5 minutes
       Potential WG Items
       draft-durand-dnsop-dont-publish	                   5 minutes
       draft-morishita-dnsop-anycast-node-requirements-01.txt 10 minutes
       draft-krishnaswamy-dnsop-dnssec-split-view-00.txt	   0 minutes
       draft-kurtis-tld-ops-00.txt                            10 minutes
       draft-yan-ipv6-ra-dns-00.txt				   5 minutes
       draft-fujiwara-dnsop-bad-dns-auth-02.txt		   5 minutes
         Fujiwara, et al
       draft-fujiwara-dnsop-dns-transport-issue-00.txt	   5 minutes
       draft-massar-dnsop-service-00.txt                      10 minutes
       draft-minda-dnsop-using-in-bailiwick-nameservers-01.txt 5 minutes 
    Overview of Notable Conclusions
    - draft-ietf-dnsop-key-rollover-requirements-02.txt
    	Of people in room who had read it, almost all wanted to
    	kill this one. Take to list, in form "we will kill this
    	unless somebody strongly and coherently objects".
    - draft-ietf-dnsop-respsize-02.txt
    	WG sees it as ready for  WGLC; However, Kato-san asked
    	for time to provide another revision.
    - draft-kato-dnsop-local-zones-00.txt
    	Not enough of those present had read it to have an
    	opinion. Sam Weiler says default should be drop this
    	unless somebody wants to stand for it.
    	Mark Andrews wants empty zones for bogus names but also
    	wants zone transfers of root zone to get rid of .local
    	and .localhost issue. for one more revision first.  
    - draft-huston-6to4-reverse-dns
    	Apnic is running stuff based on this, so the WG needs to
    	ask the authors to bring it back.
    Meeting Narrative =================

    DNS configuration document, DNS director had something he wanted to say. David Kessens.

    David Kessens (AD). The DNSconf doc has been approved by IESG. We did stick in IESG ???, was out for review for IESG to make sure every agreed. After this review round is done, should be announced by secretary, sent to RFC editor. Doc is approved, should move shortly to RFC editor.

    Rob: So as far as WG is concerned, doc is done.

    Harry Carp: IDN issue, in context of ICANN, there are several members of that council president here, we would like to depart from Paris knowing more about the current IETF concerns about IDN. Is that likely to come up this morning?

    Rob: No, that's an application issue.

    Patrik F ltstr m: working with IDN issue here in IETF. People that want to know more about IDN and IETF can contact me after Wednesday lunch.

    David Meyer: I wanted to point out, Olafur asked me for some time at the end for update on some performance numbers he's been gathering.

    Just to bring everybody up to date, ipv6 dns conf done. dns-issues is in AD followup. AD is watching: dnssec-operational-practices. serverid is active.

    Pekka Savola: Just say about this doc in ad followup that we have had discussion with Thomas Narten who was providing feedback, doc has been revised, was published in July, still trying to get him to follow up on the revision to see whether his concerns are met. In meantime, suggest that people in WG who have been looking at doc should look again, make sure there are no changes wg would be uncomfortable with.

    Rob Austein: issue with truncation, no feedback from DNSEXT? Recommend anybody who cares think about it really hard and answer Pekka. Pekka, set timeout, after a while go with what you've got.

    Pekka Savola: Jinmei provided some good feedback, but I would like some more.

    Suzanne Wolffe: Only need two minutes. Server ID last call got substantive comments that go to clarifying rationale, so there will be another rev. Want to see chair's comment on last call.

    Rob Austein: David Conrad had comments, woke up during last call, asked to roll back to what we had 2-3 years ago. My read on this, with respect, that is the rough part of rough consensus. If anybody disagrees, please say so now.

    Sam Weiler: could you go back a slide? Operational practices - what do we need to be doing?

    Rob Austein: passed wg last call, ready to send to IESG. We think we're done with that.

    David Kessens: ad is watching has little meaning.

    Rob Austein: draft tracker knows doc exists, that's all.

    Olaf Kolkman: after last call, well after, we got a couple of people commenting on draft, comments were substantial. Real content. We addressed these issues by setting up open issues on ML, tried to word smith text, propose solution, set timeouts on them, didn't get push back on everything, so I think those issues can be closed. Another thing that we got feedback on, table that we use in doc to suggest key sizes. Hillary Orman, one of the authors of BCP for determining strength of public keys, 3766, gave some push back there. And we haven't addressed that yet. We will this week, and post another issue to the list, setting timeout. Once we incorporated that work, we propose that we would like to have another review on the doc.

    Rob Austein: another WGLC?

    Olaf Kolkman: I think that's in place, but please honor that last call, because it's really unhandy to get a lot of feedback two months after last call. At some point you want to end the work, as an author. So please feed back.

    Matt Larsen: I submitted a new version of this draft after embarrassingly long time, I think I got everybody's comment who made comments in both of the last calls last year, so please read new draft, let me know what you think.

    David Meyer: thank you. I did talk to Daniel a little about this one (inaddr-required). There ahd been controversy over this one, we discussed changing name, he has revision of this, thinking of changing name, that triggered a bunch of things, so we'll have that out on the list, there is another version that hasn't hit repository yet.

    Rob Austein: The key rollover requirement. This is a doc that the wg accepted a couple of years ago, TBH I don't think we've seen a lot of support for doc other than from authors. We've had several requests to remove it as wg item. Never get very many people who have opinion, a few ask to remove, a few ask to keep. Of the relatively small sample, mostly saying get rid of it. So we will drop unless there is serious objection.

    David Meyer: Continuing on. Alain isn't here? How many have read this one? (don't publish) I think there were substantial comments on this one.

    Alain Durand: we missed deadline, so I promise that will be done soon. I'm still waiting for some text that some people promised to send me, so would like to see in my mailbox.

    David Meyer: was just updated moments before draft cutoff. respsize. Has anyone seen revision? I didn't see a lot of traffic about this one. I guess since we don't have authors here, will take to list.

    Bill Manning: I think one of the reasons for bring back to wg is that this is in ICANN formal procedures, and it's difficult to reference a doc that doesn't exist anymore. It's extraordinarily helpful to have a persistent doc for those kinds of reasons.

    Rob Austein: last time wg considered WGLC, author said it's not ready because I have a hidden surprise in doc. Since then people have found it, auth has dropped objection. My sense is we should go for WGLC.

    Ted Lemon: There are some textual problems with it, some points are missing. No substantive issues, just editing.

    Akira Kato: the one of the modification of the doc is written the parse script in appendix, I got the comment from Pekka last minute, and maybe something regarding to tcp misunderstood, so we may need to modify before the last call is being taken. If you have any other comments on doc, please pass to the list.

    David Meyer: Do you have another revision?

    Akira Kato: maybe we are going to work on.

    David Meyer: so you want to revise.

    Akira Kato: yes.

    David Meyer: Expired drafts. Interest? Local-zones draft? Rob were thinking, keep these or kill them. Other one is keff's reverse dns draft. What we wanted to do was try to gauge interest in working group. Informally, temperature.

    Rob Austein: slightly different states. Kato-san didn't think local-zones draft was ready. Jeff's draft, he wanted to take it as wg item, couldn't get anybody to read it.

    David Meyer: how many people read local zones doc? Of those, how many think it's valuable? We need to take it onto the list.

    George Michaelson: we hope to be able to put something up on agenda, we have it in deployment, there is a test service, has had zero promotion, included text in SOA of zone, we now have about fifty to seventy live 6to4 reverse registration, service basically works, concerns about scaling and resiliency, there is a test service.

    Rob Austein: to be clear, implements this draft?

    George Michaelson: yes, with knobs and frobs.

    Rob Austein: So this draft describes code that is in use out there now, operational.

    David Meyer: how many people read? How many people think to bring it back? Okay. dnsop-service.

    Sam Weiler: I want to go back to local-zones doc. It looks interesting, but if nobody is advocate for it, I think we should drop it. I'd be delighted to hear from Kato-san that we still think it's a good idea. But by default, should drop.

    Mark Andrews: I think local zones should be split into two. One to do reversal namespace, in terms of doing automatic construction of empty zones, reverse namespaces, ipv6 locally-signed local addresses draft. This one's a good place to split that part out, do for 1918 addresses, anything that fits in that same class of problem. .local, .localhost, largely solved by choosing different rationale for how stub resolves, local caching services keep root zone. Keeping copy of root zone locally would address the issue in terms of .local, don't get traffic to the root, just zone transfers from the roots. Slightly different issues: separating them apart, there's a few of them, name service should by default return name error on those things, would be a good idea.

    Jeroen: doing lot of ipv6 stuff, need to be able to detect what is closest bubble broker. Simply specify where your web server is, where mail server is, so basically you would have. So this is what you normally stick into DNS for SRV. Why not make a .service domain? If you have any cast address which has .service, then you get local version. You could request _website service, would get local services. Etc. So user doesn't have to configure anything local. When traveling, use example network. This would make configuration issue almost nul. You need anycast DNS address somewhere so that you can have local announcement.

    Tunnel service discovery. You could always have local tunnel service.

    Alain Durand: first, how does this relate draft-yamamoto naptr service discovery?

    Jeroen: it specifies that the application which is going to look at DNS, If you don't have dsp protocol, 6to4, etc, or if different service, then you connect to a service which is not intended to be used in this way.

    Keith Moore: completely invalid assumption.

    Rob Austein: not wearing chair hat. I'm not sure whether I read this in draft, maybe clarity issue, may be a problem. Looks like you're proposing that this be a pseudo-top-level domain. You probably don't want to go there. Secondly, there's a bit of history behind anycast DNS, several years of excitement we had with DNS conf stuff. Thirdly, we could have long interesting discussion about appropriate service names, maybe Mr. Moore would have something to say. You're just moving the problem.

    Keith Moore: there are a lot of topics about this that are right. We already have a lot of really bad service discovery mechanisms. No better than DHCP or Apple's stuff or a lot of those things. Any time you try to put DNS below IP. The notion is that the local net knows what's good for you. Not true in may cases, not true in general. We don't need another one. Not an improvement over the bad stuff we have already, not worth pursuing. I would agree about TLD issues and anycast issues, service name issues, huge numbers of ratholes.

    Alain Durand: would like to remind, this is an issue that was looked at in tc bof at Minneapolis, as followup to that on Thursday, allow-w bof, should be brought up at another time.

    Michael Sanf: maybe missing something, if problem is that you have service that is discovered by different protocols, can already use NAPTRs and SRV as defined in RFC3958.

    David Meyer: Of the people who have read this, is this a candidate for a WG item? Okay, moving right along, split view, author is not here. Make sure everybody knows we have it as potential item. Anybody not signed the blue sheet.

    Rob Austein: WG needs to read. Split DNS is something we're stuck with. That being the case, we have to know how to do it with DNSSEC. I don't know that this doc is right, but we need to look at this space.

    David Meyer: kurtis-tld-ops

    Kurtis Lindqvist: not going to talk about doc too much in detail. History: got stuck with. Had a question about ICANN about requirements to run TLD. IAB realized there are none. So it thought that maybe this would be good thing to have. I got elected, this got dumped on me. So I started writing something up. The IAB had discussed this, not an IAB issue, really DNSOP, IAB wanted to make sure it got written up, so I started, circulated this to usual suspects, got quite a lot of feedback. Stole large chunks of text from ?? document. When putting comments into single doc, ready for pub, I realized that the feedback was going in two different directions.

    Intention is not to have some sort of document you must adhere to. More like a check list. Description of trade offs. Hard to come up with list of things TLD operator would have to adhere to. Very hard to come up with single set of minimal requirements.

    So the operational guidelines doc would be some sort of best practice doc. Slave server, master server setup. TLD operations doc is unclear to me, what we would like to do. How do we do register, EPP, whatever? Probably doesn't belong in DNSOP. BCP. I see two issues. Having operational guidelines just for TLDs seems out of scope. Would a doc like this make any sense?

    Rob Austein: chair hat off. I think proposed split makes sense. Considerations, tradeoffs, sounds like an excellent idea. Hesitant to promise there will be no normative language. Might be appropriate. Jump off bridge when we get to it.

    Secondly, TLD ops, I agree we don't know where that should be written, okay to start here, move if you want to. Probably normative reference to first one.

    Kurtis Lindqvist: don't have strong feeling who should do it.

    Lars Liman: doing op recommendations, we've been trying to do that for more than ten years now. Requirements for DNS operations vary wildly between who we are, where you are, and what your environment is, so focusing on tradeoffs and consequences is fine, general recommendations we've been there.

    Kurtis Lindqvist: no requirements. I don't think there is normative language going into doc like this.

    Lars Liman: I do agree would dbe very glad to see doc that enumerates stuff, says this is the bad consequence you're going to get if you do this, also this is the good consequence you'll get if you do this.

    Ted Lemon: I want to concentrate on second one. Want to remind that ISOC has a program of doing courses for starting TLD registries, not long ago doc was published, I think it would be nice to catch up with these folks.

    Bill Manning: having trod this road in past, author of 2010, 2780, flaws in these docs seem to be re-emerging here. 2780 is targeted toward TLD service. You really need to be very clear and concise - TLD or registry? Separable tasks. Ops for machine, or guidance on how to maintain service? Will echo Liman: wide range of things that you can have for an authoritative server.

    Kurtis Lindqvist: if you look at doc, I tried to address this. Root of doc goes through physical security, etc. One of discussions in usual suspect group is does it make sense? I'm not sure I have a strong view of that. Service is more important than actual machine, I think.

    Antti: I think our registrars will be effected by changes in limans spaces if you do pre-validation of host on how they work the DNS.

    Kurtis Lindqvist: I'm not even sure PPP is part of that doc. The second doc I'm proposing, I'm looking for input on what should do there. Maybe look at ISOC doc. More framework than technical.

    Yasiki Orange JPRS: As bill manning said, there are so many varieties in each TLD service operation. Technical and political style. Number of domains in each TLD so very different. SO I think that it has another difficult issue than root server operation. RFC2780. But I personally think this is one of the good approach, need to go to BCP. But an we have to discuss and brush up this document for the TLD communities. Including worldwide TLD. But don't forget that there are so many varieties.

    Kurtis Lindqvist: the fact that this varies, wide scope that you and Liman are bringing up is more of an issue if you put normative language in there. That was the reason why I didn't want normative language. It's not that if you can't collect entire range of issues in one doc, you shouldn't write doc.

    Yasiki: I will make presentation.

    George Michaelson: I'm with APNIC, we act as secondary to large number of CCTLDs in our region and internationally. There's an aspect of this that documenting this raises the bar, but formalizing some of the behaviors could raise the bar to the point where we can't be sure if we can offer this service. ICANN is hammering on them. If you're saying we can be more relaxed about this, that's putting us in a funny place, because it's implying that it's okay, it's good to document this, but a side effect of this is that things will get tighter.

    Kurtis Lindqvist: as far as I know there was never any pressure from ICANN to develop this document.

    George Michaelson: I with draw that comment.

    Elakoff ???: I am afraid of handing loaded weapon to ICANN without knowing at what size ??? I should design the bullet for. This WG should narrowly focus on DNS issues and nothing else. Splitting and dumping one doc to another group, I would argue against working on registry operations in DNSOP.

    Robertin Martin: I would like to second what peter says. Second, ways of running TLD reflects what comes from, some other domains would benefit. Title should be how to run a zone setup. Also for other people, google.com is probably more important than my TLD.

    David Meyer: Next, bad-dns-auth.

    Rob Austein: in the interest of time, would like to open door on what has changed - people want to get to lunch.

    I'm Fijuwarea: BIND 8 caching server problem, I think is not DNSOP issue. I contacted to ISC. If possible, ?? and I will write new ID about authoritative DNS server?.

    David Meyer: what would you like WG to do with your document? Adopt?

    Fijuwara-san: I couldn't update this ID, but will continue next time.

    David Meyer: ipv6-ra-dns

    DING Zhemin. Updating DNS configuration. Propose new method to perform DNS update using stateless addrconf. New document to transfer domain name option. New RA/RS option. Type is domain name option, length means whether host or router does DNS updates. By default router.

    When we send RA messages it is required if we want to send domain name option, bundle it with prefix option. Simple procedure. DNS update. First step is optional - send messenger to router. Router sends RA option back with DNO. IPv6 host will auto-configure the address and its complete the domain name, then send it back using RAs messenger. The host can directly update to DNS server or can use router to perform the DNS update. Questions?

    Olaf Kolhman: security? I haven't read draft, TBH, but when I saw little diagram there, was thinking security, key exchange. If router does update, key exchange is simple, but if it's an IP host that enters a domain, how does it get ??

    DING: we prefer to use router. Added host option for probably some network administrator would like to use.

    Alain Durand: I'm not sure even router updating DNS is good enough, may have key for some part of address, but how will he trust the host to have right host ID? If you have DHCP server, easier because server allocates address, but not the case with router.

    Also, you are assuming that all the host on subnet share the same domain. In my experience that's not the case. Also that there is only one domain on subnet, in my experience this is not the case.

    DING: probably we didn't make assumptions more clear. Enterprise network, campers network, so in this network the relation between host and router is trusted, so of course security is a concern, in this draft we are addressing security in another draft, it's a very big issue.

    Rob Austein: chair hat off, there may be portions people want to drop. Core part is worth discussing, maybe not in this WG. One of the hard parts of IPv6, stateless, we have absolutely no explanation for how to do reverse tree update. In DHCP, DHCP server does. If we deal with security issues. Potentially useful part of this is to provide reverse translation. For forward, host does its own update. That said, this now reduces to a previously unsolved problem - total lack of any security model in stateless autoconf. Helps in that now keys are only in possession of router. Probably an improvement. Whether you can trust data is a separate issue. My recommendation would be to focus this strictly on the reverse tree update, leave the rest out. FQDNs, please. Not a local suffix that you just add.

    Tatuya-san: i read doc, have technical questions, but before going into that, have bigger level question. I think some of the people pointed this out, but in my understanding the basic consensus of router advertisement is that we don't want to put higher-layer stuff in it. When we discussed how to discover DNS requesting server addresses, there was a proposal to include info in RA, even for fundamental level information there was a lot of disagreement, opposition to that. At the same time there are another people who supported that approach, but even for such fundamental functionality, there were a lot of push backs to that type of approach, so I'm afraid this one will face even stronger push backs to the use of router advertisements for such application level information. If you think it's okay, please go ahead, I cannot stop that.

    DING; appreciate comments.

    David Hankins: I didn't see any mention of how you expect to overcome race conditions. As far as I know, there's no teardown event in router advertisements. So nobody knows to remove the entries. This rapidly becomes a cesspool, a swamp. What happens if two different clients think they have the same name? Were you going to address that in a different draft?

    DING: definitely name collision is a big problem.

    David Meyer: where would you source an identity for the client?

    DING: how to solve the problem? We are working on it.

    Alain Durand: I would like to comment on Rob's comment. This is useful ih teh reverse tree. If we do not make this secure, there is no point in doing it.

    DING: that's why we propose using router.

    Alain Durand: if you don't secure host to router, useless.

    Rob Austein: Alain and I agree on this. The one value I see from this is getting rid of temptation to put keys in reverse tree onto laptops.

    Ilitsch: security isn't always necessary.

    Ted Lemon: use DNSSEC.

    Keith Moore: host knows what its name is, if network doesn't agree, shouldn't be making assertions. Instead configuration error should be reported. To change hostname is jus broken. We don't need to further that. If this thing has a purpose, it's to set the reverse path, it is reasonable to set binding between address and resource records. Probably the update needs to happen via a different path.

    David Meyer: moving right along, dnsop-using-in-bailiwick-nameservers

    Minda-san, JPRS: Many people know that reverse DNS lookup is slow. Lame delegation? No, there are two reasons. One, hostname of namesever is used the standard name. This causes gluelessness. Actually case is glue-less on caching name server.

    When glue of nameserver is not obtained, caching name server is retrieved from root namserver again. Takes time to repeat.

    BIND 8 glueless issue, on caching name server stops answering client and starts iterative query to find the address of nameserver. After timeout, client retries, takes 5-10 seconds or more. Other implementation does not have this issue.

    Solution: in-bailiwick nameserver in .ARPA.

    Mark Andrews: I really don't think we should make decisions based on the fact that BIND 8 is broken. As an author, I know it's broken. And nobody really should be running BIND 8 anymore. Replace it.

    George Micahelson, APNIC. We discuss operational aspects of managing the reverse tree in regional registry meetings, if you want to talk to us about operational changes, you really do need to come to that process. Your slides imply that there is a delegation tree, not that straightforward. In IPv4 and IPv6 reverse, delegation of glue is probably not where you think it is. So if you are going to document this issue, you need to think about what is the assumption of the boundary of the glue. Your effective saving in round trips may not be accurate in that circumstance. I really think you need to bring that to a different forum.

    Rob Austein: chair hat on. One clarification to BIND * issue. It is not that the victim is running BIND 8. BIND 8 is beating up on other servers.

    Peter Kord: My usual rant, bailiwick should be less religious. My concern with this is that it probably doesn't scale. Assuming a clear cache, counting number of ops needed to go down to those names. So this is about easy access to additional date, IP addresses of nameservers. Usually the recursive resolvers operate with caching, more often than not TLD servers names and addresses will be available. I challenge your calculations - unless you do weird things, cache is almost never empty. For scaling, working for TLD registry which has 6m delegated domains, if only a fraction of our customers would follow advice and switch from relying on ISPs ore registrars to be named in the delegation, would switch to in-zone, in-domain naming scheme, there would be much more trouble due to inconsistencies. Out of our 6m domains, we delegate to no more than 50k Name servers. You would end up with millions of nameservers.

    Olaf Kohlman: in a few slides up you mention DNSSEC performance. DNSSEC has its own validation chain that doesn't' depend on where glue is. At the moment you get the delegation down the tree, ... you don't need to resolve glue to follow that chain. I'm challenging that statement about reduced cost - I don't think it's relevant.

    Mark: ??? The reason NS records exist in the first place is to make changes to addresses easy in terms of one place where it has to be done. Going to in-bailiwick breaks what we designed the DNS for initially. We could just as easily put an A record in there. The NS record is there so that you can break the simple one place to change when you are changing the name server's address.

    Sam Weiler: I'm not sure I completely agree with Olaf about DNSSEC validation. Resolver should only check main path, but it's reasonable, but not advisable to check glue.

    Morishita-san: BGP anycast node for authoritative name server requirements.

    Rob Austein: chair hat on. Where might be an appropriate place to do this. Biggest chunk is anycast stuff, might be more appropriate over in the GROW working group. Portions of this are covered by Kurtis' work. Non-IETF venues, probably ought to get reviewed there.

    David Meyer: two more items. Lixia Zhang has a brief talk she wants to give us on DoS mitigation technique, then Olaf wants a minute on DNSSEC performance.

    Lixia Zhang: We planned to rev draft, didn't get to it. DNS' hierarchical structure provides an easy target for DDos. We propose another solution. We got idea from Paul Mocapetris' paper 20 years, ago, administrator defines TTL values for reach RR as prt of the zone definition.

    Rob Austein: a number of resolvers have a limit to the TTL they will accept.

    Lixia Zhang: change ceiling to one month or longer. There is also concern, what if you have to fetch halfway through TTL? Would increase query rate? Measurement shows that on root servers, 90% are junks, so this could potentially, if refreshed often, increase legitimate queries from 2% to 4%. What if cache got poisoned, bad info stays longer? Bad implementation, need to do something to fix it. Other issues?

    ??: thank you for writing this up, but there's a problem. If I postulate a DNS-signed zone world, TTLs of a week long will affect your time to compromise recovery. One week si going to be extraordinarily long for signed zones. Unacceptable tradeoff. Using TTLs as a tool, that's unacceptable.

    Olaf Kohlman: I was going to say the same. Signature lifetime cuts off TTL. Keeping a short DNSSEC signature lifetime protects your children in case of key compromise. Tradeoffs need to be made. That's going to set time limit, not TTL.

    Sam Weiler: I see a couple of things here. We're wanting to see queries repeated fairly often so we don't have easy rollover. Resolvers should be able to continue using old data. One is to communicate this in protocol by updating TTLs. Has advantage of letting old resolvers be more resistant to DOS attacks. Another thing you could do is have resolvers not actually hard expire the data - if they can't reach the servers, they just keep using the old data.

    Lixia Zhang: another engineering tradeoff.

    (lots of boos and yells from the peanut gallery)

    Mossan Suicy: I would like to know how much availability you can gain.

    Lixia Zhang: student didn't get data ready. Gigantic DNS lookup, Most servers are stable.

    David Meyer: last one.

    Robert Martin: Over the last period of time, within center, one of the things people have been complaining a little bit about is that time it takes IANA to do a change to the root. Some people are complaining about months, others are complaining about a week. Upping to week, might be bad.

    Lars Liman: two comments. That's an administrative thing you have to approve IANA. And you cannot set TTL in record set. You might have to change a number of servers in record set on short notice, outside your control. Business partner goes bankrupt. Natural disaster. Too long TTL is not a good thing.

    Peter Koch again: ttl on delegations in root zone may have less influence than one may think since they are likely overwritten by NS records coming out of authoritative zone.

    Rob Austein: we cut off comment already long ago.

    Lixia Zhang: continue:

    Olaf Kohlman: was not on agenda, have measurements of DNSSEC on K root servers. 15 minute presentation, no work item, and I am lined up to do same presentation in a little work group for DNSSEC deployment later this week. Russ: when?

    August 3rd at 10:30. Room 315. So not going to give presentation, come Wednesday.


    None received.