From jim at rfc1035.com Mon Jun 6 13:13:36 2005 From: jim at rfc1035.com (Jim Reid) Date: Mon, 06 Jun 2005 12:13:36 +0100 Subject: [dns-wg] Followup to IANA TLD delegation problem In-Reply-To: Message from Doug Barton of "Fri, 27 May 2005 15:18:53 PDT." <42979CCD.5000602@icann.org> Message-ID: <22874.1118056416@shaun.rfc1035.com> >>>>> "Doug" == Doug Barton writes: Doug> Jim, We're happy to provide answers to these Doug> questions. Given that Monday is a holiday in the US, may I Doug> suggest that we will provide answers to the questions listed Doug> on Tuesday 31 May unless you or the WG indicate that more Doug> time is needed for you to formulate the list? Hi Doug. You'll have seen that there's been no detailed discussion in the last week or so on the mailing list about this issue. Most of the comments have seemed to echo the questions that were in my earlier mail. Assuming that you're back from paternity leave, I think it would now be helpful for these questions to be answered. This would allow us to finally resolve this issue and hopefully prevent it flaring up again in some other forum. Here are those questions once again: [1] What was the nature of the technical problem that prevented multiple names in for an IP address and how was it resolved? [2] Why was there no announcement that this problem existed? [3] Are safeguards now in place to prevent this sort of problem recurring? [4] What procedures does IANA (or ICANN?) have to make sure that changes to the TLD delegation process or problems with that process are properly communicated to its stakeholders? [5] Were those procedures followed for this incident? If not, why not? From kim at centr.org Mon Jun 6 15:39:26 2005 From: kim at centr.org (Kim Davies) Date: Mon, 06 Jun 2005 15:39:26 +0200 Subject: [dns-wg] [Fwd: [centr-fm] Re: IANA TLD delegation issue] Message-ID: <42A4520E.5070006@centr.org> Dear all, Olivier Guillard of AFNIC has described in the attached document the details of their attempts to redelegate their domains. It is a useful summary of the issue as they experienced it. kim -- Kim Davies, Council of European National Top Level Domain Registries Avenue Louise 327, B-1050 Brussels; Tel. +32 2 627 5550 -------------- next part -------------- An embedded message was scrubbed... From: Olivier Guillard / AFNIC Subject: [centr-fm] Re: [centr-ga] FWD: IANA TLD delegation issue Date: Mon, 6 Jun 2005 14:53:21 +0200 Size: 55650 URL: From paf at cisco.com Mon Jun 6 16:23:04 2005 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Mon, 6 Jun 2005 16:23:04 +0200 Subject: [dns-wg] [Fwd: [centr-fm] Re: IANA TLD delegation issue] In-Reply-To: <42A4520E.5070006@centr.org> References: <42A4520E.5070006@centr.org> Message-ID: <2C2E1298-F7CA-4C00-8420-DAE3D62EBAA8@cisco.com> Olivier, can you please, if not done so earlier, please send this for publication as an I-D. Patrik On Jun 6, 2005, at 15:39, Kim Davies wrote: > Dear all, > > Olivier Guillard of AFNIC has described in the attached document > the details of their attempts to redelegate their domains. It is a > useful summary of the issue as they experienced it. > > kim > -- > Kim Davies, Council of European National Top Level Domain Registries > Avenue Louise 327, B-1050 Brussels; Tel. +32 2 627 5550 > > From: Olivier Guillard / AFNIC > Date: June 6, 2005 14:53:21 GMT+02:00 > To: Marcel Schneider > Cc: fm at centr.org > Subject: [centr-fm] Re: [centr-ga] FWD: IANA TLD delegation issue > > > Marcel and colleagues, > > as the AFNIC multinamming story with IANA was quoted > within exchanges, we felt necessary to provide the > community with a report to clarify what happened. > > Find it here included. > > As there is no standard format to communicate over > the TLD community this kind of reports, I have > choosen the RFC one. It is not designed for this > kind of communications, but I felt that it was the > less unappropriate to use (-> it does exist and it > is known by ccTLDs). > > This is a raw draft: I would higly appreciate > *ANY* suggestions and inputs. > > This issue will be discussed over the next CENTR GA > in Trondheim: > http://www.centr.org/docs/2005/05/centr-ga26-agenda.pdf > > Best regards, > > > le vendredi 13 mai ? 15 H 58 , Marcel Schneider a ecrit : > >> Since this is a real technical concern to us all. Propose >> we ask IANA to clarify. >> >> >> Marcel >> >> >> ------- Forwarded Message >> >> Date: Fri, 13 May 2005 14:50:00 +0100 >> From: Jim Reid >> To: dns-wg at ripe.net >> Subject: [dns-wg] IANA TLD delegation issue >> >> Here is a copy of the mail that has just been sent to IANA in >> followup >> to the discussion during last week's RIPE meeting. My thanks to those >> who have helped draft this message so promptly. I will keep the WG >> informed of developments. >> >> Dear Colleagues, >> >> This note follows a discussion at the DNS Working Group during last >> week's RIPE meeting. Doug was unable to take part in this discussion >> because he was called away early. Therefore we have sent you this >> message so that we can clear up any possible misunderstandings and >> hopefully avoid invoking more formal mechanisms. >> >> The RIPE DNS Working Group is concerned about some aspects of the >> current practice regarding IANA TLD operations. In particular the >> problems encountered by AFNIC last month are unsettling. >> >> It is our understanding that IANA has recently stopped accepting >> certain updates to the DNS root zone. The current practice now >> appears >> to require each particular network address used in glue address >> RRs to >> have one unique DNS name. This requirement is new: multiple names >> already exist in the root zone for some name server addresses. There >> is no technical reason in the DNS protocols preventing this practice. >> >> Important technical and operational goals can require TLD >> operators to >> use different names for the same address. The most obvious of >> these is >> more efficient name compression to make room for additional data in >> responses. Multiple names for the same address can reduce the amount >> of co-ordination required in case of name server address changes. >> >> We do not understand why this requirement has been introduced or the >> process by which it was agreed. The RIPE DNS Working Group is >> disappointed that this change appears to have been carried out by >> IANA >> without prior consultation or discussion. We would like to know >> rationale for this policy and the mechanism which led to its >> introduction. We'd appreciate any clarifications from you before >> Friday, >> May 20th. >> >> Regards >> >> ..... >> chairs RIPE DNS WG >> >> >> ------- End of Forwarded Message >> > > -- > Olivier > > > > From Ed.Lewis at neustar.biz Mon Jun 6 23:00:00 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 6 Jun 2005 17:00:00 -0400 Subject: [dns-wg] [Fwd: [centr-fm] Re: IANA TLD delegation issue] In-Reply-To: <42A4520E.5070006@centr.org> References: <42A4520E.5070006@centr.org> Message-ID: What I find interesting is the trade-off of: The gain in packet compression by using similar names plus the operational advantage of streamlining the names vs The gain by spreading name server names under other TLDs plus the logging convenience of only needing one PTR record per address 1) Compression to insert more name servers or more glue records into a response is an advantage that I think is becoming outdated. With anycast, there is no longer a need to have a name per name server. (Still, a target of about a half-dozen names in the NS set is better than less.) Also, with fewer names listed, there are fewer names to resolve just to get the name server set. (Not all implementations will resolve all the names, but large-market-share ones do.) 2) Operational gains of having similar names is a good thing, but at what cost and for what gain. It would be good to be able to quickly ping all the names with a simple shell script from the top of your head. But what if you misread a problem report and debug e.ext.nic.tld instead of e.int.nic.tld or e.nic.tld.? 3) I would think that having servers listed under other TLDs (as we are looking at a ccTLD here) would be a good thing. Just for the fact that we are spreading the servers about (in DNS, not just topology). In addition, these servers don't count against the glue space hit in the response. 4) Multiple name per address is one of those topics that gets bashed back and forth. At times we find it distasteful to have multiple PTR records in a set, for instance, this makes traceroutes and logs list potentially "wrong" names. Other times we are reminded that it is perfectly natural to allow more than one PTR record in a set. Maybe this is a "it's good for servers but not good for routers" situation. The part of the trade-off I haven't addressed is: The gain by using unique name server names for each delegation vs The need for extra IP addresses in light of a one name per address policy I think we want to allow there to be unique names for name servers so that changes to one delegation do not impact another. I think it is also good not to waste addresses, using them as needed only, which is also possible if the policy of one name-one address is dropped. (I think it is, I'm just supporting a reason to do so.) Nevertheless, what I've debated above doesn't seem to be the point of the document. It seems the document is presenting discomfort with the response. Here I merely tried to detail the technical points, and not get into the response. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From jim at rfc1035.com Tue Jun 7 01:45:35 2005 From: jim at rfc1035.com (Jim Reid) Date: Tue, 7 Jun 2005 00:45:35 +0100 Subject: [dns-wg] TLD delegation trade-offs In-Reply-To: References: <42A4520E.5070006@centr.org> Message-ID: <914b20e5eb880a39b62af3a485a82719@rfc1035.com> Since this looks like the beginning of a new thread on this discussion, it's only fair the Subject: header gets changed.... On Jun 6, 2005, at 22:00, Edward Lewis wrote: > What I find interesting is the trade-off of: > > The gain in packet compression by using similar names plus the > operational advantage of streamlining the names > > vs > > The gain by spreading name server names under other TLDs plus the > logging convenience of only needing one PTR record per address Ed, I'm not sure I understand the second part of your trade-off. The benefits of better label compression and streamlined names seem clear enough. Spreading name server names under other TLDs appears unwise: there's an increased likelihood of not getting all the glue in a referral response with that approach. Or have I missed something? I note Neustar doesn't spread the TLD NS RRsets for .biz and .us like that. :-) And as for reverse lookups, I doubt anybody or anything cares about what name (singular) should be returned for the address of some TLD server. The operator of that server will care of course, but why would anyone or anything else even need to care? > 1) Compression to insert more name servers or more glue records into a > response is an advantage that I think is becoming outdated. With EDNS0 out there, I tend to agree. But there are lots of name servers deployed that don't and won't support EDNS0. And even if EDNS0 was ubiquitous, I'd prefer to see NS RRsets use a clean set of target names. It's prettier. And it reduces the protocol overheads: fewer CPU cycles encoding/decoding DNS packets as well as saving precious bytes we're going to need for DNSSEC RRtypes. :-) Even with EDNS0. :-( > 3) I would think that having servers listed under other TLDs (as we > are looking at a ccTLD here) would be a good thing. Just for the fact > that we are spreading the servers about (in DNS, not just topology). > In addition, these servers don't count against the glue space hit in > the response. Could you please expand on this Ed? There are things I simply do not understand here. What's gained by spreading the hostnames for 8 (say) name servers for some TLD across .tld0, .tld1, ... .tld7? And how does the extra space needed for these names not "count against the glue space hit" in a referral? > 4) Multiple name per address is one of those topics that gets bashed > back and forth. At times we find it distasteful to have multiple PTR > records in a set, for instance, this makes traceroutes and logs list > potentially "wrong" names. Other times we are reminded that it is > perfectly natural to allow more than one PTR record in a set. Maybe > this is a "it's good for servers but not good for routers" situation. Hmm. Nobody mentioned PTR records in this discussion. I'm struggling to see how this matters. Is there a name server implementation that does reverse lookups of the IP addresses in a referral, compares them with the hostnames in the NS RRset and gets upset if there's a mismatch? > The part of the trade-off I haven't addressed is: > > The gain by using unique name server names for each delegation > > vs > > The need for extra IP addresses in light of a one name per address > policy This confuses me too Ed. AFAICT there is no one name per address policy. Even if this was the case for TLD delegations, we'd still only be talking about wasting around 4000 IPv4 addresses, assuming each TLD has around 20 NS records. There are plenty of far more blatant examples of wasteful usage of IPv4 address space: the /8s that Stanford and MIT have for instance. > Nevertheless, what I've debated above doesn't seem to be the point of > the document. It seems the document is presenting discomfort with the > response. I'm not sure that's right either. I read Olivier's document as an abridged history of what happened and where things stand today. People are of course welcome to interpret that document in whatever way best suits their standpoint. The questions about transparency and process at IANA remain unanswered though Doug has promised to respond to them. It looks like these questions won't go away until they are answered. IMO, it would be better to see them answered here instead of in a more formal setting such as an ICANN meeting. From bmanning at vacation.karoshi.com Tue Jun 7 02:50:33 2005 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 7 Jun 2005 00:50:33 +0000 Subject: [dns-wg] TLD delegation trade-offs In-Reply-To: <914b20e5eb880a39b62af3a485a82719@rfc1035.com> References: <42A4520E.5070006@centr.org> <914b20e5eb880a39b62af3a485a82719@rfc1035.com> Message-ID: <20050607005033.GA17743@vacation.karoshi.com.> > of wasteful usage of IPv4 address space: the /8s that Stanford and MIT > have for instance. er... MIT & MERIT... stanford returned theirs years ago... now if i understood Ed, both he and you are tangentially arguing for in-baliwick glue. why was this considered such bad practice last decade, but now seems to be not only prefered but the only choice for right-thinking people? --bill From Mohsen.Souissi at nic.fr Tue Jun 7 10:20:13 2005 From: Mohsen.Souissi at nic.fr (Mohsen Souissi) Date: Tue, 7 Jun 2005 10:20:13 +0200 Subject: [dns-wg] TLD delegation trade-offs In-Reply-To: <20050607005033.GA17743@vacation.karoshi.com.> References: <42A4520E.5070006@centr.org> <914b20e5eb880a39b62af3a485a82719@rfc1035.com> <20050607005033.GA17743@vacation.karoshi.com.> Message-ID: <20050607082013.GA32253@kerkenna.nic.fr> Bill & all, On 07 Jun, bmanning at vacation.karoshi.com wrote: | > of wasteful usage of IPv4 address space: the /8s that Stanford and MIT | > have for instance. | | er... MIT & MERIT... stanford returned theirs years ago... | | now if i understood Ed, both he and you are tangentially | arguing for in-baliwick glue. why was this considered such | bad practice last decade, but now seems to be not only | prefered but the only choice for right-thinking people? ==> I don't think anybody expressed the "in-baliwick glue" as "the only choice for right-thinking people" nor do I think that anybody was trying to show people how to "right-think" about NS's naming for a TLD delegation... The name compression technique which maybe was considered as "a bad practice" a decade ago has become more popular for the last 3-5 years. Btw I don't think this technique is "outdated" today as Ed said since the alternative he mentioned (Anycast) is not widely deployed yet by TLDs (only a few TLDs are anycast today and still some political and technical issues to be solved... Just think for instance at IPv6 allocation policy which does't allow yet TLDs in the RIPE region to get an "unfiltered" block... Yes I know, a new proposal is underway to be adopted by the RIPE address-policy wg...). IMHO, the name compression popularity relies on two facts today: - it addresses and mitigates new technical issues which didn't use to occurr frequently a decade ago, such as riskk of glue dropping due to new "greedy" RRs such as AAAA or DNSSEC-related RRs. So compression may save a large amount of bytes which may be transformed in a new NS deployment (icluding its A/AAAA glues); - TLDs which are not yet deploying DNS anycast are endeavouring to get a suitable level of redundancy and load distribution among their deployed NS's. As the number of deployed NS's grows, it becomes very practical and interesting to have a naming plan easing the readability and consequently the operation of name service... Hence, it is seen by a number of TLDs today that name compression is a good and workable technique, in the absence of a better technique (yet to be easily deployable)... Cheers, Mohsen. From roy at dnss.ec Tue Jun 7 10:30:28 2005 From: roy at dnss.ec (Roy Arends) Date: Tue, 7 Jun 2005 10:30:28 +0200 (CEST) Subject: [dns-wg] TLD delegation trade-offs In-Reply-To: <20050607082013.GA32253@kerkenna.nic.fr> References: <42A4520E.5070006@centr.org> <914b20e5eb880a39b62af3a485a82719@rfc1035.com> <20050607005033.GA17743@vacation.karoshi.com.> <20050607082013.GA32253@kerkenna.nic.fr> Message-ID: On Tue, 7 Jun 2005, Mohsen Souissi wrote: > Bill & all, > > On 07 Jun, bmanning at vacation.karoshi.com wrote: > | > of wasteful usage of IPv4 address space: the /8s that Stanford and MIT > | > have for instance. > | > | er... MIT & MERIT... stanford returned theirs years ago... > | > | now if i understood Ed, both he and you are tangentially > | arguing for in-baliwick glue. why was this considered such > | bad practice last decade, but now seems to be not only > | prefered but the only choice for right-thinking people? > > ==> I don't think anybody expressed the "in-baliwick glue" as "the > only choice for right-thinking people" nor do I think that anybody was > trying to show people how to "right-think" about NS's naming for a > TLD delegation... > > The name compression technique which maybe was considered as "a bad > practice" a decade ago has become more popular for the last 3-5 > years. Btw I don't think this technique is "outdated" today as Ed said > since the alternative he mentioned (Anycast) is not widely deployed > yet by TLDs (only a few TLDs are anycast today and still some > political and technical issues to be solved... Just think for instance > at IPv6 allocation policy which does't allow yet TLDs in the RIPE > region to get an "unfiltered" block... Yes I know, a new proposal is > underway to be adopted by the RIPE address-policy wg...). IMHO, the > name compression popularity relies on two facts today: > > - it addresses and mitigates new technical issues which didn't use to > occurr frequently a decade ago, such as riskk of glue dropping due > to new "greedy" RRs such as AAAA or DNSSEC-related RRs. So > compression may save a large amount of bytes which may be > transformed in a new NS deployment (icluding its A/AAAA glues); > > - TLDs which are not yet deploying DNS anycast are endeavouring to get > a suitable level of redundancy and load distribution among their > deployed NS's. As the number of deployed NS's grows, it becomes very > practical and interesting to have a naming plan easing the > readability and consequently the operation of name service... > > Hence, it is seen by a number of TLDs today that name compression is a > good and workable technique, in the absence of a better technique (yet > to be easily deployable)... Just my .02 euro: Using glue (or to use a redundant term: in-bailiwick glue) helps to avoid dependency loops as well. ie: example.com nameservers exist under example.net and vice versa. IMHO a good thing. Roy From pk at DENIC.DE Tue Jun 7 10:58:29 2005 From: pk at DENIC.DE (Peter Koch) Date: Tue, 7 Jun 2005 10:58:29 +0200 Subject: [dns-wg] TLD delegation trade-offs In-Reply-To: <914b20e5eb880a39b62af3a485a82719@rfc1035.com> References: <42A4520E.5070006@centr.org> <914b20e5eb880a39b62af3a485a82719@rfc1035.com> Message-ID: <20050607085829.GD10069@denics7.denic.de> Jim Reid wrote: > Ed, I'm not sure I understand the second part of your trade-off. The > benefits of better label compression and streamlined names seem clear well, I do understand "better label copmpression" but I don't understand "streamlined names". What's the real benefit of those? > there's an increased likelihood of not getting all the glue in a > referral response with that approach. Or have I missed something? I It comes back to the question for what reason the ROOT applies a wide glue policy as opposed to a narrow one which many TLDs do. > about what name (singular) should be returned for the address of some > TLD server. The operator of that server will care of course, but why > would anyone or anything else even need to care? We know that multiple PTRs are protocolly correct but don't work well in practice, i.e. they give intermittent results. That's also about consistency and setting examples. > was ubiquitous, I'd prefer to see NS RRsets use a clean set of target > names. It's prettier. And it reduces the protocol overheads: fewer CPU "prettier"? Name servers are objects in the DNS which are pointed at due to their special function. Just using their names as "aliases" to some address misses the point. Why not get rid of these domain names in the NS RDATA and point to IP addresses directly (sounds familiar, eh)? > name servers for some TLD across .tld0, .tld1, ... .tld7? And how does > the extra space needed for these names not "count against the glue > space hit" in a referral? All "glue" is equal, but some "glue" is more equal than other. And yes, it's additional info, not "glue". > see how this matters. Is there a name server implementation that does > reverse lookups of the IP addresses in a referral, compares them with > the hostnames in the NS RRset and gets upset if there's a mismatch? There might be actual operators to confuse. > This confuses me too Ed. AFAICT there is no one name per address > policy. Even if this was the case for TLD delegations, we'd still only > be talking about wasting around 4000 IPv4 addresses, assuming each TLD So, why would all this new wisdom only apply to TLDs? -Peter From jim at rfc1035.com Tue Jun 7 12:13:42 2005 From: jim at rfc1035.com (Jim Reid) Date: Tue, 7 Jun 2005 11:13:42 +0100 Subject: [dns-wg] TLD delegation trade-offs In-Reply-To: <20050607085829.GD10069@denics7.denic.de> References: <42A4520E.5070006@centr.org> <914b20e5eb880a39b62af3a485a82719@rfc1035.com> <20050607085829.GD10069@denics7.denic.de> Message-ID: <149040aeaa5756f4c6b1e9777167bb3d@rfc1035.com> On Jun 7, 2005, at 09:58, Peter Koch wrote: > Name servers are objects in the DNS which are pointed at due > to their special function. Just using their names as "aliases" to some > address misses the point. Please explain what point is being missed Peter. The ability to have these "aliases" is valuable. For example, when I renamed the *host* that was the master server for rfc1035.com I didn't have to change the delegation. This pointed at ns0.rfc1035.com which was and is an A record for the zone's master server. Name service for the zone remained at the same IP address but the name of the box providing that service changed. >> This confuses me too Ed. AFAICT there is no one name per address >> policy. Even if this was the case for TLD delegations, we'd still only >> be talking about wasting around 4000 IPv4 addresses, assuming each TLD > > So, why would all this new wisdom only apply to TLDs? Because that was the initial context of the discussion! There appeared to be a policy at IANA of one hostname per IP address in the root zone. It's clearly unworkable to insist on there being exactly one hostname for an IP address. There should of course be one PTR record per IP address, but that's an entirely different discussion. From Ed.Lewis at neustar.biz Tue Jun 7 17:03:48 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Tue, 7 Jun 2005 11:03:48 -0400 Subject: [dns-wg] TLD delegation trade-offs In-Reply-To: <914b20e5eb880a39b62af3a485a82719@rfc1035.com> References: <42A4520E.5070006@centr.org> <914b20e5eb880a39b62af3a485a82719@rfc1035.com> Message-ID: There are quite a few message to respond in the thread, I'll stick to questions indicating that my comments need clarification... At 0:45 +0100 6/7/05, Jim Reid wrote: >On Jun 6, 2005, at 22:00, Edward Lewis wrote: > >> What I find interesting is the trade-off of: >> >> The gain in packet compression by using similar names plus the >>operational advantage of streamlining the names >> >> vs >> >> The gain by spreading name server names under other TLDs plus the logging >>convenience of only needing one PTR record per address > >Ed, I'm not sure I understand the second part of your trade-off. The benefits >of better label compression and streamlined names seem clear enough. Spreading >name server names under other TLDs appears unwise: there's an increased >likelihood of not getting all the glue in a referral response with that >approach. Or have I missed something? I note Neustar doesn't spread the TLD NS >RRsets for .biz and .us like that. :-) And as for reverse lookups, I doubt >anybody or anything cares about what name (singular) should be returned for >the address of some TLD server. The operator of that server will care of >course, but why would anyone or anything else even need to care? Let's say my TLD is "tld", that my two options for name server sets are {a.nic.tld, b.nic.tld} and {a.nic.example, b.nic.tld}, and the query is for "www.jim.tld A". With option 1, if the query goes to the root and the iterative resolver is BIND, the queries for the addresses of a.nic.tld and b.nic.tld will follow. If there is a problem with the tld zone, and perhaps the glue at the root isn't completely right, we will have problems. With option 2, a problem with the tld zone isn't an issue if the copy of the zone on a.nic.example is in good enough condition. In summary, by using a different TLD, there's one more place to get the address of a name server. It could be that the fault that makes this a true advantage has almost no chance of happening in isolation. My supposition that spreading name servers among domains is based on watching how BIND does its resolution (via packet sniffing). I don't have access to other (popular) implementations to see how they go about their business. As you descend the tree, it's clearer than spreading name servers among domains (even different tlds) has a benefit. Because there are more moving parts as you descend the tree, there's more chance something goes wrong, so you want to build in resiliency. I can see that in the case of TLDs, there really aren't many options in case of a some failures. And, as far as what I call glue space savings isn't seen in the root zone as all name servers are in the root domain. Given that BIND chases the authoritative version of the glue it receives, and that there are a lot of BIND name servers (if not a majority), I think there's a gain in spreading the name servers over different TLDs. NeuStar's name servers are all in the same TLD. Internally, well, we just haven't seen a justification for trying "something new." It's like this, it works as is, its an industry norm, and tinkering with operational systems should not be taken lightly. I'd say that I have a hunch that there is a gain to mixing name servers over TLDs, and this is based on my thoughts about how enterprises should think. Hunches are not always right. (Recall I'm writing as an individual, not a company representative.) As far as reverse lookups - I think there are a lot of folks who do care. I've seen the issue more with routing discussions, traceroute is often cited as a tool that cares what it sees in the PTR record. Security analysis too - they rely on logging data. >> 1) Compression to insert more name servers or more glue records into a >>response is an advantage that I think is becoming outdated. > >With EDNS0 out there, I tend to agree. But there are lots of name servers >deployed that don't and won't support EDNS0. And even if EDNS0 was ubiquitous, >I'd prefer to see NS RRsets use a clean set of target names. It's prettier. >And it reduces the protocol overheads: fewer CPU cycles encoding/decoding DNS >packets as well as saving precious bytes we're going to need for DNSSEC >RRtypes. :-) Even with EDNS0. :-( I wasn't even considering EDNS0. I was thinking anycast. EDNS0 is good, but some non-DNS security devices still don't understand it. That needs fixing, and is out of scope for the thread and wg. I don't see how CPU cycles are reduced by using "a clean set" of names. A label pointer reference is the same, regardless of where it goes. >> 3) I would think that having servers listed under other TLDs (as we are >>looking at a ccTLD here) would be a good thing. Just for the fact that we >>are spreading the servers about (in DNS, not just topology). In addition, >>these servers don't count against the glue space hit in the response. > >Could you please expand on this Ed? There are things I simply do not >understand >here. What's gained by spreading the hostnames for 8 (say) name servers for >some TLD across .tld0, .tld1, ... .tld7? And how does the extra space needed >for these names not "count against the glue space hit" in a referral? Going back to my fictional tld above and the two options, here is what the root can minimally send back: option 1 answer: authority: tld NS a.nic.tld tld NS b.nic.tld additional: a.nic.tld A 1.1.1.1 b.nic.tld AAAA ::1 option 2 answer: authority: tld NS a.nic.example tld NS b.nic.tld additional: b.nic.tld AAAA ::1 The reason I say these are minimal is that any query for the records in the additional section would wind up with the same answer. In option 2, the next query to the root would be for "a.nic.example A" (and AAAA) from a BIND resolver. The response to that would be a referral to the example TLD servers. In option 2, the out-of-baliwick server does not count the needed glue. Of course, in reality, the root server is probably responding with it, as the server is under the root domain. Perhaps I am seeing a gain that is possible, but is not realized in practice because of the tools we are using and are used to. >Hmm. Nobody mentioned PTR records in this discussion. I'm struggling to see >how this matters. Is there a name server implementation that does reverse >lookups of the IP addresses in a referral, compares them with the hostnames >in the NS RRset and gets upset if there's a mismatch? I thought that the main problem was that IANA wasn't permitting multiple hosts to point to one IP address. Back in prehistoric times, this restriction was also in place in .com and .net. I ran into this - and the technical glitch that caused the restriction was that the registry software couldn't support multiple PTRs in a set. My supposition was that this might have been the cause of concern with IANA - I can't imagine any other reason to be concerned. Besides (potentially) faulty registry software, the main reason why multiple PTR records in a set are denigrated by some is that application software generally assumes a host has only one name. (I think multiple PTRs are fine, I'm just relating the arguments levied against them.) My experience with one dynamically updating DHCP server would treat the forward and reverse differently. When it created a lease with a vanity name, it would add the vanity name to the forward, supplementing what was already there. When updating the reverse, it deleted all previous records and out in the PTR with the vanity name. This is an application problem, not a DNS one. The only time that the reverse of a name server has ever been called out is in some DNS checking packages. I don't know why it's an issue, but DNS set ups were graded on that. >> The part of the trade-off I haven't addressed is: >> >> The gain by using unique name server names for each delegation >> >> vs >> >> The need for extra IP addresses in light of a one name per address policy > >This confuses me too Ed. AFAICT there is no one name per address policy. Even >if this was the case for TLD delegations, we'd still only be talking about >wasting around 4000 IPv4 addresses, assuming each TLD has around 20 NS >records. There are plenty of far more blatant examples of wasteful usage of >IPv4 address space: the /8s that Stanford and MIT have for instance. During the RIPE NCC presentation in the WG at RIPE 50, I thought the criticism was that the slave server names using unique addresses was considered wasteful and ironic that an RIR was doing this. I thought that this was proposed in response to the "problems" with IANA as described in the draft. It could be that my wires are crossed. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From Ed.Lewis at neustar.biz Tue Jun 7 17:14:03 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Tue, 7 Jun 2005 11:14:03 -0400 Subject: [dns-wg] TLD delegation trade-offs In-Reply-To: <20050607005033.GA17743@vacation.karoshi.com.> References: <42A4520E.5070006@centr.org> <914b20e5eb880a39b62af3a485a82719@rfc1035.com> <20050607005033.GA17743@vacation.karoshi.com.> Message-ID: At 0:50 +0000 6/7/05, bmanning at vacation.karoshi.com wrote: >> of wasteful usage of IPv4 address space: the /8s that Stanford and MIT >> have for instance. > > er... MIT & MERIT... stanford returned theirs years ago... > > now if i understood Ed, both he and you are tangentially > arguing for in-baliwick glue. why was this considered such > bad practice last decade, but now seems to be not only > prefered but the only choice for right-thinking people? Perhaps looking at the workings of the tools we have today. I don't understand why glue in the reverse map is considered any more of a hit than glue in the forward tree. It is one less issue in the reverse map, but it has cost us by requiring crutches placed in the forward tree. The crutch I refer to I have written about in many places - the crutch is the hybrid "cache response/referral" you get in response, for example to this query: dig @f.gtld-servers.com figwort.arin.net a (Meant as an example only. Look at the flags, no RA, no AA, but ANCOUNT > 0 and the rest of the message looks like a referral.) This crutch will have to be removed for DNSSEC (or DNSSEC will have to bend around it). When the crutch is removed, antique name servers will start to fall over. Perhaps the above is worded too strongly, I mean it as a potential reason why there is a call for in-bailiwick glue. And maybe RFC 2181's introduction of credibility as a means to stop cache poisoning plays a role, as well as BIND's search for the authoritative addresses of name servers in spite of having the glue addresses. BTW - This presentation at NANOG 33 gives another angle on this. http://www.nanog.org/mtg-0501/minda.html I believe that the similar presentations have been made at IETF$last and RIPE50. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From bmanning at vacation.karoshi.com Tue Jun 7 17:47:43 2005 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 7 Jun 2005 15:47:43 +0000 Subject: [dns-wg] TLD delegation trade-offs In-Reply-To: References: <42A4520E.5070006@centr.org> <914b20e5eb880a39b62af3a485a82719@rfc1035.com> <20050607005033.GA17743@vacation.karoshi.com.> Message-ID: <20050607154743.GB20549@vacation.karoshi.com.> > > now if i understood Ed, both he and you are tangentially > > arguing for in-baliwick glue. why was this considered such > > bad practice last decade, but now seems to be not only > > prefered but the only choice for right-thinking people? > > dig @f.gtld-servers.com figwort.arin.net a > > (Meant as an example only. Look at the flags, no RA, no AA, but > ANCOUNT > 0 and the rest of the message looks like a referral.) > > This crutch will have to be removed for DNSSEC (or DNSSEC will have > to bend around it). When the crutch is removed, antique name servers > will start to fall over. just for grins... how would DNSSEC "bend" around this supporting girder (or crutch if you prefer). > Edward Lewis +1-571-434-5468 --bill From Ed.Lewis at neustar.biz Tue Jun 7 17:50:39 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Tue, 7 Jun 2005 11:50:39 -0400 Subject: [dns-wg] TLD delegation trade-offs In-Reply-To: <20050607154743.GB20549@vacation.karoshi.com.> References: <42A4520E.5070006@centr.org> <914b20e5eb880a39b62af3a485a82719@rfc1035.com> <20050607005033.GA17743@vacation.karoshi.com.> <20050607154743.GB20549@vacation.karoshi.com.> Message-ID: At 15:47 +0000 6/7/05, bmanning at vacation.karoshi.com wrote: > just for grins... how would DNSSEC "bend" around this > supporting girder (or crutch if you prefer). Having to know not to give up when seeing an unsigned answer coming from a cache, treating this as a referral message and not a bogus message. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From bmanning at vacation.karoshi.com Tue Jun 7 17:55:30 2005 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 7 Jun 2005 15:55:30 +0000 Subject: [dns-wg] TLD delegation trade-offs In-Reply-To: References: <42A4520E.5070006@centr.org> <914b20e5eb880a39b62af3a485a82719@rfc1035.com> <20050607005033.GA17743@vacation.karoshi.com.> <20050607154743.GB20549@vacation.karoshi.com.> Message-ID: <20050607155530.GC20549@vacation.karoshi.com.> On Tue, Jun 07, 2005 at 11:50:39AM -0400, Edward Lewis wrote: > At 15:47 +0000 6/7/05, bmanning at vacation.karoshi.com wrote: > > > just for grins... how would DNSSEC "bend" around this > > supporting girder (or crutch if you prefer). > > Having to know not to give up when seeing an unsigned answer coming > from a cache, treating this as a referral message and not a bogus so... get back the unsigned rrset (glue) - then treat as a referal & attempt to validate down its delegation chain...??? --bill From Ed.Lewis at neustar.biz Tue Jun 7 17:55:42 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Tue, 7 Jun 2005 11:55:42 -0400 Subject: [dns-wg] TLD delegation trade-offs In-Reply-To: <20050607082013.GA32253@kerkenna.nic.fr> References: <42A4520E.5070006@centr.org> <914b20e5eb880a39b62af3a485a82719@rfc1035.com> <20050607005033.GA17743@vacation.karoshi.com.> <20050607082013.GA32253@kerkenna.nic.fr> Message-ID: At 10:20 +0200 6/7/05, Mohsen Souissi wrote: >years. Btw I don't think this technique is "outdated" today as Ed said >since the alternative he mentioned (Anycast) is not widely deployed >yet by TLDs (only a few TLDs are anycast today and still some >political and technical issues to be solved... Just think for instance >at IPv6 allocation policy which does't allow yet TLDs in the RIPE >region to get an "unfiltered" block... Yes I know, a new proposal is >underway to be adopted by the RIPE address-policy wg...). IMHO, the >name compression popularity relies on two facts today: I would say the concerns are outdated as far as protocol considerations, but I do agree that there are some bureaucratic road blocks that it still helps you get around. My answer to that though is to remove the bureaucratic road blocks. >- it addresses and mitigates new technical issues which didn't use to > occurr frequently a decade ago, such as riskk of glue dropping due > to new "greedy" RRs such as AAAA or DNSSEC-related RRs. So > compression may save a large amount of bytes which may be > transformed in a new NS deployment (icluding its A/AAAA glues); One AAAA record, with a compressed owner name would need, what 12+128/8=28 bytes. If all of the nameservers were named [a-f].nic.fr, then you would need to compress 4 name servers names for each additional AAAA record you could squeeze in. (That's 4 label compressions saving the "nic.fr." portion.) An RRSIG is, for .fr as signer name, going to need 12+22+1024/8 (assuming RSA 1024). That's about 40 name compressions needed. Now, I suppose that the savings calculation I am presenting isn't completely accurate and am willing to go back and do a more realistic calculation for a particular TLD and proposed naming system to see if the numbers are right. The point I am trying to make is that name compression savings pale in comparison to the size of the records we are looking to add. (Note, for DNSSEC, EDNS0 is required...further muddying the debate.) > >- TLDs which are not yet deploying DNS anycast are endeavouring to get > a suitable level of redundancy and load distribution among their > deployed NS's. As the number of deployed NS's grows, it becomes very > practical and interesting to have a naming plan easing the > readability and consequently the operation of name service... I'll yield to the point that (learning) anycast is a challenge in operations. But in the long run, it will be more powerful than trying to shave bytes here and there. >Hence, it is seen by a number of TLDs today that name compression is a >good and workable technique, in the absence of a better technique (yet >to be easily deployable)... "Today" yes. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From Ed.Lewis at neustar.biz Tue Jun 7 18:03:37 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Tue, 7 Jun 2005 12:03:37 -0400 Subject: [dns-wg] TLD delegation trade-offs In-Reply-To: <20050607085829.GD10069@denics7.denic.de> References: <42A4520E.5070006@centr.org> <914b20e5eb880a39b62af3a485a82719@rfc1035.com> <20050607085829.GD10069@denics7.denic.de> Message-ID: At 10:58 +0200 6/7/05, Peter Koch wrote: >Jim Reid wrote: > >> Ed, I'm not sure I understand the second part of your trade-off. The >> benefits of better label compression and streamlined names seem clear > >well, I do understand "better label copmpression" but I don't understand >"streamlined names". What's the real benefit of those? Name the 13 root servers. Now lookup the servers for (say) .ba and try to memorize them. Come back in an hour and name them. That's the difference between streamlined naming and not. Trite, I know. "Streamlined" just refers to being able to easily enumerate them on a moment's notice, which may be important during an operations maneuver. >"prettier"? Name servers are objects in the DNS which are pointed at due >to their special function. Just using their names as "aliases" to some >address misses the point. Why not get rid of these domain names in the >NS RDATA and point to IP addresses directly (sounds familiar, eh)? There are some places where "looks" and "optics" are important - these places are usually not found very close to machine rooms and telco demarcs. ;) Why not point to IP addresses? For flexibility. When I want to renumber a name server, there's no need to update the parent's NS copy of my set. (Kinda like the DNSSEC need for the DS record.) >There might be actual operators to confuse. Hmmm, gratuitous cynical remark withheld. ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From Ed.Lewis at neustar.biz Tue Jun 7 18:06:13 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Tue, 7 Jun 2005 12:06:13 -0400 Subject: [dns-wg] TLD delegation trade-offs In-Reply-To: <20050607155530.GC20549@vacation.karoshi.com.> References: <42A4520E.5070006@centr.org> <914b20e5eb880a39b62af3a485a82719@rfc1035.com> <20050607005033.GA17743@vacation.karoshi.com.> <20050607154743.GB20549@vacation.karoshi.com.> <20050607155530.GC20549@vacation.karoshi.com.> Message-ID: At 15:55 +0000 6/7/05, bmanning at vacation.karoshi.com wrote: >On Tue, Jun 07, 2005 at 11:50:39AM -0400, Edward Lewis wrote: >> At 15:47 +0000 6/7/05, bmanning at vacation.karoshi.com wrote: >> >> > just for grins... how would DNSSEC "bend" around this >> > supporting girder (or crutch if you prefer). >> >> Having to know not to give up when seeing an unsigned answer coming >> from a cache, treating this as a referral message and not a bogus > > so... get back the unsigned rrset (glue) - then treat > as a referal & attempt to validate down its delegation chain...??? A validator would need to know to do this. Look at the reply to the dig I suggested. Is it a reply? Is it a referral? If I recall correctly, BIND treats it as a reply and ceases the iteration, caching the answer as a less credible piece of data than had the AA bit been turned on. My point is, if the resolver sees this and judges it to be a reply, instead of tossing it and trying the query again the resolver needs to slip this into the "it's a referral" queue. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From Ed.Lewis at neustar.biz Tue Jun 7 18:09:00 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Tue, 7 Jun 2005 12:09:00 -0400 Subject: [dns-wg] TLD delegation trade-offs In-Reply-To: <149040aeaa5756f4c6b1e9777167bb3d@rfc1035.com> References: <42A4520E.5070006@centr.org> <914b20e5eb880a39b62af3a485a82719@rfc1035.com> <20050607085829.GD10069@denics7.denic.de> <149040aeaa5756f4c6b1e9777167bb3d@rfc1035.com> Message-ID: At 11:13 +0100 6/7/05, Jim Reid wrote: >Because that was the initial context of the discussion! There appeared to be a >policy at IANA of one hostname per IP address in the root zone. It's clearly >unworkable to insist on there being exactly one hostname for an IP address. >There should of course be one PTR record per IP address, but that's an >entirely different discussion. I don't see the discussions as different. The rationale for the one address per name I once ran into was because they had to limit PTRs to one per address. If you allow multiple names to one address, what do you put in the PTR record that will yield meaningful results in logs? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From Ed.Lewis at neustar.biz Tue Jun 7 18:11:40 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Tue, 7 Jun 2005 12:11:40 -0400 Subject: [dns-wg] 6 replies to one thread in a day In-Reply-To: References: <42A4520E.5070006@centr.org> <914b20e5eb880a39b62af3a485a82719@rfc1035.com> <20050607005033.GA17743@vacation.karoshi.com.> <20050607154743.GB20549@vacation.karoshi.com.> <20050607155530.GC20549@vacation.karoshi.com.> Message-ID: An apology in advance, well, err, umm. I raised a lot of apparently disjointed arguments and couldn't figure out a better way to answer the detail questions. (Some lists consider it rude to answer so many times to one thread in one day.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From jim at rfc1035.com Tue Jun 7 18:49:12 2005 From: jim at rfc1035.com (Jim Reid) Date: Tue, 7 Jun 2005 17:49:12 +0100 Subject: [dns-wg] TLD delegation trade-offs In-Reply-To: References: <42A4520E.5070006@centr.org> <914b20e5eb880a39b62af3a485a82719@rfc1035.com> <20050607085829.GD10069@denics7.denic.de> <149040aeaa5756f4c6b1e9777167bb3d@rfc1035.com> Message-ID: > If you allow multiple names to one address, what do you put in the PTR > record that will yield meaningful results in logs? Well I personally make sure PTR records always return the canonical name of the host and nothing else, no matter how many A or AAAA records exist for that IP address. From bmanning at vacation.karoshi.com Tue Jun 7 19:04:28 2005 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 7 Jun 2005 17:04:28 +0000 Subject: [dns-wg] TLD delegation trade-offs In-Reply-To: References: <42A4520E.5070006@centr.org> <914b20e5eb880a39b62af3a485a82719@rfc1035.com> <20050607085829.GD10069@denics7.denic.de> <149040aeaa5756f4c6b1e9777167bb3d@rfc1035.com> Message-ID: <20050607170428.GJ20549@vacation.karoshi.com.> On Tue, Jun 07, 2005 at 05:49:12PM +0100, Jim Reid wrote: > >If you allow multiple names to one address, what do you put in the PTR > >record that will yield meaningful results in logs? > > Well I personally make sure PTR records always return the canonical > name of the host and nothing else, no matter how many A or AAAA records > exist for that IP address. for "fun" - some folks rotate the various canonical names that exist for any given A or AAAA or (for difficult types) A6 records that exist. and Jim, you confuse me. posit: twinkle.little.bat. AAAA 3ffe::dead:beef muffet.satona.tuffit. aaaa 3ffe::dead:beef PDC.e164.arpa. AAAA 3ffe::dead:beef which is THE canonical lable for the address 3ffe::dead:beef ?? --bill From jim at rfc1035.com Tue Jun 7 20:17:47 2005 From: jim at rfc1035.com (Jim Reid) Date: Tue, 7 Jun 2005 19:17:47 +0100 Subject: [dns-wg] TLD delegation trade-offs In-Reply-To: <20050607170428.GJ20549@vacation.karoshi.com.> References: <42A4520E.5070006@centr.org> <914b20e5eb880a39b62af3a485a82719@rfc1035.com> <20050607085829.GD10069@denics7.denic.de> <149040aeaa5756f4c6b1e9777167bb3d@rfc1035.com> <20050607170428.GJ20549@vacation.karoshi.com.> Message-ID: On Jun 7, 2005, at 18:04, bmanning at vacation.karoshi.com wrote: > for "fun" - some folks rotate the various canonical names > that exist for any given A or AAAA or (for difficult types) > A6 records that exist. > > and Jim, you confuse me. Mission accomplished! :-) > posit: > > twinkle.little.bat. AAAA 3ffe::dead:beef > muffet.satona.tuffit. aaaa 3ffe::dead:beef > PDC.e164.arpa. AAAA 3ffe::dead:beef > > which is THE canonical lable for the address 3ffe::dead:beef ?? I dunno. It'll be whatever one you've decided will be the canonical label today. After all you did say you rotated them for fun.... From doug.barton at icann.org Tue Jun 7 20:48:47 2005 From: doug.barton at icann.org (Doug Barton) Date: Tue, 07 Jun 2005 11:48:47 -0700 Subject: [dns-wg] Followup to IANA TLD delegation problem In-Reply-To: <22874.1118056416@shaun.rfc1035.com> References: <22874.1118056416@shaun.rfc1035.com> Message-ID: <42A5EC0F.9010909@icann.org> Thanks for confirming this Jim. We will have the answers to you by the end of this week. Regards, Doug -- Doug Barton General Manager, The Internet Assigned Numbers Authority Jim Reid wrote: >>>>>>"Doug" == Doug Barton writes: > > > Doug> Jim, We're happy to provide answers to these > Doug> questions. Given that Monday is a holiday in the US, may I > Doug> suggest that we will provide answers to the questions listed > Doug> on Tuesday 31 May unless you or the WG indicate that more > Doug> time is needed for you to formulate the list? > > Hi Doug. You'll have seen that there's been no detailed discussion in > the last week or so on the mailing list about this issue. Most of the > comments have seemed to echo the questions that were in my earlier > mail. Assuming that you're back from paternity leave, I think it would > now be helpful for these questions to be answered. This would allow us > to finally resolve this issue and hopefully prevent it flaring up > again in some other forum. > > Here are those questions once again: > > [1] What was the nature of the technical problem that prevented > multiple names in for an IP address and how was it resolved? > > [2] Why was there no announcement that this problem existed? > > [3] Are safeguards now in place to prevent this sort of problem recurring? > > [4] What procedures does IANA (or ICANN?) have to make sure that changes > to the TLD delegation process or problems with that process are properly > communicated to its stakeholders? > > [5] Were those procedures followed for this incident? If not, why not? From Mohsen.Souissi at nic.fr Wed Jun 8 00:04:31 2005 From: Mohsen.Souissi at nic.fr (Mohsen Souissi) Date: Wed, 8 Jun 2005 00:04:31 +0200 Subject: [dns-wg] TLD delegation trade-offs In-Reply-To: References: <42A4520E.5070006@centr.org> <914b20e5eb880a39b62af3a485a82719@rfc1035.com> <20050607005033.GA17743@vacation.karoshi.com.> <20050607082013.GA32253@kerkenna.nic.fr> Message-ID: <20050607220431.GA2243@kerkenna.nic.fr> On 07 Jun, Edward Lewis wrote: | At 10:20 +0200 6/7/05, Mohsen Souissi wrote: | | >years. Btw I don't think this technique is "outdated" today as Ed said | >since the alternative he mentioned (Anycast) is not widely deployed | >yet by TLDs (only a few TLDs are anycast today and still some | >political and technical issues to be solved... Just think for instance | >at IPv6 allocation policy which does't allow yet TLDs in the RIPE | >region to get an "unfiltered" block... Yes I know, a new proposal is | >underway to be adopted by the RIPE address-policy wg...). IMHO, the | >name compression popularity relies on two facts today: | | I would say the concerns are outdated as far as protocol | considerations, but I do agree that there are some bureaucratic road | blocks that it still helps you get around. | | My answer to that though is to remove the bureaucratic road blocks. ==> May the Force be with us... | >- it addresses and mitigates new technical issues which didn't use to | > occurr frequently a decade ago, such as riskk of glue dropping due | > to new "greedy" RRs such as AAAA or DNSSEC-related RRs. So | > compression may save a large amount of bytes which may be | > transformed in a new NS deployment (icluding its A/AAAA glues); | | One AAAA record, with a compressed owner name would need, what | 12+128/8=28 bytes. If all of the nameservers were named | [a-f].nic.fr, then you would need to compress 4 name servers names | for each additional AAAA record you could squeeze in. (That's 4 | label compressions saving the "nic.fr." portion.) | | An RRSIG is, for .fr as signer name, going to need 12+22+1024/8 | (assuming RSA 1024). That's about 40 name compressions needed. | | Now, I suppose that the savings calculation I am presenting isn't | completely accurate and am willing to go back and do a more realistic | calculation for a particular TLD and proposed naming system to see if | the numbers are right. | | The point I am trying to make is that name | compression savings pale in comparison to the size of the records we | are looking to add. (Note, for DNSSEC, EDNS0 is required...further | muddying the debate.) ==> If it can help, I have already written a technical document containing accurate calculations of the root-servers' DNS response size for a TLD in the general case and for FR particularly, with and without IPv6 glue: http://w6.nic.fr/dnsv6/resp-size.html Btw, thanks to that article, FR was able to safely submit 3 glue AAAA to the root zone... Otoh, I agree with you, DNSSEC requires anyway EDNS.0 and it's pointless squeezing names because saved room is anyway too small compared to the required space... Mohsen. From Niall.oReilly at ucd.ie Fri Jun 10 12:00:54 2005 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Fri, 10 Jun 2005 11:00:54 +0100 Subject: [dns-wg] TLD delegation trade-offs In-Reply-To: References: <42A4520E.5070006@centr.org> <914b20e5eb880a39b62af3a485a82719@rfc1035.com> Message-ID: <201dfe57fe2861b8f79e40ca3d18cf4f@ucd.ie> On 7 Jun 2005, at 16:03, Edward Lewis wrote: > As you descend the tree, it's clearer than spreading name servers > among domains (even different tlds) has a benefit. I'm reading that as "... clear that ..." rather than "... clearer than ...", as I can't make sense of it otherwise. I used to think so too, but I'm now convinced that this is not clear at all. I'm not saying it's necessarily untrue (or even true): just that it's not clear. > Because there are more moving parts as you descend the tree, there's > more chance something goes wrong, so you want to build in resiliency. Spreading name servers among domains _may_ give resiliency; it _certainly_ adds complexity and expands the repertoire of potential failure modes. There are more places where things can go wrong. If there are (perhaps hidden) interdependencies between these places, the overall impact of one particular thing going wrong may be far greater than expected. It all depends on having a strategy for placing your servers in well-managed parts both of the DNS tree and of the network topology. Of course, we all take care to have a strategy we can stand over, and to review it regularly! 8-) /Niall From Ed.Lewis at neustar.biz Fri Jun 10 17:05:15 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Fri, 10 Jun 2005 11:05:15 -0400 Subject: [dns-wg] TLD delegation trade-offs In-Reply-To: <201dfe57fe2861b8f79e40ca3d18cf4f@ucd.ie> References: <42A4520E.5070006@centr.org> <914b20e5eb880a39b62af3a485a82719@rfc1035.com> <201dfe57fe2861b8f79e40ca3d18cf4f@ucd.ie> Message-ID: At 11:00 +0100 6/10/05, Niall O'Reilly wrote: >Spreading name servers among domains _may_ give resiliency; it _certainly_ >adds complexity and expands the repertoire of potential failure modes. >There are more places where things can go wrong. If there are (perhaps >hidden) interdependencies between these places, the overall impact of one >particular thing going wrong may be far greater than expected. It all >depends on having a strategy for placing your servers in well-managed parts >both of the DNS tree and of the network topology. > >Of course, we all take care to have a strategy we can stand over, >and to review it regularly! 8-) Yeah, there are more places for potential failures, but it's not like the extra failures that are realized will harm because, well, it's like a parallel circuit and not a serial circuit. You only need to find one (working) name server's address to get the data you need, you don't need to find all of them. As far as complexity - is it all that more complex than the alternative of "placing your servers in well-managed parts?" You do have more places to register host information (glue) and that is more complex. But what is the complexity of determining the "well-managed parts?" ;) I think this is coming down to a realization of "fate sharing." If all of a domain's name servers share the same fate - like all being on the same physical subnet or maybe tied to the same security association (like VPN) - than naming them consistently is no loss. OTOH, if the fates are diverse, like choosing two unrelated organizations to run slave servers for you, then tying the names together is the "fate-sharing" element that reduces the benefit of the diversity in slave servers. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From Niall.oReilly at ucd.ie Sat Jun 11 02:14:34 2005 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Sat, 11 Jun 2005 01:14:34 +0100 Subject: [dns-wg] TLD delegation trade-offs In-Reply-To: References: <42A4520E.5070006@centr.org> <914b20e5eb880a39b62af3a485a82719@rfc1035.com> <201dfe57fe2861b8f79e40ca3d18cf4f@ucd.ie> Message-ID: <0a1dd2adb074eec269f4de31bfaa9633@ucd.ie> On 10 Jun 2005, at 16:05, Edward Lewis wrote: > I think this is coming down to a realization of "fate sharing." [I haven't encountered that terminology before. I like it.] Yes, I think so too. /Niall From Niall.oReilly at ucd.ie Sat Jun 11 02:15:24 2005 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Sat, 11 Jun 2005 01:15:24 +0100 Subject: [dns-wg] TLD delegation trade-offs In-Reply-To: References: <42A4520E.5070006@centr.org> <914b20e5eb880a39b62af3a485a82719@rfc1035.com> <201dfe57fe2861b8f79e40ca3d18cf4f@ucd.ie> Message-ID: <7d7ebd0147eafb0694c08b3b28cbd8ac@ucd.ie> On 10 Jun 2005, at 16:05, Edward Lewis wrote: > is it all that more complex than the alternative It's a tradeoff, and the full picture is likely more elusive than one expects. It's not just about the technical components, but about organizational structure and such "layer 9" stuff. /Niall From doug.barton at icann.org Sat Jun 11 02:27:21 2005 From: doug.barton at icann.org (Doug Barton) Date: Fri, 10 Jun 2005 17:27:21 -0700 Subject: [dns-wg] Followup to IANA TLD delegation problem Message-ID: <42AA2FE9.8030308@icann.org> Jim, Thanks again for the opportunity to discuss these issues. I hope that the group finds these answers satisfactory. We are of course happy to discuss this in further detail if desired. [1] What was the nature of the technical problem that prevented multiple names in for an IP address and how was it resolved? In November of 2004 AFNIC asked to have several hostnames added to the root zone that resolved to the same IPv4 addresses as hostnames that already existed. When VeriSign edited the root zone to include these new names, an unexpected result occurred. In some of the TLDs that had the pre-existing hostnames for these servers, the new hostnames appeared in the delegations inappropriately. This problem was identified within several hours of the zone going live by VeriSign staff, as well as at least one member of the ccTLD community. The VeriSign and IANA staffs communicated immediately about this issue, and the specific problem related to this request was fixed manually by VeriSign in the next zone revision after it was identified. Because in any pair of hostnames affected by this result the IPv4 address was the same, the operational impact of this problem was minimal, if it was identifiable at all. [2] Why was there no announcement that this problem existed? The specific problem applied only to new instances of duplicate names, it did not affect existing duplicate names for which no change was in process. The total number of these duplicate hostnames is very small relative to the rest of the zone (less than 3%), and requests to modify domains which have these hostnames in their delegations are rare. There were no instances of such a request from November of 2004 through March of 2005, when AFNIC submitted the request for the RE ccTLD. Because the issue affected only a small number of TLDs and name server operators, IANA staff chose to address the issue with those individuals directly. Often TLD managers appreciate such specific cases being dealt with on a personal level. [3] Are safeguards now in place to prevent this sort of problem recurring? Yes. VeriSign has informed us that the general problem which produced the original unexpected result has now been corrected. Additionally, IANA staff have enhanced efforts to monitor the "live" root zone from several different servers, and use that data to proactively monitor the results of change requests. [4] What procedures does IANA (or ICANN?) have to make sure that changes to the TLD delegation process or problems with that process are properly communicated to its stakeholders? The procedure that IANA uses to communicate changes in the TLD delegation process follows the typical ICANN formula of involving key stakeholders at early stages, opening proposals up for public comment, incorporating appropriate comments into the final version, and posting the procedure for its stakeholders. A relevant example of this process is the "Delegation Data Procedure," which is posted at http://www.iana.org/procedures/delegation-data.html. Specific problems in the root management process are evaluated on a case by case basis. When necessary, there is a mailing list composed of the contact addresses for each of the TLD managers that can be utilized for any issue of wide interest to the TLD manager community. As noted above, cases which affect one, or a few TLDs are often dealt with on a one-to-one basis, with the appreciation of the relevant TLD manager(s). [5] Were those procedures followed for this incident? If not, why not? The procedure for communicating changes to the TLD delegation process was not followed in this specific case because there was no formal change of process. The specific problem which produced the delay in processing AFNIC's request for RE was always understood to be temporary. As discussed above, rather than widely disseminate the information about this issue to the TLD manager community, IANA staff chose to communicate directly with those affected by the issue. ICANN's goal, as always, is to cooperate with the TLD managers in implementing the changes they feel are appropriate for their TLDs, while also maintaining the stability of the DNS. We regret if our cautious handling of this particular request, or the timing of our responses to the group's reasonable questions, has caused any undue confusion in the DNS community about ICANN's dedication to that goal. We welcome comment and discussion on these topics. I am enclosing below some information about the current (at this writing, 2005061000) root zone that may be relevant to this discussion. The first part is the complete list of IPv4 addresses that have multiple hostnames associated. There are no IPv6 addresses with multiple hostnames. The second part is a compilation of statistics about the current zone. Regards, Doug 128.112.129.15: dns.princeton.edu c.ext.nic.fr 192.134.0.49: c.nic.fr ns3.nic.fr 192.36.144.116: slave.sth.netnod.se slave1.sth.netnod.se 192.93.0.1: a.nic.fr ns1.nic.fr 192.93.0.4: b.nic.fr ns2.nic.fr 193.176.144.6: e.ext.nic.fr ns3.domain-registry.nl 193.51.208.13: dns.inria.fr a.ext.nic.fr 204.152.184.64: ns-ext.vix.com ns-ext.isc.org 204.74.112.1: tld1.basicfusion.net tld1.ultradns.net ud1.ns.net.ua 204.74.113.1: tld2.basicfusion.net tld2.ultradns.net Statistics ========== Number of gTLDs: 15 Number of ccTLDs: 245 Total number of TLDs: 260 Number of IPv4 hosts: 798 Number of IPv4 addresses: 798 Number of IPv6 hosts: 40 Number of IPv6 addresses: 41 TLDs with IPv6 glue: 50 Total TLD name server hosts: 797 -- Doug Barton General Manager, The Internet Assigned Numbers Authority From Niall.oReilly at no8.be Sat Jun 11 02:06:38 2005 From: Niall.oReilly at no8.be (Niall O'Reilly) Date: Sat, 11 Jun 2005 01:06:38 +0100 Subject: [dns-wg] TLD delegation trade-offs In-Reply-To: References: <42A4520E.5070006@centr.org> <914b20e5eb880a39b62af3a485a82719@rfc1035.com> <201dfe57fe2861b8f79e40ca3d18cf4f@ucd.ie> Message-ID: On 10 Jun 2005, at 16:05, Edward Lewis wrote: > I think this is coming down to a realization of "fate sharing." [I haven't encountered that terminology before. I like it.] Yes, I think so too. /Niall From Niall.oReilly at no8.be Sat Jun 11 02:10:42 2005 From: Niall.oReilly at no8.be (Niall O'Reilly) Date: Sat, 11 Jun 2005 01:10:42 +0100 Subject: [dns-wg] TLD delegation trade-offs In-Reply-To: References: <42A4520E.5070006@centr.org> <914b20e5eb880a39b62af3a485a82719@rfc1035.com> <201dfe57fe2861b8f79e40ca3d18cf4f@ucd.ie> Message-ID: <5bd868bf88d1e6a3ef9fb4b45933cd9e@no8.be> On 10 Jun 2005, at 16:05, Edward Lewis wrote: > is it all that more complex than the alternative It's a tradeoff, and the full picture is likely more elusive than one expects. It's not just about the technical components, but about organizational structure and such "layer 9" stuff. /Niall From schneider at switch.ch Mon Jun 13 14:02:22 2005 From: schneider at switch.ch (Marcel Schneider) Date: Mon, 13 Jun 2005 14:02:22 +0200 Subject: [dns-wg] Followup to IANA TLD delegation problem In-Reply-To: Message from Doug Barton of "Fri, 10 Jun 2005 17:27:21 -0700." <42AA2FE9.8030308@icann.org> References: <42AA2FE9.8030308@icann.org> Message-ID: <25332.1118664142@switch.ch> On Friday, 10 Jun 2005, Doug Barton writes: Dear Doug Thanks for responding to Jim's questions. Reading your mail I still have difficulties understanding two issues: a) You state in [1] that after editing the root zone, VerSign experienced an "unexpected result". What exactly was the result what caused it ? Whould also appreciate if you could elaborate on how VerSign was able to fix this "unexpected result". b) When this "unexpected result" was regarded by IANA staff as temporary and as having minimal operational impact, why was AFNIC then sent this response to their application: "IANA is no longer adding additional examples of host names in delegation records where multiple host names point to the same IP address". The "no longer" suggests a policy change. Why did IANA not just say: "Folks we have a problem here, wait a moment until we've fixed it" ? Marcel > Thanks again for the opportunity to discuss these issues. I hope that the > group finds these answers satisfactory. We are of course happy to discuss > this in further detail if desired. > [1] What was the nature of the technical problem that prevented > multiple names in for an IP address and how was it resolved? > In November of 2004 AFNIC asked to have several hostnames added to the root > zone that resolved to the same IPv4 addresses as hostnames that already > existed. When VeriSign edited the root zone to include these new names, an > unexpected result occurred. In some of the TLDs that had the pre-existing > hostnames for these servers, the new hostnames appeared in the delegations > inappropriately. This problem was identified within several hours of the > zone going live by VeriSign staff, as well as at least one member of the > ccTLD community. The VeriSign and IANA staffs communicated immediately about > this issue, and the specific problem related to this request was fixed > manually by VeriSign in the next zone revision after it was identified. > Because in any pair of hostnames affected by this result the IPv4 address > was the same, the operational impact of this problem was minimal, if it was > identifiable at all. > [2] Why was there no announcement that this problem existed? > The specific problem applied only to new instances of duplicate names, it > did not affect existing duplicate names for which no change was in process. > The total number of these duplicate hostnames is very small relative to the > rest of the zone (less than 3%), and requests to modify domains which have > these hostnames in their delegations are rare. There were no instances of > such a request from November of 2004 through March of 2005, when AFNIC > submitted the request for the RE ccTLD. > Because the issue affected only a small number of TLDs and name server > operators, IANA staff chose to address the issue with those individuals > directly. Often TLD managers appreciate such specific cases being dealt with > on a personal level. > [3] Are safeguards now in place to prevent this sort of problem recurring? > Yes. VeriSign has informed us that the general problem which produced the > original unexpected result has now been corrected. Additionally, IANA staff > have enhanced efforts to monitor the "live" root zone from several different > servers, and use that data to proactively monitor the results of change > requests. > [4] What procedures does IANA (or ICANN?) have to make sure that changes > to the TLD delegation process or problems with that process are properly > communicated to its stakeholders? > The procedure that IANA uses to communicate changes in the TLD delegation > process follows the typical ICANN formula of involving key stakeholders at > early stages, opening proposals up for public comment, incorporating > appropriate comments into the final version, and posting the procedure for > its stakeholders. A relevant example of this process is the "Delegation Data > Procedure," which is posted at > http://www.iana.org/procedures/delegation-data.html. > Specific problems in the root management process are evaluated on a case by > case basis. When necessary, there is a mailing list composed of the contact > addresses for each of the TLD managers that can be utilized for any issue of > wide interest to the TLD manager community. As noted above, cases which > affect one, or a few TLDs are often dealt with on a one-to-one basis, with > the appreciation of the relevant TLD manager(s). > [5] Were those procedures followed for this incident? If not, why not? > The procedure for communicating changes to the TLD delegation process was > not followed in this specific case because there was no formal change of > process. > The specific problem which produced the delay in processing AFNIC's request > for RE was always understood to be temporary. As discussed above, rather > than widely disseminate the information about this issue to the TLD manager > community, IANA staff chose to communicate directly with those affected by > the issue. > ICANN's goal, as always, is to cooperate with the TLD managers in > implementing the changes they feel are appropriate for their TLDs, while > also maintaining the stability of the DNS. We regret if our cautious > handling of this particular request, or the timing of our responses to the > group's reasonable questions, has caused any undue confusion in the DNS > community about ICANN's dedication to that goal. We welcome comment and > discussion on these topics. > I am enclosing below some information about the current (at this writing, > 2005061000) root zone that may be relevant to this discussion. The first > part is the complete list of IPv4 addresses that have multiple hostnames > associated. There are no IPv6 addresses with multiple hostnames. The second > part is a compilation of statistics about the current zone. > Regards, > Doug > 128.112.129.15: dns.princeton.edu c.ext.nic.fr > 192.134.0.49: c.nic.fr ns3.nic.fr > 192.36.144.116: slave.sth.netnod.se slave1.sth.netnod.se > 192.93.0.1: a.nic.fr ns1.nic.fr > 192.93.0.4: b.nic.fr ns2.nic.fr > 193.176.144.6: e.ext.nic.fr ns3.domain-registry.nl > 193.51.208.13: dns.inria.fr a.ext.nic.fr > 204.152.184.64: ns-ext.vix.com ns-ext.isc.org > 204.74.112.1: tld1.basicfusion.net tld1.ultradns.net ud1.ns.net.ua > 204.74.113.1: tld2.basicfusion.net tld2.ultradns.net > Statistics > ========== > Number of gTLDs: 15 > Number of ccTLDs: 245 > Total number of TLDs: 260 > Number of IPv4 hosts: 798 > Number of IPv4 addresses: 798 > Number of IPv6 hosts: 40 > Number of IPv6 addresses: 41 > TLDs with IPv6 glue: 50 > Total TLD name server hosts: 797 > -- > Doug Barton > General Manager, The Internet Assigned Numbers Authority From jim at rfc1035.com Mon Jun 13 14:53:02 2005 From: jim at rfc1035.com (Jim Reid) Date: Mon, 13 Jun 2005 13:53:02 +0100 Subject: [dns-wg] Followup to IANA TLD delegation problem In-Reply-To: <42AA2FE9.8030308@icann.org> References: <42AA2FE9.8030308@icann.org> Message-ID: <76390676a30070a97b5ef83a7f4ee1bd@rfc1035.com> Doug, thank you very much for your detailed reply to the followup questions I asked on behalf of the WG. Speaking in a personal capacity, I think it would be helpful if IANA would consider a different course of action if an incident like this pops up again. Although there are all sorts of difficult value judgements to be made -- many of them political rather than technical -- it may be better to err on the side of openness and transparency. That reduces the potential for confusion. Or, in the context of this recent problem, it prevents the perception that some sort of policy change has been made behind closed doors. It's now up to the WG to respond to your reply Doug. If there are no substantive comments or questions in the next week or so, I suggest we consider this matter resolved. From pk at DENIC.DE Mon Jun 13 17:18:01 2005 From: pk at DENIC.DE (Peter Koch) Date: Mon, 13 Jun 2005 17:18:01 +0200 Subject: [dns-wg] TLD delegation trade-offs In-Reply-To: <149040aeaa5756f4c6b1e9777167bb3d@rfc1035.com> References: <42A4520E.5070006@centr.org> <914b20e5eb880a39b62af3a485a82719@rfc1035.com> <20050607085829.GD10069@denics7.denic.de> <149040aeaa5756f4c6b1e9777167bb3d@rfc1035.com> Message-ID: <20050613151801.GM21389@denics7.denic.de> Jim Reid wrote: > >to their special function. Just using their names as "aliases" to some > >address misses the point. > > Please explain what point is being missed Peter. The ability to have > these "aliases" is valuable. For example, when I renamed the *host* i didn't contest that. However, this is kinda "bit fiddling" and uses naming by function instead of by object. Had that been the intent there would be no need for names in the RDATA of an NS RR. IP addresses would be fine (well, the versioning became difficult, but anyway). > that was the master server for rfc1035.com I didn't have to change the > delegation. This pointed at ns0.rfc1035.com which was and is an A > record for the zone's master server. Name service for the zone remained > at the same IP address but the name of the box providing that service > changed. [...] > >So, why would all this new wisdom only apply to TLDs? > > Because that was the initial context of the discussion! There appeared This does not provide for a justification for such restriction. Your example above is for an SLD, not a TLD, by the way. So, I'm still not convinced that this "new scheme" is really a good or well scaling recommendation. > to be a policy at IANA of one hostname per IP address in the root zone. > It's clearly unworkable to insist on there being exactly one hostname Yes, but it doesn't mean one has to recommend to the contrary. -Peter From pk at DENIC.DE Mon Jun 13 17:29:42 2005 From: pk at DENIC.DE (Peter Koch) Date: Mon, 13 Jun 2005 17:29:42 +0200 Subject: [dns-wg] TLD delegation trade-offs In-Reply-To: References: <42A4520E.5070006@centr.org> <914b20e5eb880a39b62af3a485a82719@rfc1035.com> <20050607085829.GD10069@denics7.denic.de> Message-ID: <20050613152942.GN21389@denics7.denic.de> Edward Lewis wrote: > >well, I do understand "better label copmpression" but I don't understand > >"streamlined names". What's the real benefit of those? > > Name the 13 root servers. Now lookup the servers for (say) .ba and > try to memorize them. Come back in an hour and name them. hmm, I tried. I could remember A-M.root-servers.net but missed two of BA's servers. However, the only address I could recall was ns.ripe.net's, because it is so "pretty". Now, wouldn't that call for beautifying addresses? Seriously, a side effect of those efficienmt naming schemes is information hiding. > Why not point to IP addresses? For flexibility. When I want to > renumber a name server, there's no need to update the parent's NS > copy of my set. (Kinda like the DNSSEC need for the DS record.) So, Jim tells me that he likes to have dedicated names so he doesn't have to change the delegation once the server's name changes and you argue that renumbering is easier if just names are used (instead of IP adresses or, to the same extent, per-zone server names and their necessary glue records). I guess we can't have both. I'm with you. -Peter From jim at rfc1035.com Mon Jun 13 17:46:34 2005 From: jim at rfc1035.com (Jim Reid) Date: Mon, 13 Jun 2005 16:46:34 +0100 Subject: [dns-wg] TLD delegation trade-offs In-Reply-To: <20050613152942.GN21389@denics7.denic.de> References: <42A4520E.5070006@centr.org> <914b20e5eb880a39b62af3a485a82719@rfc1035.com> <20050607085829.GD10069@denics7.denic.de> <20050613152942.GN21389@denics7.denic.de> Message-ID: <147ffd1cb80a9e271b459d95c35a8bf0@rfc1035.com> On Jun 13, 2005, at 16:29, Peter Koch wrote: > Edward Lewis wrote: >> Why not point to IP addresses? For flexibility. When I want to >> renumber a name server, there's no need to update the parent's NS >> copy of my set. (Kinda like the DNSSEC need for the DS record.) > > So, Jim tells me that he likes to have dedicated names so he doesn't > have > to change the delegation once the server's name changes and you argue > that > renumbering is easier if just names are used (instead of IP adresses > or, > to the same extent, per-zone server names and their necessary glue > records). > I guess we can't have both. I'm with you. Shame! :-) Ed and I are both right. But one of us is more right than the other. :-) The answer depends to some extent on whether the target of an NS record is the actual host name for the box or not. For Ed's they are. For my zones and servers, they're not. They're "aliases" as I try to keep names for services separated from the names of the hosts that provide those services. That way I can change one without affecting the other. Now let me throw a spanner in the works: anycasting. There's a single A record for k.root-servers.net. But there are many instances of that IP address. I'd expect the NCC Ops people to have unique hostnames and IP addresses for each instance so they know which box to SSH to. These hostnames will of course be discrete from the name that's used for providing root DNS service. Or at least I hope these names are discrete... From doug.barton at icann.org Mon Jun 13 22:53:39 2005 From: doug.barton at icann.org (Doug Barton) Date: Mon, 13 Jun 2005 13:53:39 -0700 Subject: [dns-wg] Followup to IANA TLD delegation problem In-Reply-To: <25332.1118664142@switch.ch> References: <42AA2FE9.8030308@icann.org> <25332.1118664142@switch.ch> Message-ID: <42ADF253.6040705@icann.org> Marcel, Thanks for these questions. I've responded in line below to (hopefully) make the responses more clear. Marcel Schneider wrote: > On Friday, 10 Jun 2005, Doug Barton writes: > > Dear Doug > > Thanks for responding to Jim's questions. Reading your mail > I still have difficulties understanding two issues: > > a) You state in [1] that after editing the root zone, VeriSign > experienced an "unexpected result". What exactly was the result As described in the first paragraph of my answers below, the wrong hostname appeared in a few TLD delegations. For example, if there was an existing hostname ns1.foo.example which pointed to 10.0.0.1, and this hostname appeared in the delegation of the .aa ccTLD; then a new hostname was introduced with the same IP address, the problem manifested itself as the new hostname appearing in the delegation for .aa, instead of the correct (old) hostname. This error was caught by the VeriSign staff during their change management process for root zone changes, and brought to the attention of the IANA staff before that version of the zone was published. A new root zone with the correct changes was then published, ans verified by the ICANN and VeriSign staffs. Unfortunately, subsequent production of the root zone that should not have had changes to the delegations with the duplicate hostnames reflected the initial problem, and this result was not observed before the new zone went live. The unplanned changes to the delegations were noticed both by IANA staff, and at least one member of the ccTLD community, and when brought to VeriSign's attention, was corrected as described below. > what caused it ? Whould also appreciate if you could elaborate > on how VeriSign was able to fix this "unexpected result". ICANN was not informed of the details of what caused the problem, or how it was fixed. We have asked VeriSign to provide us, and the community with additional details about this incident. > b) When this "unexpected result" was regarded by IANA staff as > temporary and as having minimal operational impact, why was > AFNIC then sent this response to their application: > > "IANA is no longer adding additional examples of host names in > delegation records where multiple host names point to the same IP > address". > > The "no longer" suggests a policy change. Why did IANA not just > say: "Folks we have a problem here, wait a moment until we've > fixed it" ? AFNIC had requested a clear statement about why an alternative solution was being discussed to fulfill their operational goals. My statement to AFNIC was, "Due to problems encountered in the past, we are no longer adding additional examples of hostnames in delegation records where multiple hostnames point to the same IP address." In retrospect, my statement was made in more absolute terms than actually intended, or needed. I would once again like to offer my apologies for the confusion caused by this incident. My message to AFNIC was not intended to convey any kind of policy change on the part of the IANA, and I appreciate this opportunity to clarify the situation. For those attending the CENTR meeting in Trondheim this week I would love to chat with you more in person about this, or any other issue of interest. Warmest regards, Doug -- Doug Barton General Manager, The Internet Assigned Numbers Authority >>Thanks again for the opportunity to discuss these issues. I hope that the >>group finds these answers satisfactory. We are of course happy to discuss >>this in further detail if desired. > > >>[1] What was the nature of the technical problem that prevented >>multiple names in for an IP address and how was it resolved? > > >>In November of 2004 AFNIC asked to have several hostnames added to the root >>zone that resolved to the same IPv4 addresses as hostnames that already >>existed. When VeriSign edited the root zone to include these new names, an >>unexpected result occurred. In some of the TLDs that had the pre-existing >>hostnames for these servers, the new hostnames appeared in the delegations >>inappropriately. This problem was identified within several hours of the >>zone going live by VeriSign staff, as well as at least one member of the >>ccTLD community. The VeriSign and IANA staffs communicated immediately about >>this issue, and the specific problem related to this request was fixed >>manually by VeriSign in the next zone revision after it was identified. > > >>Because in any pair of hostnames affected by this result the IPv4 address >>was the same, the operational impact of this problem was minimal, if it was >>identifiable at all. > > > >>[2] Why was there no announcement that this problem existed? > > >>The specific problem applied only to new instances of duplicate names, it >>did not affect existing duplicate names for which no change was in process. >>The total number of these duplicate hostnames is very small relative to the >>rest of the zone (less than 3%), and requests to modify domains which have >>these hostnames in their delegations are rare. There were no instances of >>such a request from November of 2004 through March of 2005, when AFNIC >>submitted the request for the RE ccTLD. > > >>Because the issue affected only a small number of TLDs and name server >>operators, IANA staff chose to address the issue with those individuals >>directly. Often TLD managers appreciate such specific cases being dealt with >>on a personal level. > > > >>[3] Are safeguards now in place to prevent this sort of problem recurring? > > >>Yes. VeriSign has informed us that the general problem which produced the >>original unexpected result has now been corrected. Additionally, IANA staff >>have enhanced efforts to monitor the "live" root zone from several different >>servers, and use that data to proactively monitor the results of change >>requests. > > > >>[4] What procedures does IANA (or ICANN?) have to make sure that changes >>to the TLD delegation process or problems with that process are properly >>communicated to its stakeholders? > > >>The procedure that IANA uses to communicate changes in the TLD delegation >>process follows the typical ICANN formula of involving key stakeholders at >>early stages, opening proposals up for public comment, incorporating >>appropriate comments into the final version, and posting the procedure for >>its stakeholders. A relevant example of this process is the "Delegation Data >>Procedure," which is posted at >>http://www.iana.org/procedures/delegation-data.html. > > >>Specific problems in the root management process are evaluated on a case by >>case basis. When necessary, there is a mailing list composed of the contact >>addresses for each of the TLD managers that can be utilized for any issue of >>wide interest to the TLD manager community. As noted above, cases which >>affect one, or a few TLDs are often dealt with on a one-to-one basis, with >>the appreciation of the relevant TLD manager(s). > > > >>[5] Were those procedures followed for this incident? If not, why not? > > >>The procedure for communicating changes to the TLD delegation process was >>not followed in this specific case because there was no formal change of >>process. > > >>The specific problem which produced the delay in processing AFNIC's request >>for RE was always understood to be temporary. As discussed above, rather >>than widely disseminate the information about this issue to the TLD manager >>community, IANA staff chose to communicate directly with those affected by >>the issue. > > > >>ICANN's goal, as always, is to cooperate with the TLD managers in >>implementing the changes they feel are appropriate for their TLDs, while >>also maintaining the stability of the DNS. We regret if our cautious >>handling of this particular request, or the timing of our responses to the >>group's reasonable questions, has caused any undue confusion in the DNS >>community about ICANN's dedication to that goal. We welcome comment and >>discussion on these topics. > > >>I am enclosing below some information about the current (at this writing, >>2005061000) root zone that may be relevant to this discussion. The first >>part is the complete list of IPv4 addresses that have multiple hostnames >>associated. There are no IPv6 addresses with multiple hostnames. The second >>part is a compilation of statistics about the current zone. > > >>Regards, > > >>Doug > > > >>128.112.129.15: dns.princeton.edu c.ext.nic.fr >>192.134.0.49: c.nic.fr ns3.nic.fr >>192.36.144.116: slave.sth.netnod.se slave1.sth.netnod.se >>192.93.0.1: a.nic.fr ns1.nic.fr >>192.93.0.4: b.nic.fr ns2.nic.fr >>193.176.144.6: e.ext.nic.fr ns3.domain-registry.nl >>193.51.208.13: dns.inria.fr a.ext.nic.fr >>204.152.184.64: ns-ext.vix.com ns-ext.isc.org >>204.74.112.1: tld1.basicfusion.net tld1.ultradns.net ud1.ns.net.ua >>204.74.113.1: tld2.basicfusion.net tld2.ultradns.net > > >>Statistics >>========== >>Number of gTLDs: 15 >>Number of ccTLDs: 245 >>Total number of TLDs: 260 > > >>Number of IPv4 hosts: 798 >>Number of IPv4 addresses: 798 > > >>Number of IPv6 hosts: 40 >>Number of IPv6 addresses: 41 >>TLDs with IPv6 glue: 50 > > >>Total TLD name server hosts: 797 > > > >>-- >>Doug Barton >>General Manager, The Internet Assigned Numbers Authority From mlarson at verisign.com Wed Jun 15 15:50:06 2005 From: mlarson at verisign.com (Matt Larson) Date: Wed, 15 Jun 2005 09:50:06 -0400 Subject: [dns-wg] Followup to IANA TLD delegation problem In-Reply-To: <42AA2FE9.8030308@icann.org> References: <42AA2FE9.8030308@icann.org> Message-ID: <20050615135006.GJ2516@monsoon.verisignlabs.com> On Fri, 10 Jun 2005, Doug Barton wrote: > Thanks again for the opportunity to discuss these issues. I hope that the > group finds these answers satisfactory. We are of course happy to discuss > this in further detail if desired. In the interests of further explanation and clarification, I'd like to add some details of these events from VeriSign's perspective. First, to be clear, the VeriSign registry database that generates the root zone has supported multiple name server names (i.e., A records) with the same IP address for some time. There was never a technical restriction on multiple names with the same IP address during these events. On November 11, 2005, VeriSign performed a root zone edit as requested by an IANA Name Server Change template for the .FR ccTLD. The template requested name server NAME changes. A request to change the name DNS.PRINCETON.EDU. was included in the template. As a result of the execution of the change, the name DNS.PRINCETON.EDU did not exist and had been replaced by C.EXT.NIC.FR. Considering the template semantics, this was the correct result. It was not, however, the result that IANA desired. After VeriSign discovered the undesired results, DNS.PRINCETON.EDU was immediately re-added to the root zone by ADDing a new name server. In retrospect, it is apparent that the correct way to accomplish the original request would have been to request a new server ADD for C.EXT.NIC.FR, and then to delegate .FR to it while leaving the older name server DNS.PRINCETON.EDU untouched, and thus leaving delegations of BI, CH, HT, LI, and LU untouched. Below is an example of a preferred template semantic for a name server NAME change, followed by the original template as it arrived: New/GOOD: ************************************************************ CCTLD MODIFICATION TEMPLATE v.1.3 1. Purpose/Description.............: Add 7 name servers, add an IPv6 address for 1 name server and remove 6 name servers 2. Top-Level Domain Name...........: .fr 3. Sponsoring Organization [no change] 4. Administrative Contact [no change] 5. Technical Contact [no change] Primary Name Server [add primary nameserver] 6a. Primary Server Hostname.........: A.NIC.FR 6b. Primary Server Netaddress.......: 192.93.0.1 [remove NS1.NIC.FR from delegation] Secondary Name Server [add secondary nameserver] 7a. Secondary Server Hostname.......: B.NIC.FR 7b. Secondary Server Netaddress.....: 192.93.0.4 7c. Secondary Server Netaddress.....: 2001:660:3005:1::1:2 [remove NS2.NIC.FR from delegation] Secondary Name Server [no change] 7a. Secondary Server Hostname.......: C.NIC.FR 7b. Secondary Server Netaddress.....: 192.134.0.49 7c. Secondary Server Netaddress.....: 2001:660:3006:1::1:1 Secondary Name Server [add secondary nameserver] 7a. Secondary Server Hostname.......: A.EXT.NIC.FR 7b. Secondary Server Netaddress.....: 193.51.208.13 [remove DNS.INRIA.FR from delegation] Secondary Name Server [add secondary nameserver] 7a. Secondary Server Hostname.......: B.EXT.NIC.FR 7b. Secondary Server Netaddress.....: 128.105.2.10 [remove DNS.CS.WISC.EDU from delegation] Secondary Name Server [add secondary nameserver] 7a. Secondary Server Hostname.......: C.EXT.NIC.FR 7b. Secondary Server Netaddress.....: 128.112.129.15 [remove DNS.PRINCETON.EDU from delegation] Secondary Name Server [add secondary name server] 7a. Secondary Server Hostname.......: D.EXT.NIC.FR 7b. Secondary Server Netaddress.....: 204.152.184.85 7c. Secondary Server Netaddress.....: 2001:4f8:0:2::8 Secondary Name Server [add secondary name server] 7a. Secondary Server Hostname.......: E.EXT.NIC.FR 7b. Secondary Server Netaddress.....: 193.176.144.6 REMOVE: NS-EXT.VIX.COM (204.152.184.64) from delegation ************************************************************ Old/BAD: ************************************************************ CCTLD MODIFICATION TEMPLATE v.1.3 1. Purpose/Description.............: Change the hostname for 5 name servers, add 2 name servers, add an IPv6 address for 1 name server and remove 1 name server 2. Top-Level Domain Name...........: .fr 3. Sponsoring Organization [no change] 4. Administrative Contact [no change] 5. Technical Contact [no change] Primary Name Server [change the hostname and add GLUE] 6a. Primary Server Hostname.........: A.NIC.FR 6b. Primary Server Netaddress.......: 192.93.0.1 [previous hostname was NS1.NIC.FR] Secondary Name Server [change the hostname, add IPv6 address, add GLUE] 7a. Secondary Server Hostname.......: B.NIC.FR 7b. Secondary Server Netaddress.....: 192.93.0.4 7c. Secondary Server Netaddress.....: 2001:660:3005:1::1:2 [previous hostname was NS2.NIC.FR] Secondary Name Server [no change] 7a. Secondary Server Hostname.......: C.NIC.FR 7b. Secondary Server Netaddress.....: 192.134.0.49 7c. Secondary Server Netaddress.....: 2001:660:3006:1::1:1 Secondary Name Server [change the hostname and add GLUE] 7a. Secondary Server Hostname.......: A.EXT.NIC.FR 7b. Secondary Server Netaddress.....: 193.51.208.13 [previous hostname was DNS.INRIA.FR] Secondary Name Server [change the hostname and add GLUE] 7a. Secondary Server Hostname.......: B.EXT.NIC.FR 7b. Secondary Server Netaddress.....: 128.105.2.10 [previous hostname was DNS.CS.WISC.EDU] Secondary Name Server [change the hostname and add GLUE] 7a. Secondary Server Hostname.......: C.EXT.NIC.FR 7b. Secondary Server Netaddress.....: 128.112.129.15 [previous hostname was DNS.PRINCETON.EDU] Secondary Name Server [add secondary name server] 7a. Secondary Server Hostname.......: D.EXT.NIC.FR 7b. Secondary Server Netaddress.....: 204.152.184.85 7c. Secondary Server Netaddress.....: 2001:4f8:0:2::8 Secondary Name Server [add secondary name server] 7a. Secondary Server Hostname.......: E.EXT.NIC.FR 7b. Secondary Server Netaddress.....: 193.176.144.6 REMOVE: NS-EXT.VIX.COM (204.152.184.64) ************************************************************ VeriSign has taken action to avoid this situation in the future. We have shared details of this incident with all relevant VeriSign personnel and alerted them that we should watch for name server NAME changes and not execute them literally. That is, a name server name "change" should not actually be a change, but we should interpret that a name server name change is really a name server name "add." We consider this a temporary fix for the ambiguous name server name change template. The long-term fix should be a less ambiguous name server name change template. To that end, we have opened a discussion with IANA regarding the format and semantics of the root zone change template. Matt -- Matt Larson VeriSign Naming and Directory Services From gall at switch.ch Wed Jun 15 20:28:45 2005 From: gall at switch.ch (Alexander Gall) Date: Wed, 15 Jun 2005 20:28:45 +0200 Subject: [dns-wg] Followup to IANA TLD delegation problem In-Reply-To: <20050615135006.GJ2516@monsoon.verisignlabs.com> References: <42AA2FE9.8030308@icann.org> <20050615135006.GJ2516@monsoon.verisignlabs.com> Message-ID: <17072.29533.387694.115096@hadron.switch.ch> On Wed, 15 Jun 2005 09:50:06 -0400, Matt Larson said: > On Fri, 10 Jun 2005, Doug Barton wrote: >> Thanks again for the opportunity to discuss these issues. I hope that the >> group finds these answers satisfactory. We are of course happy to discuss >> this in further detail if desired. > In the interests of further explanation and clarification, I'd like to > add some details of these events from VeriSign's perspective. > First, to be clear, the VeriSign registry database that generates the > root zone has supported multiple name server names (i.e., A records) > with the same IP address for some time. There was never a technical > restriction on multiple names with the same IP address during these > events. > On November 11, 2005, VeriSign performed a root zone edit as requested > by an IANA Name Server Change template for the .FR ccTLD. The > template requested name server NAME changes. A request to change the > name DNS.PRINCETON.EDU. was included in the template. As a result of > the execution of the change, the name DNS.PRINCETON.EDU did not exist > and had been replaced by C.EXT.NIC.FR. Considering the template > semantics, this was the correct result. It was not, however, the > result that IANA desired. After VeriSign discovered the undesired > results, DNS.PRINCETON.EDU was immediately re-added to the root zone > by ADDing a new name server. I think the problem is that VeriSign uses the concept of name server objects (probably the same model they use for their TLD registries) and IANA doesn't. To IANA, the template simply represents the complete delegation (or maybe only the things that actually changed) for a single TLD, changes of which are not supposed to affect the state of any other TLD. When the template says "remove server for TLD ", IANA actually means "remove the NS record for and possibly the glue RR for if no other TLD is referencing it", while VeriSign apparently just deletes the name server object. Not quite the same thing. > In retrospect, it is apparent that the correct way to accomplish the > original request would have been to request a new server ADD for > C.EXT.NIC.FR, and then to delegate .FR to it while leaving the older > name server DNS.PRINCETON.EDU untouched, and thus leaving delegations > of BI, CH, HT, LI, and LU untouched. It's not at all apparent to me. I don't think this is ncessary and that the template is well-defined without any additional instructions on how to manipulate name servers. It's simple: after the template has been processed (possibly merging it with the previous set of name servers if it only contains diffs), the TLD in question must have NS records for all the "Server Hostname" entries in the template and appropriate A/AAAA glue for each one of them. This is unambiguous and doesn't affect any other TLDs. How VeriSign maps this to their database model is up to them and should not be exposed to the outside. I believe that this is what IANA is expecting, and, frankly, it sounds very reasonable and clear to me. I'm baffled (actually, I'm shocked :-) that such a major misunderstanding could go undetected for so long. -- Alex From jefsey at jefsey.com Wed Jun 22 01:01:55 2005 From: jefsey at jefsey.com (JFC (Jefsey) Morfin) Date: Wed, 22 Jun 2005 01:01:55 +0200 Subject: [dns-wg] Followup to IANA TLD delegation problem In-Reply-To: <25332.1118664142@switch.ch> References: <42AA2FE9.8030308@icann.org> <25332.1118664142@switch.ch> Message-ID: <6.2.1.2.2.20050622003637.038e1170@mail.jefsey.com> Dear Doug, I share the questions of Marcel Schneider: - what was the unexpected result? - what did cause it? - what did permit to decide it could be addressed in small committee? - what did permit to immediately understand the problem was temporary? - how was it fixed? - how to be sure it will not repeat? - why was the mail received by AFNIC phrased that way? - I have some concerns learning that Verisign has the capacity to enter manually in the root? Why was the problem corrected in changing the root file and not the entry in the IANA file? I am sorry for beeing formal about this. But I frankly do not understand anything here. We tested that a distributed multiple automated building of the root from TLD Manager controled multiple on-line copies of their data would be the most secure, interference free solution and most easy for mutual control. Depending on your responses, this case could contradict or confirm this result. As I am writing a Draft to include it into a community test bed along ICP-3 guidelines, I would really want to understand, not propose testing a wrong approach. I thank you for your comments. Sincerely yours. jfc morfin At 14:02 13/06/2005, Marcel Schneider wrote: >On Friday, 10 Jun 2005, Doug Barton writes: > >Dear Doug > >Thanks for responding to Jim's questions. Reading your mail >I still have difficulties understanding two issues: > >a) You state in [1] that after editing the root zone, VerSign > experienced an "unexpected result". What exactly was the result > what caused it ? Whould also appreciate if you could elaborate > on how VerSign was able to fix this "unexpected result". > >b) When this "unexpected result" was regarded by IANA staff as > temporary and as having minimal operational impact, why was > AFNIC then sent this response to their application: > >"IANA is no longer adding additional examples of host names in > delegation records where multiple host names point to the same IP > address". > > The "no longer" suggests a policy change. Why did IANA not just > say: "Folks we have a problem here, wait a moment until we've > fixed it" ? > > >Marcel > > > > > Thanks again for the opportunity to discuss these issues. I hope that the > > group finds these answers satisfactory. We are of course happy to discuss > > this in further detail if desired. > > > [1] What was the nature of the technical problem that prevented > > multiple names in for an IP address and how was it resolved? > > > In November of 2004 AFNIC asked to have several hostnames added to the root > > zone that resolved to the same IPv4 addresses as hostnames that already > > existed. When VeriSign edited the root zone to include these new names, an > > unexpected result occurred. In some of the TLDs that had the pre-existing > > hostnames for these servers, the new hostnames appeared in the delegations > > inappropriately. This problem was identified within several hours of the > > zone going live by VeriSign staff, as well as at least one member of the > > ccTLD community. The VeriSign and IANA staffs communicated immediately > about > > this issue, and the specific problem related to this request was fixed > > manually by VeriSign in the next zone revision after it was identified. > > > Because in any pair of hostnames affected by this result the IPv4 address > > was the same, the operational impact of this problem was minimal, if it was > > identifiable at all. > > > > [2] Why was there no announcement that this problem existed? > > > The specific problem applied only to new instances of duplicate names, it > > did not affect existing duplicate names for which no change was in process. > > The total number of these duplicate hostnames is very small relative to the > > rest of the zone (less than 3%), and requests to modify domains which have > > these hostnames in their delegations are rare. There were no instances of > > such a request from November of 2004 through March of 2005, when AFNIC > > submitted the request for the RE ccTLD. > > > Because the issue affected only a small number of TLDs and name server > > operators, IANA staff chose to address the issue with those individuals > > directly. Often TLD managers appreciate such specific cases being dealt > with > > on a personal level. > > > > [3] Are safeguards now in place to prevent this sort of problem recurring? > > > Yes. VeriSign has informed us that the general problem which produced the > > original unexpected result has now been corrected. Additionally, IANA staff > > have enhanced efforts to monitor the "live" root zone from several > different > > servers, and use that data to proactively monitor the results of change > > requests. > > > > [4] What procedures does IANA (or ICANN?) have to make sure that changes > > to the TLD delegation process or problems with that process are properly > > communicated to its stakeholders? > > > The procedure that IANA uses to communicate changes in the TLD delegation > > process follows the typical ICANN formula of involving key stakeholders at > > early stages, opening proposals up for public comment, incorporating > > appropriate comments into the final version, and posting the procedure for > > its stakeholders. A relevant example of this process is the "Delegation > Data > > Procedure," which is posted at > > http://www.iana.org/procedures/delegation-data.html. > > > Specific problems in the root management process are evaluated on a case by > > case basis. When necessary, there is a mailing list composed of the contact > > addresses for each of the TLD managers that can be utilized for any > issue of > > wide interest to the TLD manager community. As noted above, cases which > > affect one, or a few TLDs are often dealt with on a one-to-one basis, with > > the appreciation of the relevant TLD manager(s). > > > > [5] Were those procedures followed for this incident? If not, why not? > > > The procedure for communicating changes to the TLD delegation process was > > not followed in this specific case because there was no formal change of > > process. > > > The specific problem which produced the delay in processing AFNIC's request > > for RE was always understood to be temporary. As discussed above, rather > > than widely disseminate the information about this issue to the TLD manager > > community, IANA staff chose to communicate directly with those affected by > > the issue. > > > > ICANN's goal, as always, is to cooperate with the TLD managers in > > implementing the changes they feel are appropriate for their TLDs, while > > also maintaining the stability of the DNS. We regret if our cautious > > handling of this particular request, or the timing of our responses to the > > group's reasonable questions, has caused any undue confusion in the DNS > > community about ICANN's dedication to that goal. We welcome comment and > > discussion on these topics. > > > I am enclosing below some information about the current (at this writing, > > 2005061000) root zone that may be relevant to this discussion. The first > > part is the complete list of IPv4 addresses that have multiple hostnames > > associated. There are no IPv6 addresses with multiple hostnames. The second > > part is a compilation of statistics about the current zone. > > > Regards, > > > Doug > > > > 128.112.129.15: dns.princeton.edu c.ext.nic.fr > > 192.134.0.49: c.nic.fr ns3.nic.fr > > 192.36.144.116: slave.sth.netnod.se slave1.sth.netnod.se > > 192.93.0.1: a.nic.fr ns1.nic.fr > > 192.93.0.4: b.nic.fr ns2.nic.fr > > 193.176.144.6: e.ext.nic.fr ns3.domain-registry.nl > > 193.51.208.13: dns.inria.fr a.ext.nic.fr > > 204.152.184.64: ns-ext.vix.com ns-ext.isc.org > > 204.74.112.1: tld1.basicfusion.net tld1.ultradns.net ud1.ns.net.ua > > 204.74.113.1: tld2.basicfusion.net tld2.ultradns.net > > > Statistics > > ========== > > Number of gTLDs: 15 > > Number of ccTLDs: 245 > > Total number of TLDs: 260 > > > Number of IPv4 hosts: 798 > > Number of IPv4 addresses: 798 > > > Number of IPv6 hosts: 40 > > Number of IPv6 addresses: 41 > > TLDs with IPv6 glue: 50 > > > Total TLD name server hosts: 797 > > > > -- > > Doug Barton > > General Manager, The Internet Assigned Numbers Authority From jim at rfc1035.com Wed Jun 22 02:38:33 2005 From: jim at rfc1035.com (Jim Reid) Date: Wed, 22 Jun 2005 01:38:33 +0100 Subject: [dns-wg] Followup to IANA TLD delegation problem In-Reply-To: <6.2.1.2.2.20050622003637.038e1170@mail.jefsey.com> References: <42AA2FE9.8030308@icann.org> <25332.1118664142@switch.ch> <6.2.1.2.2.20050622003637.038e1170@mail.jefsey.com> Message-ID: <3451e6e8bf5b5656e4d08bfec60c860c@rfc1035.com> On Jun 22, 2005, at 00:01, JFC (Jefsey) Morfin wrote: > - what was the unexpected result? > - what did cause it? > - what did permit to decide it could be addressed in small committee? > - what did permit to immediately understand the problem was temporary? > - how was it fixed? > - how to be sure it will not repeat? > - why was the mail received by AFNIC phrased that way? > - I have some concerns learning that Verisign has the capacity to > enter manually in the root? Why was the problem corrected in changing > the root file and not the entry in the IANA file? Jefsey, these questions have already been adequately answered in the responses from Doug Barton on June 11th and 13th. Matt Larson's clarification on the 15th was also helpful. If those replies were not clear enough for you, please take it up directly with the authors of those messages. I'd appreciate it if you did not carry out that dialogue on the DNS WG list. I see no need to continue this discussion any further in this mailing list. Alexander Gall made some comments on the processes surrounding the to-be-replaced template. Aside from his observations, the list has been silent. So the WG should now consider this discussion closed. There may well be some questions on layer-9 issues about transparency and process at IANA that have arisen as a result of this incident. If these exist, they should be taken somewhere else, presumably ICANN. This WG is for operational and technical discussions about the DNS. It does not do layer-9 stuff. > As I am writing a Draft to include it into a community test bed along > ICP-3 guidelines, I would really want to understand, not propose > testing a wrong approach. Hmm. I would have thought the approach to take would be to write the draft, see if the ideas that were proposed had any merit and then implement and test them. That's normally how things get done at the IETF. [Authors of drafts will typically circulate them to colleagues for feedback before they get published.] Feel free to complete your draft and submit it to the IETF in the usual manner. Or if you'd prefer to have the DNS WG discuss your draft, post it to the list where I'm sure it will get the attention it deserves. BTW Jefsey, please fix your mail client or at least trim your postings. There's no need for everyone to see everything that's been posted on this thread over and over again by appending the whole of the message you're replying to. From jefsey at jefsey.com Thu Jun 23 01:47:42 2005 From: jefsey at jefsey.com (JFC (Jefsey) Morfin) Date: Thu, 23 Jun 2005 01:47:42 +0200 Subject: [dns-wg] Followup to IANA TLD delegation problem In-Reply-To: <3451e6e8bf5b5656e4d08bfec60c860c@rfc1035.com> References: <42AA2FE9.8030308@icann.org> <25332.1118664142@switch.ch> <6.2.1.2.2.20050622003637.038e1170@mail.jefsey.com> <3451e6e8bf5b5656e4d08bfec60c860c@rfc1035.com> Message-ID: <6.2.1.2.2.20050623011324.04319eb0@mail.jefsey.com> At 02:38 22/06/2005, Jim Reid wrote: >On Jun 22, 2005, at 00:01, JFC (Jefsey) Morfin wrote: >>- what was the unexpected result? >>- what did cause it? >>- what did permit to decide it could be addressed in small committee? >>- what did permit to immediately understand the problem was temporary? >>- how was it fixed? >>- how to be sure it will not repeat? >>- why was the mail received by AFNIC phrased that way? >>- I have some concerns learning that Verisign has the capacity to enter >>manually in the root? Why was the problem corrected in changing the root >>file and not the entry in the IANA file? > >Jefsey, these questions have already been adequately answered in the >responses from Doug Barton on June 11th and 13th. Matt Larson's >clarification on the 15th was also helpful. If those replies were not >clear enough for you, please take it up directly with the authors of those >messages. Dear Jim, I do not think they answer the concerns I have. >I'd appreciate it if you did not carry out that dialogue on the DNS WG >list. I see no need to continue this discussion any further in this >mailing list. Alexander Gall made some comments on the processes >surrounding the to-be-replaced template. Aside from his observations, the >list has been silent. So the WG should now consider this discussion closed. It is not silent since I rose these points. Political decisions may result from this, this is why I would have prefered to be exhaustive and fair. But I do not understand your political layer: now we discuss source code and operational procedures. >[Authors of drafts will typically circulate them to colleagues for >feedback before they get published.] This is a BCP based upon three years of work and test by an independent organisation (IETF was not interested). What is reported here is more experimental than operational. Hence my interest. >Feel free to complete your draft and submit it to the IETF in the usual >manner. Or if you'd prefer to have the DNS WG discuss your draft, post it >to the list where I'm sure it will get the attention it deserves. Certainly. >BTW Jefsey, please fix your mail client or at least trim your postings. >There's no need for everyone to see everything that's been posted on this >thread over and over again by appending the whole of the message you're >replying to. Apologies. jfc From jaap at NLnetLabs.nl Thu Jun 23 10:35:59 2005 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Thu, 23 Jun 2005 10:35:59 +0200 Subject: [dns-wg] Followup to IANA TLD delegation problem In-Reply-To: Your message of Thu, 23 Jun 2005 01:47:42 +0200. <6.2.1.2.2.20050623011324.04319eb0@mail.jefsey.com> Message-ID: <200506230835.j5N8ZxBs097374@bartok.nlnetlabs.nl> I do not think they answer the concerns I have. As Jim has said: >Aside from his observations, the >list has been silent. So the WG should now consider this discussion closed. It is not silent since I rose these points. Political decisions may result from this, this is why I would have prefered to be exhaustive and fair. But I do not understand your political layer: now we discuss source code and operational procedures. There has been no discussion. >[Authors of drafts will typically circulate them to colleagues for >feedback before they get published.] This is a BCP based upon three years of work and test by an independent organisation (IETF was not interested). What is reported here is more experimental than operational. Hence my interest. Why don't you just publish it? I only see it mentioned by you on various mailing lists, but the actual thing never surfaced. jaap