From pim at bit.nl Fri Oct 1 16:44:42 2004 From: pim at bit.nl (Pim van Pelt) Date: Fri, 1 Oct 2004 16:44:42 +0200 Subject: [dns-wg] blackhole-*.iana.org gone ? Message-ID: <20041001144441.GA21874@hog.ipng.nl> Hi, The nameserver on blackhole-[12].iana.org does not seem to reply queries for me. $ dig @blackhole-1.iana.org PTR 1.0.0.10.in-addr.arpa. ; <<>> DiG 8.3 <<>> @blackhole-1.iana.org PTR 1.0.0.10.in-addr.arpa. ; (1 server found) ;; res options: init recurs defnam dnsrch ;; res_nsend: Connection refused I am in AS12859. Is anybody else experiencing this problem ? -- Met vriendelijke groet, BIT BV / Ing P.B. van Pelt PBVP1-RIPE (PGPKEY-4DCA7E5E) From pk at TechFak.Uni-Bielefeld.DE Fri Oct 1 16:54:01 2004 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Fri, 01 Oct 2004 16:54:01 +0200 Subject: [dns-wg] blackhole-*.iana.org gone ? In-Reply-To: Your message of "Fri, 01 Oct 2004 16:44:42 +0200." <20041001144441.GA21874@hog.ipng.nl> Message-ID: <200410011454.i91Es2v00730@grimsvotn.TechFak.Uni-Bielefeld.DE> Hi, > I am in AS12859. Is anybody else experiencing this problem ? at least the Autonomica instance, which I happen to use, works. You may want to look at -Peter From jabley at isc.org Fri Oct 1 16:55:16 2004 From: jabley at isc.org (Joe Abley) Date: Fri, 1 Oct 2004 10:55:16 -0400 Subject: [dns-wg] blackhole-*.iana.org gone ? In-Reply-To: <20041001144441.GA21874@hog.ipng.nl> References: <20041001144441.GA21874@hog.ipng.nl> Message-ID: On 1 Oct 2004, at 10:44, Pim van Pelt wrote: > The nameserver on blackhole-[12].iana.org does not seem to reply > queries > for me. > > $ dig @blackhole-1.iana.org PTR 1.0.0.10.in-addr.arpa. > > ; <<>> DiG 8.3 <<>> @blackhole-1.iana.org PTR 1.0.0.10.in-addr.arpa. > ; (1 server found) > ;; res options: init recurs defnam dnsrch > ;; res_nsend: Connection refused > > I am in AS12859. Is anybody else experiencing this problem ? blackhole-1.iana.org and blackhole-2.iana.org are anycast as part of the AS112 project. See . Chances are good that the experiences of other people on this list may not be directly relevant to your problem. Traceroutes show "show ip bgp" to the affected addresses might help identify the actual server you're using. Joe From pim at bit.nl Fri Oct 1 17:15:48 2004 From: pim at bit.nl (Pim van Pelt) Date: Fri, 1 Oct 2004 17:15:48 +0200 Subject: [dns-wg] blackhole-*.iana.org gone ? In-Reply-To: References: <20041001144441.GA21874@hog.ipng.nl> Message-ID: <20041001151547.GB21874@hog.ipng.nl> Hi, | >The nameserver on blackhole-[12].iana.org does not seem to reply | >queries | >for me. | > | >$ dig @blackhole-1.iana.org PTR 1.0.0.10.in-addr.arpa. | > | >; <<>> DiG 8.3 <<>> @blackhole-1.iana.org PTR 1.0.0.10.in-addr.arpa. | >; (1 server found) | >;; res options: init recurs defnam dnsrch | >;; res_nsend: Connection refused | > | >I am in AS12859. Is anybody else experiencing this problem ? | | blackhole-1.iana.org and blackhole-2.iana.org are anycast as part of | the AS112 project. See . traceroute to blackhole-1.iana.org (192.175.48.6), 64 hops max, 44 byte packets 1 jun1 (193.109.122.225) 0.242 ms 0.243 ms 0.591 ms 2 jun1.sara.network.bit.nl (213.136.31.3) 2.811 ms 1.528 ms 1.474 ms 3 blackhole-1.iana.org (192.175.48.6) 2.160 ms 1.329 ms 1.449 ms These are the AMS-IX based nodes. The 193.148.15.39 unicast address which accompanies the AS112 instance at the RIPE NCC seems to have vanished from my routing tables and is therefor not reachable. NCC folks ? -- Met vriendelijke groet, BIT BV / Ing P.B. van Pelt PBVP1-RIPE (PGPKEY-4DCA7E5E) From jeroen at unfix.org Fri Oct 1 17:16:11 2004 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 01 Oct 2004 17:16:11 +0200 Subject: [dns-wg] blackhole-*.iana.org gone ? In-Reply-To: <200410011454.i91Es2v00730@grimsvotn.TechFak.Uni-Bielefeld.DE> References: <200410011454.i91Es2v00730@grimsvotn.TechFak.Uni-Bielefeld.DE> Message-ID: <1096643770.14349.179.camel@firenze.zurich.ibm.com> On Fri, 2004-10-01 at 16:54, Peter Koch wrote: > Hi, > > > I am in AS12859. Is anybody else experiencing this problem ? > > at least the Autonomica instance, which I happen to use, works. > You may want to look at The one in palo alto works: 15 r3-sfo2.r8.pao1.isc.org (192.5.4.232) [AS3557] 158 ms 158 ms 158 ms 16 blackhole-1.iana.org (192.175.48.6) [AS112/AS8001/AS7586/AS13591/AS9942/AS12885] 158 ms 158 ms 158 ms $ dig +short @blackhole-1.iana.org hostname.bind ch txt hostname.bind. 0 CH TXT "hazel.isc.org" Though the next second when one retries it doesn't, and then it is quite apparently, there is no other at AMS-IX, the AS112 installation at ripe according to a traceroute. Unfortunatly there is no direct contact http://www.ripe.net/as112/ though ops at ripe.net are probably in charge. There is a small dip in the graph which might clarify that this is really that node giving problems. Above effect seen from behind AS8251 and AS12871. $ traceroute -A blackhole-1.iana.org traceroute to blackhole-1.iana.org (192.175.48.6), 64 hops max, 40 byte packets 1 nrp-1.bras-1.ams-tel.cistron.net (195.64.92.1) [AS8251] 10 ms 9 ms 9 ms 2 ve-4.rtr-1.ams-sar.cistron.net (62.216.29.1) [AS8251] 10 ms 10 ms 9 ms 3 blackhole-1.iana.org (192.175.48.6) [AS112/AS8001/AS7586/AS13591/AS9942/AS12885] 10 ms 9 ms 9 ms Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From dknight at ripe.net Fri Oct 1 17:40:17 2004 From: dknight at ripe.net (Dave Knight) Date: Fri, 01 Oct 2004 17:40:17 +0200 Subject: [dns-wg] blackhole-*.iana.org gone ? In-Reply-To: <20041001151547.GB21874@hog.ipng.nl> References: <20041001144441.GA21874@hog.ipng.nl> Message-ID: <5.2.1.1.2.20041001173228.0445c008@mailhost.ripe.net> Hi, At 17:15 01/10/2004 +0200, Pim van Pelt wrote: >Hi, > >| >The nameserver on blackhole-[12].iana.org does not seem to reply >| >queries for me. [..] We are indeed having problems with the AS112 server at AMS-IX ( as112.ripe.net [195.69.144.39] ). I have just removed it's advertisement of the 192.175.48.0/24 network. Those of you at AMS-IX who have been experiencing problems should now be using another AS112 server. I'll send a follow-up to the list when we have resolved the problem. Cheers, dave From pim at bit.nl Fri Oct 1 17:58:11 2004 From: pim at bit.nl (Pim van Pelt) Date: Fri, 1 Oct 2004 17:58:11 +0200 Subject: [dns-wg] blackhole-*.iana.org gone ? In-Reply-To: <5.2.1.1.2.20041001173228.0445c008@mailhost.ripe.net> References: <20041001144441.GA21874@hog.ipng.nl> <5.2.1.1.2.20041001173228.0445c008@mailhost.ripe.net> Message-ID: <20041001155811.GA90268@hog.ipng.nl> Hi, | We are indeed having problems with the AS112 server at AMS-IX | ( as112.ripe.net [195.69.144.39] ). | | I have just removed it's advertisement of the 192.175.48.0/24 | network. Those of you at AMS-IX who have been experiencing | problems should now be using another AS112 server. Confirmed, I am reaching one of the instances in London now and this one is just fine. Thanks for acting, it saves some of my customers the hassle of setting up their own zones. They have come to rely on the NXDOMAIN answers they are getting :) -- Met vriendelijke groet, BIT BV / Ing P.B. van Pelt PBVP1-RIPE (PGPKEY-4DCA7E5E) From dknight at ripe.net Fri Oct 1 19:36:53 2004 From: dknight at ripe.net (Dave Knight) Date: Fri, 01 Oct 2004 19:36:53 +0200 Subject: [dns-wg] blackhole-*.iana.org gone ? In-Reply-To: <20041001155811.GA90268@hog.ipng.nl> References: <5.2.1.1.2.20041001173228.0445c008@mailhost.ripe.net> <20041001144441.GA21874@hog.ipng.nl> <5.2.1.1.2.20041001173228.0445c008@mailhost.ripe.net> Message-ID: <5.2.1.1.2.20041001193247.0274c460@mailhost.ripe.net> Hi, The RIPE NCC AS112 server, as112.ripe.net [195.69.144.39] is up and running again and is advertising the 192.175.48.0/24 network. Please report any outstanding issues to: RIPE NCC Operations Apologies for any inconvenience. Cheers, dave From dknight at ripe.net Fri Oct 1 22:54:51 2004 From: dknight at ripe.net (Dave Knight) Date: Fri, 01 Oct 2004 22:54:51 +0200 Subject: [dns-wg] blackhole-*.iana.org gone ? In-Reply-To: <5.2.1.1.2.20041001193247.0274c460@mailhost.ripe.net> References: <20041001155811.GA90268@hog.ipng.nl> <5.2.1.1.2.20041001173228.0445c008@mailhost.ripe.net> <20041001144441.GA21874@hog.ipng.nl> <5.2.1.1.2.20041001173228.0445c008@mailhost.ripe.net> Message-ID: <5.2.1.1.2.20041001225327.026dbd30@mailhost.ripe.net> At 19:36 01/10/2004 +0200, Dave Knight wrote: >Hi, > >The RIPE NCC AS112 server, as112.ripe.net [195.69.144.39] is up and >running again and is advertising the 192.175.48.0/24 network. As we are continuing to have issues with this machine and have decided to take it offline until they are definitively fixed. We plan to replace the hardware and bring it back online next week. Cheers, dave From pk at TechFak.Uni-Bielefeld.DE Mon Oct 4 17:24:49 2004 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Mon, 04 Oct 2004 17:24:49 +0200 Subject: [dns-wg] Reverse delegation checks: call for discussion Message-ID: <200410041524.i94FOoY07431@grimsvotn.TechFak.Uni-Bielefeld.DE> Dear DNS wg, from http://www.ripe.net/ripe/wg/dns/action-list.html you can see action item 48.3: Send to the mailing list (a pointer to) the current list of checks applied to IN-ADDR.ARPA zones before reverse delegation is activated or updated. Initiate review of those checks and propose, if necessary, updates and/or additional tests. Olaf sent the requested information to this list early September: http://www.ripe.net/ripe/mail-archives/dns-wg/2004/msg00172.html During the Action Item Review in Manchester it was decided to take this item to the list with a six week comment period. Anyone interested in changing the currently applied tests (i.e. the set of checks or a particular one) is invited to discuss this on the list or approach the WG co-chairs until November, 5th. Action Item 48.3 will be closed after that date unless tangible proposals have been made. Of course, there's always the opportunity to address this issue in the future should the need arise. Please expect the action item list to be updated after the minutes of RIPE 49 have been circulated. -Peter From james at ripe.net Wed Oct 6 09:56:22 2004 From: james at ripe.net (James Aldridge) Date: Wed, 06 Oct 2004 09:56:22 +0200 Subject: [dns-wg] blackhole-*.iana.org gone ? Message-ID: <200410060756.i967uMrL020171@birch.ripe.net> Dave Knight wrote: > At 19:36 01/10/2004 +0200, Dave Knight wrote: > >Hi, > > > >The RIPE NCC AS112 server, as112.ripe.net [195.69.144.39] is up and > >running again and is advertising the 192.175.48.0/24 network. > > As we are continuing to have issues with this machine and have decided > to take it offline until they are definitively fixed. We plan to replace > the hardware and bring it back online next week. Since around 13:00 UTC yesterday afternoon, as112.ripe.net has been running on new hardware (with a software upgrade at the same time for good measure). Regards, James From adamo at central.tee.gr Wed Oct 13 10:16:02 2004 From: adamo at central.tee.gr (Yiorgos Adamopoulos) Date: Wed, 13 Oct 2004 11:16:02 +0300 Subject: [dns-wg] ORSN-SERVERS.NET Message-ID: <416CE442.2050607@central.tee.gr> [ Sorry if this has been discussed before ] Recenlty I came across ORSN . Soonafter I discovered that one of our peers is using their rootzone (and we are forwarding queries to them). So, the question is: What do you think of this effort? o any members of the group use the ORSN-SERVERS.NET root instead of the traditional one? If so why? If not why? TIA, -Yiorgos. From roy at dnss.ec Wed Oct 13 10:28:57 2004 From: roy at dnss.ec (Roy Arends) Date: Wed, 13 Oct 2004 10:28:57 +0200 (CEST) Subject: [dns-wg] ORSN-SERVERS.NET In-Reply-To: <416CE442.2050607@central.tee.gr> References: <416CE442.2050607@central.tee.gr> Message-ID: On Wed, 13 Oct 2004, Yiorgos Adamopoulos wrote: > Recenlty I came across ORSN . Soonafter I > discovered that one of our peers is using their rootzone (and we are > forwarding queries to them). > > So, the question is: What do you think of this effort? o any members > of the group use the ORSN-SERVERS.NET root instead of the traditional > one? If so why? If not why? This effort is undermining the stability of the DNS Please read RFC 2826 http://www.ietf.org/rfc/rfc2826.txt Roy From jeroen at unfix.org Wed Oct 13 10:35:50 2004 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 13 Oct 2004 10:35:50 +0200 Subject: [dns-wg] ORSN-SERVERS.NET In-Reply-To: References: <416CE442.2050607@central.tee.gr> Message-ID: <1097656550.27737.34.camel@firenze.zurich.ibm.com> On Wed, 2004-10-13 at 10:28 +0200, Roy Arends wrote: > > On Wed, 13 Oct 2004, Yiorgos Adamopoulos wrote: > > > Recenlty I came across ORSN . Soonafter I > > discovered that one of our peers is using their rootzone (and we are > > forwarding queries to them). > > > > So, the question is: What do you think of this effort? o any members > > of the group use the ORSN-SERVERS.NET root instead of the traditional > > one? If so why? If not why? > > This effort is undermining the stability of the DNS > > Please read RFC 2826 RFC's are still Request For Comments, not Standards, nevertheless anyone can choose to use any infrastructure, rootserver, firewalling policies, routing policies and a whole lot of other politics that that person/organisation whishes to follow. For that matter if someone would setup his/her/it's own RIR and started giving out IPv4 or IPv6 addresses, who is going to stop you? That it won't interoperate with what most of the people on this globe call 'the internet' is another question, but isn't that their problem? Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From dr at cluenet.de Wed Oct 13 10:46:23 2004 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 13 Oct 2004 10:46:23 +0200 Subject: [dns-wg] ORSN-SERVERS.NET In-Reply-To: <1097656550.27737.34.camel@firenze.zurich.ibm.com> References: <416CE442.2050607@central.tee.gr> <1097656550.27737.34.camel@firenze.zurich.ibm.com> Message-ID: <20041013084623.GA11024@srv01.cluenet.de> On Wed, Oct 13, 2004 at 10:35:50AM +0200, Jeroen Massar wrote: > For that matter if someone would setup his/her/it's own RIR and > started giving out IPv4 or IPv6 addresses, who is going to stop > you? That it won't interoperate with what most of the people on > this globe call 'the internet' is another question, but isn't > that their problem? As soon as I have to deal with the fallout of that, it certainly becomes _my_ problem. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From jim at rfc1035.com Wed Oct 13 10:55:18 2004 From: jim at rfc1035.com (Jim Reid) Date: Wed, 13 Oct 2004 09:55:18 +0100 Subject: [dns-wg] ORSN-SERVERS.NET In-Reply-To: Message from Jeroen Massar of "Wed, 13 Oct 2004 10:35:50 +0200." <1097656550.27737.34.camel@firenze.zurich.ibm.com> Message-ID: <9706.1097657718@gromit.rfc1035.com> >>>>> "Jeroen" == Jeroen Massar writes: Jeroen> RFC's are still Request For Comments, not Standards, Some RFCs *are* standards and get labelled as such. Sadly 2826 isn't one of them. :-( Jeroen> nevertheless anyone can choose to use any infrastructure, Jeroen> rootserver, firewalling policies, routing policies and a Jeroen> whole lot of other politics that that person/organisation Jeroen> whishes to follow. For that matter if someone would setup Jeroen> his/her/it's own RIR and started giving out IPv4 or IPv6 Jeroen> addresses, who is going to stop you? That it won't Jeroen> interoperate with what most of the people on this globe Jeroen> call 'the internet' is another question, but isn't that Jeroen> their problem? Not really. Granted, they have the lion's share of the problems. But those problems won't stop at the boundary of their net. For example, a bogus TLD will leak out to people on the real internet, links on web pages can't be resolved (or point elsewhere), users get confused, mail gets bounced or treated as spam, etc, etc. Once that happens, bogus root servers and suchlike become a serious problem for the helpdesks and support people at ISPs on the real internet. If only there was a Protocol Police to deal with these impostors. From Piet.Beertema at cwi.nl Wed Oct 13 11:45:43 2004 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Wed, 13 Oct 2004 11:45:43 +0200 Subject: [dns-wg] ORSN-SERVERS.NET In-Reply-To: <1097656550.27737.34.camel@firenze.zurich.ibm.com> References: <416CE442.2050607@central.tee.gr> Message-ID: <5.1.0.14.2.20041013114208.00b036d0@imap.cwi.nl> >RFC's are still Request For Comments, not Standards You're plain wrong. Period. No matter what the title, RFC's are standards that are cast in concrete, until the time that they're superseded by a new RFC. >For that matter if someone would setup his/her/it's own RIR and started >giving out IPv4 or IPv6 addresses, who is going to stop you? Nobody is going to stop an idiot. >That it won't interoperate with what most of the people on this globe >call 'the internet' is another question, but isn't that their problem? It's both their problem and the problem of those who fall into their trap. And in the worst case the latter category may become a nuisance for all of 'the internet'. Piet From bortzmeyer at nic.fr Wed Oct 13 12:03:24 2004 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 13 Oct 2004 12:03:24 +0200 Subject: [dns-wg] Re: ORSN-SERVERS.NET In-Reply-To: <416CE442.2050607@central.tee.gr> References: <416CE442.2050607@central.tee.gr> Message-ID: <20041013100324.GA5494@nic.fr> On Wed, Oct 13, 2004 at 11:16:02AM +0300, Yiorgos Adamopoulos wrote a message of 13 lines which said: > So, the question is: What do you think of this effort? o any members > of the group use the ORSN-SERVERS.NET root instead of the traditional > one? I use it at home (not at work and my personal opinion does not bind AFNIC and so on and so forth). It works well. I used ORSC http://www.open-rsc.org/ before which is technically... not perfect (and unresponsive). Until now, the sky did not fall, my wife did not leave the home, my bank did not block my account, I did not become deaf and the Linux server still boots. From bortzmeyer at nic.fr Wed Oct 13 12:04:33 2004 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 13 Oct 2004 12:04:33 +0200 Subject: [dns-wg] Re: ORSN-SERVERS.NET In-Reply-To: References: <416CE442.2050607@central.tee.gr> Message-ID: <20041013100433.GB5494@nic.fr> On Wed, Oct 13, 2004 at 10:28:57AM +0200, Roy Arends wrote a message of 19 lines which said: > Please read RFC 2826 Please read about ORSN (http://european.nl.orsn.net/faq.php#opmode). ORSN is *not* an alternative root. From bortzmeyer at nic.fr Wed Oct 13 12:07:07 2004 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 13 Oct 2004 12:07:07 +0200 Subject: [dns-wg] Re: ORSN-SERVERS.NET In-Reply-To: <9706.1097657718@gromit.rfc1035.com> References: <1097656550.27737.34.camel@firenze.zurich.ibm.com> <9706.1097657718@gromit.rfc1035.com> Message-ID: <20041013100707.GC5494@nic.fr> On Wed, Oct 13, 2004 at 09:55:18AM +0100, Jim Reid wrote a message of 26 lines which said: > links on web pages can't be resolved (or point elsewhere), users get > confused, mail gets bounced or treated as spam, etc, etc. Keep cool. With firewalls, intranets and split DNS, all these things already happen daily (and create problems for the poor guys at the support). > If only there was a Protocol Police to deal with these impostors. A Police dealing with every broken implementation spotted in the wild? How long will they work, 48 hours a day? From Piet.Beertema at cwi.nl Wed Oct 13 12:13:59 2004 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Wed, 13 Oct 2004 12:13:59 +0200 Subject: [dns-wg] Re: ORSN-SERVERS.NET In-Reply-To: <20041013100324.GA5494@nic.fr> References: <416CE442.2050607@central.tee.gr> <416CE442.2050607@central.tee.gr> Message-ID: <5.1.0.14.2.20041013121209.00b036d0@imap.cwi.nl> >I use it at home (not at work and my personal opinion does not bind >AFNIC and so on and so forth). It works well. >Until now, the sky did not fall, my wife did not leave the home, my >bank did not block my account, I did not become deaf and the Linux >server still boots. Thanks for this non-exhaustive list of things that could go wrong. ;-) Piet From pim at bit.nl Wed Oct 13 12:19:15 2004 From: pim at bit.nl (Pim van Pelt) Date: Wed, 13 Oct 2004 12:19:15 +0200 Subject: [dns-wg] Re: ORSN-SERVERS.NET In-Reply-To: <20041013100433.GB5494@nic.fr> References: <416CE442.2050607@central.tee.gr> <20041013100433.GB5494@nic.fr> Message-ID: <20041013101915.GB40120@hog.ipng.nl> Hi, | > Please read RFC 2826 | | Please read about ORSN | (http://european.nl.orsn.net/faq.php#opmode). ORSN is *not* an | alternative root. Yes it in fact _is_ an alternative root, but the contents are the same at this time. When (if, and when) the operators of the ORSN root choose to deviate from the current ICANN-root, they can and will do so. This is a deliberate aspect of the OSRN project. I do not think this is that harmless, especially when the FAQ states ' - in our opinion - ' because that opinion may conflict with their users' opinion. It undermines DNS. groet, Pim -- Met vriendelijke groet, BIT BV / Ing P.B. van Pelt PBVP1-RIPE (PGPKEY-4DCA7E5E) From roy at dnss.ec Wed Oct 13 13:20:50 2004 From: roy at dnss.ec (Roy Arends) Date: Wed, 13 Oct 2004 13:20:50 +0200 (CEST) Subject: [dns-wg] Re: ORSN-SERVERS.NET In-Reply-To: <20041013100433.GB5494@nic.fr> References: <416CE442.2050607@central.tee.gr> <20041013100433.GB5494@nic.fr> Message-ID: On Wed, 13 Oct 2004, Stephane Bortzmeyer wrote: > On Wed, Oct 13, 2004 at 10:28:57AM +0200, > Roy Arends wrote > a message of 19 lines which said: > > > Please read RFC 2826 > > Please read about ORSN > (http://european.nl.orsn.net/faq.php#opmode). ORSN is *not* an > alternative root. I did. It is an alternative root, since it is not sanctioned nor supported by ICANN. The main reason for the ORSN is outlined in the about page at their site. IMHO, their reasons (a lesser dependency on non-european instances of authoritative root-servers, but correct me if I'm wrong) are less valid nowadays, since some of the ICANN root-server operators chose to use anycast as a viable means to spread the load on the root-zone. f.root-servers.net: 26 sites, (5 in EU, 4 in US) i.root-servers.net: 17 sites, (11 in EU, 2 in US) j.root-servers.net: 13 sites, (3 in EU, 7 in US) k.root-servers.net: 6 sites, (5 in EU and 1 in Qatar) m.root-servers.net: 3 sites, (1 in EU) The rest of roots: 11 sites in US. In total 76 instances of a root-server of which are 25 in the EU, 26 in the US, and 50 outside EU/US. And this network is growing and growing. I can recommend any organisation who has the resources (skill and infrastructure) that would like to help to spread the load of the root-servers to contact the anycast-enabled root operators (ISC, Autonomica/Nordunet, RIPE). In comparison, there are 13 ORSN servers based in europe, of which are 2 unused, and 1 has errors. I do understand the effort ORSN is trying to make. If it is to spread load and create less dependency, they are obviously not up to par with the ICANN root-server network. If they effort is merely a political protest, that is a different layer I know nothing about. Roy From roy at dnss.ec Wed Oct 13 14:21:18 2004 From: roy at dnss.ec (Roy Arends) Date: Wed, 13 Oct 2004 14:21:18 +0200 (CEST) Subject: [dns-wg] Re: ORSN-SERVERS.NET In-Reply-To: References: <416CE442.2050607@central.tee.gr> <20041013100433.GB5494@nic.fr> Message-ID: On Wed, 13 Oct 2004, Roy Arends wrote: > In total 76 instances of a root-server of which are 25 in the > EU, 26 in the US, and 50 outside EU/US. 25 outside EU/US Roy From bmanning at vacation.karoshi.com Wed Oct 13 15:46:31 2004 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 13 Oct 2004 13:46:31 +0000 Subject: [dns-wg] -RFC- In-Reply-To: <5.1.0.14.2.20041013114208.00b036d0@imap.cwi.nl> References: <416CE442.2050607@central.tee.gr> <5.1.0.14.2.20041013114208.00b036d0@imap.cwi.nl> Message-ID: <20041013134631.GD3417@vacation.karoshi.com.> On Wed, Oct 13, 2004 at 11:45:43AM +0200, Piet Beertema wrote: > > >RFC's are still Request For Comments, not Standards > > You're plain wrong. Period. No matter what the title, RFC's are > standards that are cast in concrete, until the time that they're > superseded by a new RFC. not all are standards. please clarify your understanding by reviewing http://www.rfc-editor.org/ > Piet --bill From bmanning at vacation.karoshi.com Wed Oct 13 15:54:14 2004 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 13 Oct 2004 13:54:14 +0000 Subject: [dns-wg] Re: root-servers In-Reply-To: References: <416CE442.2050607@central.tee.gr> <20041013100433.GB5494@nic.fr> Message-ID: <20041013135414.GE3417@vacation.karoshi.com.> > It is an alternative root, since it is not sanctioned nor supported > by ICANN. > > I can recommend any organisation who has the resources (skill and > infrastructure) that would like to help to spread the load of the > root-servers to contact the anycast-enabled root operators (ISC, > Autonomica/Nordunet, RIPE). several other operators are also anycasting - we don't use the ISC maintained publication page ... > ICANN root-server network. this is a misnomer. there is no ICANN supported root server network. ICANN sactions a root-server network, but its not theirs. > > Roy --bill From roy at dnss.ec Wed Oct 13 16:07:45 2004 From: roy at dnss.ec (Roy Arends) Date: Wed, 13 Oct 2004 16:07:45 +0200 (CEST) Subject: [dns-wg] Re: root-servers In-Reply-To: <20041013135414.GE3417@vacation.karoshi.com.> References: <416CE442.2050607@central.tee.gr> <20041013100433.GB5494@nic.fr> <20041013135414.GE3417@vacation.karoshi.com.> Message-ID: On Wed, 13 Oct 2004 bmanning at vacation.karoshi.com wrote: > > It is an alternative root, since it is not sanctioned nor supported > > by ICANN. > > > > I can recommend any organisation who has the resources (skill and > > infrastructure) that would like to help to spread the load of the > > root-servers to contact the anycast-enabled root operators (ISC, > > Autonomica/Nordunet, RIPE). > > several other operators are also anycasting - we don't > use the ISC maintained publication page ... Names, baby, names ! > > ICANN root-server network. > > this is a misnomer. there is no ICANN supported root server > network. ICANN sactions a root-server network, but its not > theirs. icann schmicann, Your message added _zero_ to this discussion, if not mere noise, you can do better ! Roy From Joao_Damas at isc.org Wed Oct 13 22:26:23 2004 From: Joao_Damas at isc.org (Joao Damas) Date: Wed, 13 Oct 2004 22:26:23 +0200 Subject: [dns-wg] Re: root-servers In-Reply-To: <20041013135414.GE3417@vacation.karoshi.com.> References: <416CE442.2050607@central.tee.gr> <20041013100433.GB5494@nic.fr> <20041013135414.GE3417@vacation.karoshi.com.> Message-ID: <265FB0A6-1D56-11D9-BB56-000D93B1DDA6@isc.org> On 13 Oct, 2004, at 15:54, bmanning at vacation.karoshi.com wrote: >> It is an alternative root, since it is not sanctioned nor supported >> by ICANN. >> >> I can recommend any organisation who has the resources (skill and >> infrastructure) that would like to help to spread the load of the >> root-servers to contact the anycast-enabled root operators (ISC, >> Autonomica/Nordunet, RIPE). > > several other operators are also anycasting - we don't > use the ISC maintained publication page ... You mean the ones at www.isc.org? Only F-root is reflected there. That's the only page ISC maintains. Joao From bmanning at vacation.karoshi.com Wed Oct 13 22:27:54 2004 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 13 Oct 2004 20:27:54 +0000 Subject: [dns-wg] Re: root-servers In-Reply-To: <265FB0A6-1D56-11D9-BB56-000D93B1DDA6@isc.org> References: <416CE442.2050607@central.tee.gr> <20041013100433.GB5494@nic.fr> <20041013135414.GE3417@vacation.karoshi.com.> <265FB0A6-1D56-11D9-BB56-000D93B1DDA6@isc.org> Message-ID: <20041013202754.GB4487@vacation.karoshi.com.> On Wed, Oct 13, 2004 at 10:26:23PM +0200, Joao Damas wrote: > > On 13 Oct, 2004, at 15:54, bmanning at vacation.karoshi.com wrote: > > >>It is an alternative root, since it is not sanctioned nor supported > >>by ICANN. > >> > >>I can recommend any organisation who has the resources (skill and > >>infrastructure) that would like to help to spread the load of the > >>root-servers to contact the anycast-enabled root operators (ISC, > >>Autonomica/Nordunet, RIPE). > > > > several other operators are also anycasting - we don't > > use the ISC maintained publication page ... > > You mean the ones at www.isc.org? Only F-root is reflected there. > That's the only page ISC maintains. > > Joao who maintains www.root-servers.org? --bill From Joao_Damas at isc.org Wed Oct 13 22:39:54 2004 From: Joao_Damas at isc.org (Joao Damas) Date: Wed, 13 Oct 2004 22:39:54 +0200 Subject: [dns-wg] Re: root-servers In-Reply-To: <20041013202754.GB4487@vacation.karoshi.com.> References: <416CE442.2050607@central.tee.gr> <20041013100433.GB5494@nic.fr> <20041013135414.GE3417@vacation.karoshi.com.> <265FB0A6-1D56-11D9-BB56-000D93B1DDA6@isc.org> <20041013202754.GB4487@vacation.karoshi.com.> Message-ID: <09BFF3FC-1D58-11D9-BB56-000D93B1DDA6@isc.org> On 13 Oct, 2004, at 22:27, bmanning at vacation.karoshi.com wrote: > On Wed, Oct 13, 2004 at 10:26:23PM +0200, Joao Damas wrote: >> >> On 13 Oct, 2004, at 15:54, bmanning at vacation.karoshi.com wrote: >> >>>> It is an alternative root, since it is not sanctioned nor supported >>>> by ICANN. >>>> >>>> I can recommend any organisation who has the resources (skill and >>>> infrastructure) that would like to help to spread the load of the >>>> root-servers to contact the anycast-enabled root operators (ISC, >>>> Autonomica/Nordunet, RIPE). >>> >>> several other operators are also anycasting - we don't >>> use the ISC maintained publication page ... >> >> You mean the ones at www.isc.org? Only F-root is reflected there. >> That's the only page ISC maintains. >> >> Joao > > who maintains www.root-servers.org? Quite a few people working for several root server operators. You for instance have an account on that machine. Joao From dns-wg at Reithermann.de Wed Oct 13 12:54:58 2004 From: dns-wg at Reithermann.de (Steffen Reithermann) Date: Wed, 13 Oct 2004 12:54:58 +0200 Subject: [dns-wg] Re: ORSN-SERVERS.NET In-Reply-To: <20041013100433.GB5494@nic.fr>; from bortzmeyer@nic.fr on Wed, Oct 13, 2004 at 12:04:33PM +0200 References: <416CE442.2050607@central.tee.gr> <20041013100433.GB5494@nic.fr> Message-ID: <20041013125458.A4513@erebus.ibs.de> Hello, On Wed, Oct 13, 2004 at 12:04:33PM +0200, Stephane Bortzmeyer wrote: > On Wed, Oct 13, 2004 at 10:28:57AM +0200, > Roy Arends wrote > > Please read RFC 2826 > > Please read about ORSN > (http://european.nl.orsn.net/faq.php#opmode). ORSN is *not* an > alternative root. if I read it correctly, ORSN *is* an alternative root, e.g. they say "However, removed TLDs won't be considered ..." in the FAQ you mentioned above, so even in the so-called "ICANN-based mode" there might be a different content of the root zone compared to the official root zone. This might get much worse in the "independent mode" since ORSN is an independent organization with no clear transparency regarding decisions and control of the root zone's content. Besides the technical reason above this is another administrative reason why I would call ORSN an alternative root. Don't get me wrong ... I don't say ICANN's decisions are transparent all or even most of the time. Some independence of Europe regarding DNS and other critical Internet infrastructure is a creditable goal, but I think it needs a stronger basis and a broader support in the ISP community than ORSN seems to have currently. -- Steffen Reithermann From jim at rfc1035.com Thu Oct 14 13:26:30 2004 From: jim at rfc1035.com (Jim Reid) Date: Thu, 14 Oct 2004 12:26:30 +0100 Subject: [dns-wg] Re: ORSN-SERVERS.NET In-Reply-To: Message from Steffen Reithermann of "Wed, 13 Oct 2004 12:54:58 +0200." <20041013125458.A4513@erebus.ibs.de> Message-ID: <12085.1097753190@gromit.rfc1035.com> >>>>> "Steffen" == Steffen Reithermann writes: Steffen> Don't get me wrong ... I don't say ICANN's decisions are Steffen> transparent all or even most of the time. Some Steffen> independence of Europe regarding DNS and other critical Steffen> Internet infrastructure is a creditable goal, but I think Steffen> it needs a stronger basis and a broader support in the Steffen> ISP community than ORSN seems to have currently. Personal opinion: People who are unhappy with ICANN -- and who isn't? -- should be working to reform it from within. ICANN's processes are open and everyone is free to participate. [Sort of.] Supporting or encouraging efforts like alternate DNS roots undermines ICANN. That could lead to the replacement of ICANN with something even less palatable to Internet people: internet governance by international civil servants through some part of the United Nations. From hank at mail.iucc.ac.il Thu Oct 21 10:40:05 2004 From: hank at mail.iucc.ac.il (Hank Nussbacher) Date: Thu, 21 Oct 2004 10:40:05 +0200 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names Message-ID: <5.1.0.14.2.20041021102217.00acdff8@mail.iucc.ac.il> I'm new to this particular WG but I'd like to raise an issue that I feel is best discussed in a European DNS forum. It has to do with .eu: According to my understanding, there will be direct 2nd level domains - like ibm.eu or ripe.eu or even tonyblair.eu. Up till now, most countries employed a hierarchical structure such as ac.xx or co.xx or org.xx. What do we lose by eliminating 2nd level domains? Since .eu is a totally new TLD - perhaps not much, but what happens to countries that then decide to follow the same path as Singapore recently did (they are cc'ed to this email): http://www.nic.net.sg/newsroom/20040816030345.html Are there any limitations to what a 2nd level domain name can be (not referring to trademarks)? I.e. would a single digit or letter be allowed? Would co.sg be allowed (up till now com.sg was the main commercial 2nd level domain)? Are other countries considering following the same path? Thanks, Hank From brad at stop.mail-abuse.org Thu Oct 21 11:05:59 2004 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Thu, 21 Oct 2004 11:05:59 +0200 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: <5.1.0.14.2.20041021102217.00acdff8@mail.iucc.ac.il> References: <5.1.0.14.2.20041021102217.00acdff8@mail.iucc.ac.il> Message-ID: At 10:40 AM +0200 2004-10-21, Hank Nussbacher wrote: > Are other countries considering following the same path? Other countries in Europe already do this, at least including Belgium, Netherlands, France, and Germany. Specific examples I can recall off the top of my head include skynet.be and mind.be, xs4all.nl, wanadoo.fr, and siemens.de. Belgium and the Netherlands may be small, but France and Germany are not. Within Europe, I don't think that this policy is unusual. Nevertheless, given the size of the population of the expanded EU, I don't see how this kind of scheme will scale well to handle potentially hundreds of millions of people. I don't think you necessarily need to go to a US-style city.county.state.us mechanism, but I think a three-level domain scheme would definitely be advisable. Given the problems that some ccTLD operators are already having with their SLD scheme they currently have to live with and how this is making their life unpleasant in trying to manage the huge and very flat ccTLD they already have, I cannot see why people would want to compound this problem by at least a couple of orders of magnitude. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From roy at dnss.ec Thu Oct 21 11:38:17 2004 From: roy at dnss.ec (Roy Arends) Date: Thu, 21 Oct 2004 11:38:17 +0200 (CEST) Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: <5.1.0.14.2.20041021102217.00acdff8@mail.iucc.ac.il> References: <5.1.0.14.2.20041021102217.00acdff8@mail.iucc.ac.il> Message-ID: On Thu, 21 Oct 2004, Hank Nussbacher wrote: > I'm new to this particular WG but I'd like to raise an issue that I feel is > best discussed in a European DNS forum. It has to do with .eu: > > > According to my understanding, there will be direct 2nd level domains - > like ibm.eu or ripe.eu or even tonyblair.eu. Up till now, most countries > employed a hierarchical structure such as ac.xx or co.xx or org.xx. About a third of all cctld use some form (com.xx or co.xx) of 2nd level domain. My experience is that most european cctlds register 2nd level domains. > What do we lose by eliminating 2nd level domains? Eliminating secondlevel domains that were used to part the namespace into categories obviously gets rid of the categorisation. OTOH it is more recognisable (hence desirable) to have example.eu instead of example.co.nl.eu or even example.co.eu. > Since .eu is a totally > new TLD - perhaps not much, but what happens to countries that then decide > to follow the same path as Singapore recently did (they are cc'ed to this > email): > http://www.nic.net.sg/newsroom/20040816030345.html Last year, the ecuadorian CCTLD (.ec) allowed second level registrations (http://www.nic.ec/eng/novedades.htm) Allowing 'cute' names like ips.ec (ipsec) or dnss.ec (dnssec) to be registered, as well as brand names ofcourse. Also some European Community (ec) spoofs were seen. > Are there any limitations to what a 2nd level domain name can be (not > referring to trademarks)? I.e. would a single digit or letter be > allowed? Would co.sg be allowed (up till now com.sg was the main > commercial 2nd level domain)? There are some technical boundaries. i.e. a label can not have more then 62 characters, nor can it be less then 1 character. Another restriction is the character set used (in general a..z0..9-). Also labels are case insensitive. There are yet other technical restrictions due to provisions for internationalised domain names. Prohibiting single character labels is mostly a policy restriction, rather than a technical one. Other policy restrictions may be imposed, like reserved labels. One can imagine prohibiting the registration of 'co' or 'mil' directly under a cctld is such a policy restriction. Regards, Roy Arends From pk at TechFak.Uni-Bielefeld.DE Thu Oct 21 12:17:24 2004 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Thu, 21 Oct 2004 12:17:24 +0200 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: Your message of "Thu, 21 Oct 2004 10:40:05 +0200." <5.1.0.14.2.20041021102217.00acdff8@mail.iucc.ac.il> Message-ID: <200410211017.i9LAHPH18680@grimsvotn.TechFak.Uni-Bielefeld.DE> Hank Nussbacher wrote: > like ibm.eu or ripe.eu or even tonyblair.eu. Up till now, most countries > employed a hierarchical structure such as ac.xx or co.xx or org.xx. a quick scan showed that at least 1/4 of the 248 ccTLDs (some of them aren't open for registration at all) allow for registration of 2LDs. Within Europe, the percentage is higher and has been increasing, i.e. TLDs have changed their policies from 'structured' to 'flat' in the past. > Are there any limitations to what a 2nd level domain name can be (not > referring to trademarks)? I.e. would a single digit or letter be > allowed? Would co.sg be allowed (up till now com.sg was the main > commercial 2nd level domain)? The problem described in RFC 1535 is still present (I've just coincidentally looked at "new" TLDs recently), so I'd always recommend to block all existing TLDs plus all 2-character SLDs (since most of them might become a country code). Part of that was already realized in EU Regulation 733/2002 (number 19) and still can be found in the COMMISSION REGULATION (EC) No 874/2004 of 28 April 2004 http://europe.eu.int/cgi-bin/eur-lex/udl.pl?REQUEST=Seek-Deliver&LANGUAGE=en&SERVICE=eurlex&COLLECTION=oj&DOCID=2004l162p00400050 where - amongst other names - the 2 character codes of existing countries (article 8) are blocked, although very likely for different reasons than those motivated by RFC 1535. -Peter From Piet.Beertema at cwi.nl Thu Oct 21 12:56:43 2004 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Thu, 21 Oct 2004 12:56:43 +0200 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: References: <5.1.0.14.2.20041021102217.00acdff8@mail.iucc.ac.il> <5.1.0.14.2.20041021102217.00acdff8@mail.iucc.ac.il> Message-ID: <5.1.0.14.2.20041021124734.00b03b78@imap.cwi.nl> >Other countries in Europe already do this, at least including Belgium, >Netherlands, France, and Germany. Denmark, Sweden, Italy, Spain, Portugal, etc. They all followed the example that I set with .nl in 1986. Some now work with a mixture of 2nd and 3rd level domains. >Nevertheless, given the size of the population of the expanded EU, I >don't see how this kind of scheme will scale well to handle potentially >hundreds of millions of people. I don't think there's any need for that. What would private persons gain by registering .eu instead of .? Adding something .co.eu (which the EU policy already rules out) or .com.eu wouldn't really alleviate the perceived problem. >I don't think you necessarily need to go to a US-style city.county.state.us >mechanism That's counterproductive: moving from one city to another, which is quite common for private persons, would imply a new domain name... >but I think a three-level domain scheme would definitely be advisable. It might be worth considering, but advisable? Not in my view. Piet From Piet.Beertema at cwi.nl Thu Oct 21 13:19:46 2004 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Thu, 21 Oct 2004 13:19:46 +0200 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: <200410211017.i9LAHPH18680@grimsvotn.TechFak.Uni-Bielefeld. DE> References: Message-ID: <5.1.0.14.2.20041021125710.055daeb0@imap.cwi.nl> >COMMISSION REGULATION (EC) No 874/2004 of 28 April 2004 >http://europe.eu.int/cgi-bin/eur-lex/udl.pl?REQUEST=Seek-Deliver&LANGUAGE=en&SERVICE=eurlex&COLLECTION=oj&DOCID=2004l162p00400050 > >where - amongst other names - the 2 character codes of existing countries >(article 8) are blocked Which is short-sighted. What's the use of blocking only *existing* ccTLD codes, when nobody can foresee what new ccTLD codes may come to exist in the future? We've seen enough recent examples... Piet From brad at stop.mail-abuse.org Thu Oct 21 13:53:26 2004 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Thu, 21 Oct 2004 13:53:26 +0200 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: <5.1.0.14.2.20041021125710.055daeb0@imap.cwi.nl> References: <5.1.0.14.2.20041021125710.055daeb0@imap.cwi.nl> Message-ID: At 1:19 PM +0200 2004-10-21, Piet Beertema wrote: > Which is short-sighted. What's the use of blocking only *existing* > ccTLD codes, when nobody can foresee what new ccTLD codes may come > to exist in the future? We've seen enough recent examples... Okay, so block all two and three-letter SLDs, under the assumption that if they aren't already valid TLDs, they might become valid TLDs in the future. That would cause problems for ibm.eu, but would guarantee that you can prevent .com.eu from being registered (as one example). However, you'd then also have to block all four-letter SLDs, because there are current TLDs with four letters (.aero and .name). How far would you be willing to take this? -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From tjd-dnswg at phlegethon.org Thu Oct 21 14:01:48 2004 From: tjd-dnswg at phlegethon.org (Tim Deegan) Date: Thu, 21 Oct 2004 13:01:48 +0100 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: References: <5.1.0.14.2.20041021102217.00acdff8@mail.iucc.ac.il> <5.1.0.14.2.20041021125710.055daeb0@imap.cwi.nl> Message-ID: <20041021120148.GF69081@ocelot.phlegethon.org> At 13:53 +0200 on 21 Oct (1098366806), Brad Knowles wrote: > Okay, so block all two and three-letter SLDs, under the > assumption that if they aren't already valid TLDs, they might become > valid TLDs in the future. That would cause problems for ibm.eu, but > would guarantee that you can prevent .com.eu from being registered > (as one example). > > However, you'd then also have to block all four-letter SLDs, > because there are current TLDs with four letters (.aero and .name). ...and six-letter words: .museum :) Blocking just the two-letter SLDs is still a reasonable policy; it solves the problem for the predictable case (ccTLDs). It doesn't prevent collisions with new gTLDs but that's not a reason to drop it entirely. Tim. -- Tim Deegan We were back to the sad age-old knowledge that there are only two genuine aphrodisiacs: youth and boredom. [ Alistair Cooke, "Letter From America", 12/5/98 ] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From Piet.Beertema at cwi.nl Thu Oct 21 14:07:01 2004 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Thu, 21 Oct 2004 14:07:01 +0200 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: References: <5.1.0.14.2.20041021125710.055daeb0@imap.cwi.nl> <5.1.0.14.2.20041021125710.055daeb0@imap.cwi.nl> Message-ID: <5.1.0.14.2.20041021140233.0533ea98@imap.cwi.nl> >> Which is short-sighted. What's the use of blocking only *existing* >> ccTLD codes, when nobody can foresee what new ccTLD codes may come >> to exist in the future? We've seen enough recent examples... > >Okay, so block all two and three-letter SLDs, under the assumption that >if they aren't already valid TLDs, they might become valid TLDs in the >future. That would cause problems for ibm.eu, but would guarantee that >you can prevent .com.eu from being registered (as one example). I wouldn't go that far. I would block all 2-letter codes and the "historical" 3-letter codes. After all there's no rule for (new) generic TLD's. Piet From brad at stop.mail-abuse.org Thu Oct 21 14:12:40 2004 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Thu, 21 Oct 2004 14:12:40 +0200 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: <20041021120148.GF69081@ocelot.phlegethon.org> References: <5.1.0.14.2.20041021102217.00acdff8@mail.iucc.ac.il> <5.1.0.14.2.20041021125710.055daeb0@imap.cwi.nl> <20041021120148.GF69081@ocelot.phlegethon.org> Message-ID: At 1:01 PM +0100 2004-10-21, Tim Deegan wrote: > Blocking just the two-letter SLDs is still a reasonable policy; it > solves the problem for the predictable case (ccTLDs). It doesn't > prevent collisions with new gTLDs but that's not a reason to drop it > entirely. The ISO is going to run out of potential two-letter ccTLDs pretty soon. Two letters only give you 676 possible combinations and there are already almost 300 countries. It won't take too many more name changes or new countries being created out of old ones, before you start running out of possible combinations you can hand out that will have any bearing whatsoever on the actual name of the country. This is the same type of problem you have in most English-speaking countries with the name "smith" and chinese-speaking countries with the name "chang". It's also not unlike the Y2k problem. When they run out of two-letter ccTLDs that they can hand out, what do you think they're going to do? At the very least, any policy that prohibits two-letter SLDs (on the basis of potential conflicts with ccTLDs) should acknowledge this future problem. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From Piet.Beertema at cwi.nl Thu Oct 21 14:24:53 2004 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Thu, 21 Oct 2004 14:24:53 +0200 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: References: <20041021120148.GF69081@ocelot.phlegethon.org> <5.1.0.14.2.20041021102217.00acdff8@mail.iucc.ac.il> <5.1.0.14.2.20041021125710.055daeb0@imap.cwi.nl> <20041021120148.GF69081@ocelot.phlegethon.org> Message-ID: <5.1.0.14.2.20041021141924.00afffc8@imap.cwi.nl> > The ISO is going to run out of potential two-letter ccTLDs pretty >soon. Two letters only give you 676 possible combinations and there are >already almost 300 countries. Which means the number of countries could more than double before ISO would start running into troubles. My guess is that that won't happen in this century, perhaps not even in the next one. And by that time there may be no more ISO, Internet, e-mail etc. And the direct brain-to-brain communication envisaged for that era needs no 2-letter codes. ;-) Piet From tjd-dnswg at phlegethon.org Thu Oct 21 14:32:20 2004 From: tjd-dnswg at phlegethon.org (Tim Deegan) Date: Thu, 21 Oct 2004 13:32:20 +0100 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: References: <5.1.0.14.2.20041021102217.00acdff8@mail.iucc.ac.il> <5.1.0.14.2.20041021125710.055daeb0@imap.cwi.nl> <20041021120148.GF69081@ocelot.phlegethon.org> Message-ID: <20041021123220.GG69081@ocelot.phlegethon.org> At 14:12 +0200 on 21 Oct (1098367960), Brad Knowles wrote: > The ISO is going to run out of potential two-letter ccTLDs pretty > soon. Two letters only give you 676 possible combinations and there are > already almost 300 countries. Good point. I don't think it's the same trade-off, though -- when the number of countries has about tripled, that will still only use 1/26 of the three-letter codes. > At the very least, any policy that prohibits two-letter SLDs (on > the basis of potential conflicts with ccTLDs) should acknowledge this > future problem. How about: "At the present rate-of-change of ISO 3166-1, we must solve the problems mentioned in RFC 1535 at some time in the next six hundred years"? :) Tim. -- Tim Deegan As far back as I can remember, soccer for me has been linked with the absence of purpose and the vanity of all things. [ Umberto Eco, "Faith in Fakes" ] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From brad at stop.mail-abuse.org Thu Oct 21 15:05:12 2004 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Thu, 21 Oct 2004 15:05:12 +0200 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: <5.1.0.14.2.20041021141924.00afffc8@imap.cwi.nl> References: <20041021120148.GF69081@ocelot.phlegethon.org> <5.1.0.14.2.20041021102217.00acdff8@mail.iucc.ac.il> <5.1.0.14.2.20041021125710.055daeb0@imap.cwi.nl> <20041021120148.GF69081@ocelot.phlegethon.org> <5.1.0.14.2.20041021141924.00afffc8@imap.cwi.nl> Message-ID: At 2:24 PM +0200 2004-10-21, Piet Beertema wrote: >> The ISO is going to run out of potential two-letter ccTLDs pretty >>soon. Two letters only give you 676 possible combinations and there are >>already almost 300 countries. > > Which means the number of countries could more than double before > ISO would start running into troubles. Uh, no. Re-read that message again. I'm talking about clustering of names around certain common sequences of characters. Unless you want to hand out the ccTLDs in a totally random fashion, they will start running into collision problems much sooner than that. Most hashing algorithms start having problems when they get close to 50% full. There's no difference here. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From brad at stop.mail-abuse.org Thu Oct 21 15:06:14 2004 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Thu, 21 Oct 2004 15:06:14 +0200 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: <20041021123220.GG69081@ocelot.phlegethon.org> References: <5.1.0.14.2.20041021102217.00acdff8@mail.iucc.ac.il> <5.1.0.14.2.20041021125710.055daeb0@imap.cwi.nl> <20041021120148.GF69081@ocelot.phlegethon.org> <20041021123220.GG69081@ocelot.phlegethon.org> Message-ID: At 1:32 PM +0100 2004-10-21, Tim Deegan wrote: > How about: "At the present rate-of-change of ISO 3166-1, we must solve > the problems mentioned in RFC 1535 at some time in the next six hundred > years"? :) See my other message. This is a problem that is looming much faster than you are giving it credit. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From adamo at central.tee.gr Thu Oct 21 15:59:35 2004 From: adamo at central.tee.gr (Yiorgos Adamopoulos) Date: Thu, 21 Oct 2004 16:59:35 +0300 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: References: <5.1.0.14.2.20041021102217.00acdff8@mail.iucc.ac.il> <5.1.0.14.2.20041021125710.055daeb0@imap.cwi.nl> <20041021120148.GF69081@ocelot.phlegethon.org> Message-ID: <4177C0C7.8030000@central.tee.gr> Brad Knowles wrote: > The ISO is going to run out of potential two-letter ccTLDs pretty > soon. Two letters only give you 676 possible combinations and there are > already almost 300 countries. 650. Countries cannot have two letter identifiers begining with the letter x, so xa ... xz are ruled out. For more you can check: http://www.iso.org/iso/en/prods-services/iso3166ma/index.html > When they run out of two-letter ccTLDs that they can hand out, what > do you think they're going to do? Recycle. IIRC, CS used to symbolise Chechosolvakia (sp?) and now it stands for Serbia & Montenegro. -- Yiorgos Adamopoulos -- adamo at central.tee.gr Technical Chamber of Greece -- #include Work Phone: +30.2103671130 -- FAX: +30.2103671101 From hank at mail.iucc.ac.il Thu Oct 21 16:52:16 2004 From: hank at mail.iucc.ac.il (Hank Nussbacher) Date: Thu, 21 Oct 2004 16:52:16 +0200 (IST) Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: <20041021123220.GG69081@ocelot.phlegethon.org> References: <5.1.0.14.2.20041021102217.00acdff8@mail.iucc.ac.il> <5.1.0.14.2.20041021125710.055daeb0@imap.cwi.nl> <20041021120148.GF69081@ocelot.phlegethon.org> <20041021123220.GG69081@ocelot.phlegethon.org> Message-ID: > > At the very least, any policy that prohibits two-letter SLDs (on > > the basis of potential conflicts with ccTLDs) should acknowledge this > > future problem. > > How about: "At the present rate-of-change of ISO 3166-1, we must solve > the problems mentioned in RFC 1535 at some time in the next six hundred > years"? :) > > Tim. I see an April 1, 2005 RFC lurking here :-) -Hank From brad at stop.mail-abuse.org Thu Oct 21 21:56:40 2004 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Thu, 21 Oct 2004 21:56:40 +0200 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: <4177C0C7.8030000@central.tee.gr> References: <5.1.0.14.2.20041021102217.00acdff8@mail.iucc.ac.il> <5.1.0.14.2.20041021125710.055daeb0@imap.cwi.nl> <20041021120148.GF69081@ocelot.phlegethon.org> <4177C0C7.8030000@central.tee.gr> Message-ID: At 4:59 PM +0300 2004-10-21, Yiorgos Adamopoulos wrote: >> When they run out of two-letter ccTLDs that they can hand out, what >> do you think they're going to do? > > Recycle. IIRC, CS used to symbolise Chechosolvakia (sp?) and now it > stands for Serbia & Montenegro. How long do you have to wait before you recycle? What if recycling still isn't enough to solve the collision problem for a given set of initial characters? -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From brian.nisbet at heanet.ie Fri Oct 22 10:43:22 2004 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Fri, 22 Oct 2004 09:43:22 +0100 Subject: [dns-wg] HEAnet comments on Future of RIPE Hostcount Document Message-ID: <4178C82A.4090001@heanet.ie> Hi, These are some comments that HEAnet would like to submit on the "Future of the RIPE Hostcount" Document presented at RIPE 49. - perhaps the paper should refer to the current distributed nature of the host count; this is something which might or might not be possible with the alternatives suggested - the current host count also gathers the numbers of SOAs, also a measure of the size and growth of the Internet - and the host count also generates an error file per TLD; this could be useful in maintaining the integrity of the DNS - in #2.1, I think attribution should be made to the author of the host program, the late Erik Wassenaar. - in #2.2, it should be said that the RIPE host count is used as a metric of Internet size, and an index of its growth. Certainly, we use it in HEAnet. - it might be argued that the host count also could provide some KPIs (key performance indicators) for RIPE NCC, its members, and other bodies - in #2.3, it mentions used addresses not entered in the DNS. The converse also occurs i.e. A records for hosts which are not reachable. We know that some people use the DNS as a database and that it often includes firewalled machines and even rfc-1918 addresses - in #3, another possibility to estimate the size of the Internet is to measure the number of domains. This might be done by the CC TLDs in Europe, for example Regards, Brian. -- Brian Nisbet, HEAnet, Brooklawn Hse, Crampton Ave, Shelbourne rd, Dublin 4. Tel:+35316609040/Fax:+35316603666 email:brian.nisbet at heanet.ie From huggenberger at gmail.com Fri Oct 22 11:32:10 2004 From: huggenberger at gmail.com (Marco Huggenberger) Date: Fri, 22 Oct 2004 11:32:10 +0200 Subject: [dns-wg] Re: ORSN-SERVERS.NET Message-ID: Hi Folks! Markus Grundman, founder of the ORSN project has asked me to post the following: "Dear list members! ORSN is not transparently enough? Sorry! But I must laughing about this posting. We do provide all needed information for interested users. You must read our homepage carefully before you can write about our project. The independent mode of ORSN was implemented to disable the automatic synchronization of the database. Regards, Markus Grundmann ORSN, Open Root Server Network Germany" A detailed view about network/server transparency is and was always available at: http://european.ch.orsn.net/servers.php If you have any questions about ORSN, please feel free to contact us directly on our mailinglist: http://european.ch.orsn.net/lists.php Cheers Marco Huggenberger Init Seven AG, Switzerland AS13030 Operator of the ORSN Root Server H From mgrundmann at de.orsn.org Fri Oct 22 11:41:05 2004 From: mgrundmann at de.orsn.org (Markus Grundmann/ORSN) Date: Fri, 22 Oct 2004 11:41:05 +0200 Subject: [dns-wg] Re: ORSN-SERVERS.NET Message-ID: <005901c4b81b$40bccf80$6e8392d9@client.hildesheim.wfi.de> >In total 76 instances of a root-server of which are 25 in the >EU, 26 in the US, and 50 outside EU/US. >And this network is growing and growing I'm very happy about this posting ;-) 76 copies of an single database source managed by an organization outside from europe and controlled by the U.S. DOC. Great! When it comes the master corrupt all AnyCast servers will use this information. Very great and very stable! ORSN is an DNS system with all the same information provided by ICANN. The difference: We have our own managed and independent database!!! In few days you will found an tool to compare the ORSN database with the ICANN root servers in realtime on our homepage. Some people wrote (not here): "ORSN is not transparently enough!" Sorry! But I must laughing about this words. We do provide all needed information for interested users. Peoples must read our homepage carefully before any can write this. Notice: The independent mode of ORSN was implemented to disable the automatic synchronization of the database. Regards, Markus Grundmann ORSN, Open Root Server Network Germany From huggenberger at init7.net Fri Oct 22 11:52:45 2004 From: huggenberger at init7.net (Marco Huggenberger) Date: Fri, 22 Oct 2004 11:52:45 +0200 Subject: [dns-wg] Re: ORSN-SERVERS.NET Message-ID: <4178D86D.3020104@init7.net> Hi Folks! Markus Grundman, founder of the ORSN project has asked me to post the following: "Dear list members! ORSN is not transparently enough? Sorry! But I must laughing about this posting. We do provide all needed information for interested users. You must read our homepage carefully before you can write about our project. The independent mode of ORSN was implemented to disable the automatic synchronization of the database. Regards, Markus Grundmann ORSN, Open Root Server Network Germany" A detailed view about network/server transparency is and was always available at: http://european.ch.orsn.net/servers.php If you have any questions about ORSN, please feel free to contact us directly on our mailinglist: http://european.ch.orsn.net/lists.php Cheers Marco Huggenberger Init Seven AG, Switzerland AS13030 Operator of the ORSN Root Server H From pim at bit.nl Fri Oct 22 12:04:51 2004 From: pim at bit.nl (Pim van Pelt) Date: Fri, 22 Oct 2004 10:04:51 +0000 Subject: [dns-wg] Re: ORSN-SERVERS.NET In-Reply-To: <005901c4b81b$40bccf80$6e8392d9@client.hildesheim.wfi.de> References: <005901c4b81b$40bccf80$6e8392d9@client.hildesheim.wfi.de> Message-ID: <20041022100451.GB83473@hog.ipng.nl> Hi Markus, First of all, thanks for your appearance in this forum. | ORSN is an DNS system with all the same information provided by ICANN. | The difference: We have our own managed and independent database!!! That's all great and noble, but as a user I wish to make use of exactly one copy of this data, and that is the one that is provided already by an organisation which has - admittedly - some problems of their own, but none that we can't fix using proper politics. | In few days you will found an tool to compare the ORSN database | with the ICANN root servers in realtime on our homepage. There should not be a difference in the first place. | Notice: | The independent mode of ORSN was implemented to disable the automatic | synchronization of the database. Which makes it possible - at your sole discression (and I happen to have actually read your FAQ) - for you to dictate a new (alternative) dataset. If you want better root presence in Europe, why aren't you offering services to the existing deployment ? It seems like you have some political objection to the root maintainer. Can you elaborate on that (in private or on this mailinglist) ? -- Met vriendelijke groet, BIT BV / Ing P.B. van Pelt PBVP1-RIPE (PGPKEY-4DCA7E5E) From bortzmeyer at nic.fr Fri Oct 22 12:15:54 2004 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 22 Oct 2004 12:15:54 +0200 Subject: [dns-wg] Re: ORSN-SERVERS.NET In-Reply-To: <20041022100451.GB83473@hog.ipng.nl> References: <005901c4b81b$40bccf80$6e8392d9@client.hildesheim.wfi.de> <20041022100451.GB83473@hog.ipng.nl> Message-ID: <20041022101554.GA9173@nic.fr> On Fri, Oct 22, 2004 at 10:04:51AM +0000, Pim van Pelt wrote a message of 30 lines which said: > an organisation which has - admittedly - some problems of their own, > but none that we can't fix using proper politics. Congratulations for your inalterable optimism. Next time I will feel tired or discouraged, I will read again your message. From roy at dnss.ec Fri Oct 22 12:38:25 2004 From: roy at dnss.ec (Roy Arends) Date: Fri, 22 Oct 2004 12:38:25 +0200 (CEST) Subject: [dns-wg] Re: ORSN-SERVERS.NET In-Reply-To: <005901c4b81b$40bccf80$6e8392d9@client.hildesheim.wfi.de> References: <005901c4b81b$40bccf80$6e8392d9@client.hildesheim.wfi.de> Message-ID: On Fri, 22 Oct 2004, Markus Grundmann/ORSN wrote: > >In total 76 instances of a root-server of which are 25 in the > >EU, 26 in the US, and 50 outside EU/US. > > >And this network is growing and growing > > I'm very happy about this posting ;-) Y'welcome. > 76 copies of an single database source managed by an organization > outside from europe and controlled by the U.S. DOC. Great! No, just sanctioned by ICANN. Different organisations manage these boxes, and they do this very well. > When it comes the master corrupt all AnyCast servers will use this > information. Very great and very stable! If data in the database becomes corrupt, ORSN's data will become corrupt as well. ORSN's copy of the root-zone file is downloaded by ftp once a day from ICANN. Note that every ICANN sanctioned root is updated twice per day. While changes occur in the ICANN sanctioned root-zone, it takes in worst case a day before the ORSN root-zone is updated. > ORSN is an DNS system with all the same information provided by ICANN. > The difference: We have our own managed and independent database!!! You can't have it both ways. Either you have an independent root-zone, or it is ICANN based. If you have any technical concerns about the database management of the ICANN sanctioned servers, then you would have a point if the argument would be valid. It seems to me however you have political concerns with regards to database management (as in who manages the CONTENT of the root-zone). Then why copy the ICANN source ? IMHO it is really not in the best interest in ORSN to spread fear, uncertainty and doubt wrt database management, while blindly serving the ICANN source published on ftp://rs.internic.net/domain/root.zone.gz But be assured. The folks at ISI, ISC, Autonomica, RIPE, WIDE, etc, etc, who publish the ICANN sanctioned root-zone are very critical and concerned with process, procedures and policy around the root. They take their technical concerns to IETF workgroups. Publish informationals and standards endorsed by ISOC, organise workshops at NANOG, RIPE, ARIN (etc, etc) meetings. They are open, transparant, approachable, visible and at times very loud when in their view ICANN, or any associated party crosses some line somewhere. In fact, they all take part in the DNS Root Server System Advisory Commitee to make sure their concerns are heard. Ofcourse you could start your own root. Then again, you could go driving backwards on the opposite side of the road, and convince some to do the same. Roy From mgrundmann at de.orsn.org Fri Oct 22 13:26:13 2004 From: mgrundmann at de.orsn.org (Markus Grundmann/ORSN) Date: Fri, 22 Oct 2004 13:26:13 +0200 Subject: [dns-wg] Re: ORSN-SERVERS.NET References: <005901c4b81b$40bccf80$6e8392d9@client.hildesheim.wfi.de> Message-ID: <00aa01c4b829$f0aebd50$6e8392d9@client.hildesheim.wfi.de> > Y'welcome. Thanks and thank you for the reply. > No, just sanctioned by ICANN. Different organisations manage these boxes, > and they do this very well. Really? I think the boxes are closed and only the hardware was managed by the operator. That's my information. The root zone will provided by "ICANN" or not? > If data in the database becomes corrupt, ORSN's data will become corrupt > as well. ORSN's copy of the root-zone file is downloaded by ftp once a day > from ICANN. That is not completely correct . Yes we load the root zone with ftp, but the additional way is the synchronization by DNS queries (Alpha version). We have some reference tables in our database to check the current root zone provided by ICANN. Only a real person can start the rebuild when ORSN is in independent mode and all checks are completed. > Note that every ICANN sanctioned root is updated twice per day. While > changes occur in the ICANN sanctioned root-zone, it takes in worst case a > day before the ORSN root-zone is updated. We wait some hours before the ICANN root zone go online. Two TLDs are based on XML exchanges (see TDE on our homepage) and this data overrides the ICANN root zone. > You can't have it both ways. Either you have an independent root-zone, or > it is ICANN based. If you have any technical concerns about the > database management of the ICANN sanctioned servers, then you would have a > point if the argument would be valid. It seems to me however you have > political concerns with regards to database management (as in who manages Yes! ORSN has an political background but I think that is not bad. Projects like ORSC (*ggrr*) undermines DNS. ! And not ORSN ! We are only the european (independent) copy of the stable ICANN root server system :-)) > the CONTENT of the root-zone). Then why copy the ICANN source ? IMHO it is > really not in the best interest in ORSN to spread fear, uncertainty and > doubt wrt database management, while blindly serving the ICANN source > published on ftp://rs.internic.net/domain/root.zone.gz You have right but see above. > some line somewhere. In fact, they all take part in the DNS Root Server > System Advisory Commitee to make sure their concerns are heard. I hope this ... for the internet community! > > Ofcourse you could start your own root. Then again, you could go driving > backwards on the opposite side of the road, and convince some to do the > same. *g* ... In January 2005 ORSN has its third birthday. We already began. Regards, Markus From roy at dnss.ec Fri Oct 22 16:24:21 2004 From: roy at dnss.ec (Roy Arends) Date: Fri, 22 Oct 2004 16:24:21 +0200 (CEST) Subject: [dns-wg] Re: ORSN-SERVERS.NET In-Reply-To: <00aa01c4b829$f0aebd50$6e8392d9@client.hildesheim.wfi.de> References: <005901c4b81b$40bccf80$6e8392d9@client.hildesheim.wfi.de> <00aa01c4b829$f0aebd50$6e8392d9@client.hildesheim.wfi.de> Message-ID: On Fri, 22 Oct 2004, Markus Grundmann/ORSN wrote: > > No, just sanctioned by ICANN. Different organisations manage these boxes, > > and they do this very well. > > Really? I think the boxes are closed and only the hardware was managed by > the operator. That's my information. No. The infrastructure is the responsibility of the operating organisation. This includes the software brands/versions. There are root-servers running BIND 8, BIND 9 and NSD. The data that constitutes the root-zone (used by ORSN as well) comes from ICANN. Thats it as far ass ICANN is concerned. Roy From niall.oreilly at ucd.ie Fri Oct 22 13:36:45 2004 From: niall.oreilly at ucd.ie (Niall O'Reilly) Date: Fri, 22 Oct 2004 12:36:45 +0100 Subject: [dns-wg] HEAnet comments on Future of RIPE Hostcount Document In-Reply-To: <4178C82A.4090001@heanet.ie> References: <4178C82A.4090001@heanet.ie> Message-ID: On 22 Oct 2004, at 09:43, Brian Nisbet wrote: > - in #3, another possibility to estimate the size of the Internet > is to measure the number of domains. This might be done by the CC > TLDs in Europe, for example It's worth bearing in mind that different estimators (or metrics) may give different pictures, especially with regard to trends. For this reason, I would suggest considering the various possibilities as complementary to one another rather than as alternatives. Best regards, Niall O'Reilly PGP key ID: AE995ED9 (see www.pgp.net) Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9 From jefsey at jefsey.com Fri Oct 22 17:36:49 2004 From: jefsey at jefsey.com (JFC (Jefsey) Morfin) Date: Fri, 22 Oct 2004 17:36:49 +0200 Subject: [dns-wg] Re: ORSN-SERVERS.NET In-Reply-To: References: <005901c4b81b$40bccf80$6e8392d9@client.hildesheim.wfi.de> <00aa01c4b829$f0aebd50$6e8392d9@client.hildesheim.wfi.de> Message-ID: <6.1.2.0.2.20041022162716.0464edb0@mail.jefsey.com> At 16:24 22/10/2004, Roy Arends wrote: >The data that constitutes the root-zone (used by ORSN as well) comes from >ICANN. Thats it as far ass ICANN is concerned. Untrue. There are at least four real root zones origins: - the ICANN/NTIA root file used in the ICANN name servers - the ICANN/NTIA root file used in ORSN machines after verification and possible addition par cooperating ccTLDs - the RSSAC added IPv6 addresses which are under implementation (?) - the TLD Managers information added through their db.files when denied/slowed down by ICANN jfc morfin From pk at TechFak.Uni-Bielefeld.DE Fri Oct 22 17:57:36 2004 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Fri, 22 Oct 2004 17:57:36 +0200 Subject: [dns-wg] Re: ORSN-SERVERS.NET In-Reply-To: Your message of "Fri, 22 Oct 2004 17:36:49 +0200." <6.1.2.0.2.20041022162716.0464edb0@mail.jefsey.com> Message-ID: <200410221557.i9MFvbE24167@grimsvotn.TechFak.Uni-Bielefeld.DE> "JFC (Jefsey) Morfin" wrote: > - the RSSAC added IPv6 addresses which are under implementation (?) last time I looked those were not only not yet added to the root zone but also absent from the root-servers.net zone, which is (inofficially) authoritatively available from all 13 root servers. > - the TLD Managers information added through their db.files when > denied/slowed down by ICANN Which TLDs (other than ARPA and MIL) do the root nameservers serve or how do TLD Managers change the root zone content? -Peter From randy at psg.com Fri Oct 22 19:06:20 2004 From: randy at psg.com (Randy Bush) Date: Fri, 22 Oct 2004 10:06:20 -0700 Subject: [dns-wg] Re: ORSN-SERVERS.NET References: <005901c4b81b$40bccf80$6e8392d9@client.hildesheim.wfi.de> <00aa01c4b829$f0aebd50$6e8392d9@client.hildesheim.wfi.de> <6.1.2.0.2.20041022162716.0464edb0@mail.jefsey.com> Message-ID: <16761.15884.910520.134976@ran.psg.com> > Untrue. There are at least four real root zones origins: the number of zones you see is roughly proportional to the amount of koolaid you're drinking From jefsey at jefsey.com Sat Oct 23 03:19:09 2004 From: jefsey at jefsey.com (JFC (Jefsey) Morfin) Date: Sat, 23 Oct 2004 03:19:09 +0200 Subject: [dns-wg] Re: ORSN-SERVERS.NET In-Reply-To: <16761.15884.910520.134976@ran.psg.com> References: <005901c4b81b$40bccf80$6e8392d9@client.hildesheim.wfi.de> <00aa01c4b829$f0aebd50$6e8392d9@client.hildesheim.wfi.de> <6.1.2.0.2.20041022162716.0464edb0@mail.jefsey.com> <16761.15884.910520.134976@ran.psg.com> Message-ID: <6.1.2.0.2.20041023025627.0445d0f0@mail.jefsey.com> At 19:06 22/10/2004, Randy Bush wrote: > > Untrue. There are at least four real root zone origins: > >the number of zones you see is roughly proportional to the >amount of koolaid you're drinking Dear Randy, I am not sure that koolaid fits your intended meaning. Beaujolais is probably what you intended to say :-) Now, please reread what I wrote (I corrected the typo but the meaning was clear). There is only one real root zone (the root servers and legacy first level name servers). I repeat there are many origins (or contributions if you like - or pollution in ICANN, RSSAC terms?) to that real root zone. Less than two hours ago there were 1312 name servers in the ICANN/NTIA root file and 1443 in the first level zone (10.0 % discrepancy). But I may miss some. jfc From iljitsch at muada.com Sun Oct 24 12:52:21 2004 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sun, 24 Oct 2004 12:52:21 +0200 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: References: <20041021120148.GF69081@ocelot.phlegethon.org> <5.1.0.14.2.20041021102217.00acdff8@mail.iucc.ac.il> <5.1.0.14.2.20041021125710.055daeb0@imap.cwi.nl> <20041021120148.GF69081@ocelot.phlegethon.org> <5.1.0.14.2.20041021141924.00afffc8@imap.cwi.nl> Message-ID: On 21-okt-04, at 15:05, Brad Knowles wrote: >>> The ISO is going to run out of potential two-letter ccTLDs >>> pretty >>> soon. Two letters only give you 676 possible combinations and there >>> are >>> already almost 300 countries. >> Which means the number of countries could more than double before >> ISO would start running into troubles. > Uh, no. Re-read that message again. I'm talking about clustering of > names around certain common sequences of characters. Unless you want > to hand out the ccTLDs in a totally random fashion, they will start > running into collision problems much sooner than that. It seems rather excessive to me to tell organizations such as IBM, NEC, JVC, MIT, JPL etc. that they can't register their name as a domain because in the future existing countries might want to rename / new ones may be formed and have ample choice of the abbreviation they get to use. > Most hashing algorithms start having problems when they get close to > 50% full. There's no difference here. No, except that this isn't a hash function. Besides, 2 character codes can easily be extended by allowing 0-9 as the second character, allowing for 936 combinations, which should be enough for a long time to come. And it's ISO's problem, not ours, anyway. Just curious: does anyone know how many gb/uk-like cases there are? From iljitsch at muada.com Sun Oct 24 13:05:47 2004 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sun, 24 Oct 2004 13:05:47 +0200 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: References: <5.1.0.14.2.20041021102217.00acdff8@mail.iucc.ac.il> Message-ID: On 21-okt-04, at 11:05, Brad Knowles wrote: > Nevertheless, given the size of the population of the expanded EU, I > don't see how this kind of scheme will scale well to handle > potentially hundreds of millions of people. I don't think you > necessarily need to go to a US-style city.county.state.us mechanism, > but I think a three-level domain scheme would definitely be advisable. It is extremely unlikely that this will provide any benefits, as I don't see how it would be possible to make the largest subdomain of .eu at least an order of magnitude smaller than .eu as a whole, without defeating the purpose of having a Europe-wide TLD in the first place. For instance, see http://www.nominet.org.uk/Statistics/RegistrationStatistics/ Around 90% of all registered .uk domains are .co.uk domains. From brad at stop.mail-abuse.org Sun Oct 24 15:50:23 2004 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Sun, 24 Oct 2004 15:50:23 +0200 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: References: <20041021120148.GF69081@ocelot.phlegethon.org> <5.1.0.14.2.20041021102217.00acdff8@mail.iucc.ac.il> <5.1.0.14.2.20041021125710.055daeb0@imap.cwi.nl> <20041021120148.GF69081@ocelot.phlegethon.org> <5.1.0.14.2.20041021141924.00afffc8@imap.cwi.nl> Message-ID: At 12:52 PM +0200 2004-10-24, Iljitsch van Beijnum wrote: >> Most hashing algorithms start having problems when they get close to >> 50% full. There's no difference here. > > No, except that this isn't a hash function. True, but that doesn't change the nature of the problem. > Besides, 2 character codes can easily be extended by allowing 0-9 as > the second character, allowing for 936 combinations, which should be > enough for a long time to come. And it's ISO's problem, not ours, anyway. It's a problem that the ISO has created, but one we will have to live with. At the very least, we need to keep in mind upcoming future problems. The reason Y2k wasn't much of a problem was that people saw the issue looming, and many people around the world worked their butts off over a multi-year period of time to help ensure that everything would go smoothly. And overall, it did go reasonably smoothly. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From brad at stop.mail-abuse.org Sun Oct 24 15:58:15 2004 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Sun, 24 Oct 2004 15:58:15 +0200 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: References: <5.1.0.14.2.20041021102217.00acdff8@mail.iucc.ac.il> Message-ID: At 1:05 PM +0200 2004-10-24, Iljitsch van Beijnum wrote: > For instance, see >http://www.nominet.org.uk/Statistics/RegistrationStatistics/ > Around 90% of all registered .uk domains are .co.uk domains. Anyone know what the distribution of company sizes are for those registrations? I ask because, at least in Belgium/France/Netherlands there are two overall types of companies that you can create -- SA/NV and sprl/bvba. Pretty much anyone can create an sprl/bvba company, but there are some pretty hard requirements you have to fulfill before you can legally incorporate as an SA/NV. If this distinction was made at the registry level (as well as others), this might help break things into more manageable chunks. This is just one idea, of course. I'm sure that there are many others which might be interesting, if only you'd give people a chance to discuss them before shutting them down. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From Piet.Beertema at cwi.nl Sun Oct 24 16:56:03 2004 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Sun, 24 Oct 2004 16:56:03 +0200 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: References: <5.1.0.14.2.20041021102217.00acdff8@mail.iucc.ac.il> Message-ID: <5.1.0.14.2.20041024164950.033b2a48@imap.cwi.nl> >> For instance, see >> http://www.nominet.org.uk/Statistics/RegistrationStatistics/ >> Around 90% of all registered .uk domains are .co.uk domains. > > Anyone know what the distribution of company sizes are for those >registrations? Company sizes have nothing to do with domain names. > I ask because, at least in Belgium/France/Netherlands there are two >overall types of companies that you can create -- SA/NV and sprl/bvba. In any case there are 4+2 in Holland: NV, CV, BV and eenmanszaak (plc); stichting (foundation) and vereniging (society). They have in common that they're all registered with the KvK (Chamber of Commerce). >If this distinction was made at the registry level (as well as others), >this might help break things into more manageable chunks. It would reduce the perceived problem from one zillion to half a zillion. Piet From jim at rfc1035.com Sun Oct 24 17:46:51 2004 From: jim at rfc1035.com (Jim Reid) Date: Sun, 24 Oct 2004 16:46:51 +0100 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: Message-ID: <2097.1098632811@gromit.rfc1035.com> >> If this distinction was made at the registry level (as well as >> others), this might help break things into more manageable chunks. Can you please explain? I must be missing something. Is anyone saying that large, flat zones are somehow unmanageable? Sure, doing this with BIND for huge zones is clumsy. However the trend seems to be for using database back-ends to feed the name servers: BIND-DLZ, UltraDNS, ATLAS, ANS, PowerDNS, etc, etc. A database is the right solution for this problem when there's lots of data to look after. Most registries are already using a database for their customer data so it should be a no-brainer to couple that to their name servers. Just think of all the legacy perl and SQL scripts that could be eliminated..... I don't understand why partitioning the name space is going to help. The same data management problems will remain. IMO, they are a function of the amount of data that's under management, not the number of zone files that data gets stored in. Unless of course you're suggesting there should be discrete registries for second- or even third-level domains. From Piet.Beertema at cwi.nl Sun Oct 24 18:08:16 2004 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Sun, 24 Oct 2004 18:08:16 +0200 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: <2097.1098632811@gromit.rfc1035.com> References: Message-ID: <5.1.0.14.2.20041024175932.00afb5a0@imap.cwi.nl> >I don't understand why partitioning the name space is going to help. It isn't. Partioning name space is applying yesterday's "solutions" to tomorrow's problems. Even worse: to tomorrow's *perceived* problems. See my previous reply: there's no reason to assume that the .eu TLD will explode. Piet P.S. Lets see if this mail does reach you, Jim... From Piet.Beertema at cwi.nl Sun Oct 24 18:10:33 2004 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Sun, 24 Oct 2004 18:10:33 +0200 Subject: [dns-wg] Fwd: Mail delivery failed: returning message to sender Message-ID: <5.1.0.14.2.20041024180924.033b2a48@imap.cwi.nl> No comment... Piet ----- Forwarded Message ----- This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: jim at rfc1035.com SMTP error from remote mailer after MAIL FROM:: host gromit.rfc1035.com [195.54.233.67]: 550 5.0.0 Mail from spammers is refused - get lost. ----- End of Forwarded Message ----- From td at nominet.org.uk Sun Oct 24 19:47:01 2004 From: td at nominet.org.uk (Jay Daley) Date: Sun, 24 Oct 2004 18:47:01 +0100 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: Message-ID: Brad Brad wrote on 24/10/2004 02:58:15 pm: > At 1:05 PM +0200 2004-10-24, Iljitsch van Beijnum wrote: > > > For instance, see > >http://www.nominet.org.uk/Statistics/RegistrationStatistics/ > > Around 90% of all registered .uk domains are .co.uk domains. > > Anyone know what the distribution of company sizes are for those > registrations? > We have not been asking for those details for long enough to have a firm answer. In addition we suspect there is some distortion caused by companies that put themselves down as private individuals in order to opt-out of the whois. Maybe in a year or so we might be able to start publishing those figures, after we go through a major data restructuring exercise.. BTW we breakdown the organisational type into 13 different categories! Jay From td at nominet.org.uk Sun Oct 24 20:13:28 2004 From: td at nominet.org.uk (Jay Daley) Date: Sun, 24 Oct 2004 19:13:28 +0100 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: <2097.1098632811@gromit.rfc1035.com> Message-ID: Jim Jim wrote on 24/10/2004 04:46:51 pm: > However the trend seems to be for using > database back-ends to feed the name servers: BIND-DLZ, UltraDNS, > ATLAS, ANS, PowerDNS, etc, etc. A database is the right solution for > this problem when there's lots of data to look after. Most registries > are already using a database for their customer data so it should be a > no-brainer to couple that to their name servers. Just think of all the > legacy perl and SQL scripts that could be eliminated..... > I'm not so sure that I agree with this. I think there is quite a lot to think about here and databases are not necessarily the best solution. The reasoning goes like this: - You don't want all of your database data replicated to each node, that would be pointless, just the data required to fill the zones. This is actually a very small fraction of the data we (and most registries?) hold. So you then end up with a database system on each nameserver for a relatively small amount of information and almost all of the functionality of the database is not used. - You then have to manage another system on each nameserver, and that brings with it a new set of dependencies and vulnerabilities, that you could just as easily do without. Out view has always been to minimise the number of unnecessary processes on any production nameserver. - Then of course there is the replication process. Some databases are good but IXFR is uniquely designed for nameservers. Having the replication process so closely tied to the database concerns me that problems with that process that require it to be fixed can lead to unneeded downtime on your main database. If each of your nameservers instances is going to have multiple heads then you might get better performance with a database backend serving all those heads rather than relying on nameserver replication, but I've not done the tests. Some of this is, of course, supposition so I would be interested to know if anyone else thinks using database in this way is simple. Jay From jim at rfc1035.com Sun Oct 24 21:07:36 2004 From: jim at rfc1035.com (Jim Reid) Date: Sun, 24 Oct 2004 20:07:36 +0100 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: Message from Jay Daley of "Sun, 24 Oct 2004 19:13:28 BST." Message-ID: <2295.1098644856@gromit.rfc1035.com> >>>>> "Jay" == Jay Daley writes: >> However the trend seems to be for using database back-ends to >> feed the name servers: BIND-DLZ, UltraDNS, ATLAS, ANS, >> PowerDNS, etc, etc. A database is the right solution for this >> problem when there's lots of data to look after. Most >> registries are already using a database for their customer data >> so it should be a no-brainer to couple that to their name >> servers. Just think of all the legacy perl and SQL scripts that >> could be eliminated..... Jay> I'm not so sure that I agree with this. I think there is Jay> quite a lot to think about here and databases are not Jay> necessarily the best solution. Jay, I think you have misunderstood me. Or I didn't make myself clear enough. You're quite right. Using a database back-end for DNS service introduces a lot of interesting issues such as throughout, how replication gets done, consistency between the database and any in-core cache, the database becoming a SPoF, etc, etc. However the initial discussion was about restructuring the name space because large flat zone files were felt to be harder to manage than introducing second- or third-level domains. In that context the problem is essentially one of data management. Which would already be handled by the database that any sizeable registry will be using for their customer data. That said, I do believe that huge text files for zone files and name server configurations will eventually move to some sort of database back-end. This is the direction that most DNS implementations seem to be moving towards. Some TLDs have already adopted this approach and I'd be surprised if others didn't follow. From td at nominet.org.uk Sun Oct 24 21:57:21 2004 From: td at nominet.org.uk (Jay Daley) Date: Sun, 24 Oct 2004 20:57:21 +0100 Subject: [dns-wg] Re: ORSN-SERVERS.NET In-Reply-To: <00aa01c4b829$f0aebd50$6e8392d9@client.hildesheim.wfi.de> Message-ID: Markus Markus wrote on 22/10/2004 12:26:13 pm: > We are only the > european (independent) copy of the stable ICANN root server system :-)) I really do not understand this. How are you in anyway more independent than k-root or i-root? Jay From adamo at central.tee.gr Mon Oct 25 15:23:37 2004 From: adamo at central.tee.gr (Yiorgos Adamopoulos) Date: Mon, 25 Oct 2004 16:23:37 +0300 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: References: Message-ID: <417CFE59.30608@central.tee.gr> Jay Daley wrote: [ most of the message snipped ] > - You then have to manage another system on each nameserver, and that > brings with it a new set of dependencies and vulnerabilities, that you > could just as easily do without. Out view has always been to minimise the > number of unnecessary processes on any production nameserver. > > Some of this is, of course, supposition so I would be interested to know > if anyone else thinks using database in this way is simple. Well for the moment we are using a flat-file "database" that is going to be moved to Oracle in the next 4 months (as part of many other things integrated to it). Actually you do not have to run a database instance on every node where you want to run a DNS server. Why not have the Database system produce the zone files for the nameserver of your taste (be it NSD, tinydns, BIND, etc) and then rsync to the actual servers? -- Yiorgos Adamopoulos -- adamo at central.tee.gr Technical Chamber of Greece -- #include Work Phone: +30.2103671130 -- FAX: +30.2103671101 From brad at stop.mail-abuse.org Mon Oct 25 16:29:39 2004 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Mon, 25 Oct 2004 16:29:39 +0200 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: <417CFE59.30608@central.tee.gr> References: <417CFE59.30608@central.tee.gr> Message-ID: At 4:23 PM +0300 2004-10-25, Yiorgos Adamopoulos wrote: > Actually you do not have to run a database instance > on every node where you want to run a DNS server. Why not have the > Database system produce the zone files for the nameserver of your taste > (be it NSD, tinydns, BIND, etc) and then rsync to the actual servers? Well, for NSD, using large zones will cause it to eat memory exponentially. It pre-calculates all possible questions and all possible answers before it loads the zone(s), and then creates a jump table. I remember at RIPE 44 that we got a report from the folks up at SUNET, who had tried using NSD to serve the ccTLDs they handle, and even though it was a monster machine with many gigabytes of memory, that still wasn't enough. BIND will probably be better in this respect, but I doubt it's going to be manageable, either. If you're bound and determined to go with a completely flat namespace for what will be the largest TLD in the world (Europe already has more citizens than the US, more citizens online than the US, and a faster growth rate than the US), then I think you have no option but to go with a database back-end for operations as well as maintenance. Sure, in a few years the Chinese or Indians may take over the #1 position (since both countries have unbelievable growth rates and over one billion population each), but that's still several years away and they can always look at whatever solution Europe has pioneered to handle these extremely large ultra-flat zones. Of course, your operational database could be trimmed to just the absolutely necessary information and loaded non-real time from the maintenance database which does include all the desired information, but that's still going to be a big database. I doubt that you're going to have any practical option but to use ANS from Nominum. NSD certainly isn't going to cut it, PowerDNS certainly won't cut it, I don't think that BIND will have the necessary high-reliability interfaces, and I don't know of any other large-scale database back-end nameservers (dlz-bind is a nice toy, but certainly won't be able to scale to this kind of level). That is, unless you want to hand everything over to someone else to operate as a service for you -- like UltraDNS. Oh, wait -- they bought the business from Nominum, who was using ANS for their customers, and UltraDNS almost certainly still using ANS today.... -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From jim at rfc1035.com Mon Oct 25 17:04:01 2004 From: jim at rfc1035.com (Jim Reid) Date: Mon, 25 Oct 2004 16:04:01 +0100 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: Message from Brad Knowles of "Mon, 25 Oct 2004 16:29:39 +0200." Message-ID: <4001.1098716641@gromit.rfc1035.com> >>>>> "Brad" == Brad Knowles writes: Brad> Oh, wait -- they bought the business from Nominum, who Brad> was using ANS for their customers, and UltraDNS almost Brad> certainly still using ANS today.... Sorry Brad you are quite wrong. UltraDNS have never used Nominum's ANS. However there was a brief transition period after the GNS hosting business was sold when GNS customers still used its ANS-based service until they got migrated to the UltraDNS platform. Even then, I'm fairly sure that Nominum remained in control of the GNS infrastructure throughout that migration exercise. My understanding was that UltraDNS was primarily interested in the GNS customer base. Besides, since they already had their own DNS implementation they had no real need for Nominum's ANS. UltraDNS didn't need the GNS infrastructure either, since they already had their own. To the best of my knowledge UltraDNS has always run its hosting service on its own DNS implementation. From Piet.Beertema at cwi.nl Mon Oct 25 18:14:28 2004 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Mon, 25 Oct 2004 18:14:28 +0200 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: References: <417CFE59.30608@central.tee.gr> <417CFE59.30608@central.tee.gr> Message-ID: <5.1.0.14.2.20041025181033.050c90f0@imap.cwi.nl> > If you're bound and determined to go with a completely flat >namespace for what will be the largest TLD in the world (Europe >already has more citizens than the US, more citizens online than >the US, and a faster growth rate than the US) Why do you keep ignoring the existence of ccTLD's in Europe? Plus the fact that a generic, worldwide and *flat* TLD like .com still hasn't grown such as to become unmanageable? Piet From jakob at rfc.se Mon Oct 25 19:08:33 2004 From: jakob at rfc.se (Jakob Schlyter) Date: Mon, 25 Oct 2004 19:08:33 +0200 (CEST) Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: References: <417CFE59.30608@central.tee.gr> Message-ID: On Mon, 25 Oct 2004, Brad Knowles wrote: > Oh, wait -- they bought the business from Nominum, who was using > ANS for their customers, and UltraDNS almost certainly still using ANS > today.... # perl fpdns.pl udns1.ultradns.net udns2.ultradns.net fingerprint (udns1.ultradns.net, 204.69.234.1): UltraDNS v2.7.0.2 -- 2.7.3 fingerprint (udns2.ultradns.net, 204.74.101.1): UltraDNS v2.7.0.2 -- 2.7.3 jakob From brad at stop.mail-abuse.org Mon Oct 25 20:56:17 2004 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Mon, 25 Oct 2004 20:56:17 +0200 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: <4001.1098716641@gromit.rfc1035.com> References: <4001.1098716641@gromit.rfc1035.com> Message-ID: At 4:04 PM +0100 2004-10-25, Jim Reid wrote: > To the best of my knowledge UltraDNS has always run its hosting > service on its own DNS implementation. Okay, fair enough -- there is another DNS management service to whom this sort of thing could be outsourced. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From brad at stop.mail-abuse.org Mon Oct 25 21:03:33 2004 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Mon, 25 Oct 2004 21:03:33 +0200 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: <5.1.0.14.2.20041025181033.050c90f0@imap.cwi.nl> References: <417CFE59.30608@central.tee.gr> <417CFE59.30608@central.tee.gr> <5.1.0.14.2.20041025181033.050c90f0@imap.cwi.nl> Message-ID: At 6:14 PM +0200 2004-10-25, Piet Beertema wrote: > Why do you keep ignoring the existence of ccTLD's in Europe? What on $DEITY's green earth makes you think that I'm ignoring the existence of ccTLDs in Europe?!? I have been talking about nothing *but* ccTLDs in Europe, and how this flat namespace model will not continue to scale. > Plus the fact that a generic, worldwide and *flat* TLD like > .com still hasn't grown such as to become unmanageable? It has grown to the point where it is not manageable. It was unmanageable a long time ago, and things have been going further down the toilet ever since. And you're going to have a problem that will be an order of magnitude larger than .com. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From brad at stop.mail-abuse.org Mon Oct 25 21:06:22 2004 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Mon, 25 Oct 2004 21:06:22 +0200 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: References: <417CFE59.30608@central.tee.gr> Message-ID: At 7:08 PM +0200 2004-10-25, Jakob Schlyter wrote: > # perl fpdns.pl udns1.ultradns.net udns2.ultradns.net > fingerprint (udns1.ultradns.net, 204.69.234.1): UltraDNS v2.7.0.2 -- 2.7.3 > fingerprint (udns2.ultradns.net, 204.74.101.1): UltraDNS v2.7.0.2 -- 2.7.3 That doesn't necessarily mean anything. If they had been a large customer of Nominum, they could easily be running code that generated a different fingerprint. When it comes to this sort of thing, I trust information from people who have extensive background information (such as Jim) than I do fingerprints. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From jim at rfc1035.com Mon Oct 25 22:28:13 2004 From: jim at rfc1035.com (Jim Reid) Date: Mon, 25 Oct 2004 21:28:13 +0100 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: Message from Brad Knowles of "Mon, 25 Oct 2004 21:03:33 +0200." Message-ID: <4491.1098736093@gromit.rfc1035.com> >>>>> "Brad" == Brad Knowles writes: Brad> I have been talking about nothing *but* ccTLDs in Brad> Europe, and how this flat namespace model will not continue Brad> to scale. Brad, you're being silly. The only real constraint on scaling will be the availablity of names to register. That is inherently self-correcting by the market place. People will register names in a given TLD for as long as they perceive those registrations to have some meaning and value. Whether that limit is reached after 1 name or 1 billion names is irrelevant. Sure, as the registrations increase, the operational problems and data management issues for the registry will increase. But so too will the amount of money and other resources needed to solve those problems. >> Plus the fact that a generic, worldwide and *flat* TLD like >> .com still hasn't grown such as to become unmanageable? Brad> It has grown to the point where it is not manageable. Brad> It was unmanageable a long time ago, and things have been Brad> going further down the toilet ever since. This will come as a big surprise to the tens of thousands of people who register or renew .com domain names every day. And to the folk at Verisign's registry. FYI, the gtld-servers.net run ATLAS, Verisign's own DNS implementation. It has a database back-end and does multi-site replication. Rapid propagation of changes is easy. Verisign no longer generate a 1-2 Gb zone file and load it into BIND servers twice a day. If they did, your point about the manageability of .com might have some credence. Brad> And you're going to have a problem that will be an Brad> order of magnitude larger than .com. So what? To get to that problem, the zone would have to have an order of magnitude more registrations than .com has today. Assuming .eu was ever be that popular, which is at best a highly debatable assumption. Let's do some back of the envelope calculations. A zone that was an order of magnitude as big as .com would have around 200M entries. At 5 Euro/registration/year -- comparable to the wholesale prices most TLD registries charge today -- this would yield an annual income of 1B Euro. With that amount of money at the .eu registry's disposal, any hardware or software limitations in their DNS (related) operations could be solved from petty cash. I can't be alone in wanting to have as little as 1% of that sort of budget to solve DNS problems. :-) From jim at rfc1035.com Mon Oct 25 22:39:35 2004 From: jim at rfc1035.com (Jim Reid) Date: Mon, 25 Oct 2004 21:39:35 +0100 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: Message from Brad Knowles of "Mon, 25 Oct 2004 21:06:22 +0200." Message-ID: <4513.1098736775@gromit.rfc1035.com> >>>>> "Brad" == Brad Knowles writes: >> # perl fpdns.pl udns1.ultradns.net udns2.ultradns.net >> fingerprint (udns1.ultradns.net, 204.69.234.1): UltraDNS v2.7.0.2 -- 2.7.3 >> fingerprint (udns2.ultradns.net, 204.74.101.1): UltraDNS v2.7.0.2 -- 2.7.3 Brad> That doesn't necessarily mean anything. If they had Brad> been a large customer of Nominum, they could easily be Brad> running code that generated a different fingerprint. Nope. Roy and Jakob's tool can already fingerprint Nominum's DNS implementations. And just about anyone else's for that matter. Besides, I very much doubt if anyone would create a code fork and all the aggravation flowing from that -- support overheads, regression testing, documentation, software maintenance, etc -- just to confuse a fingerprinting tool. And of course the tool could easily be updated to take account of any obfuscation like that. Why would anyone choose to enter that zero-sum game? Brad> When it comes to this sort of thing, I trust Brad> information from people who have extensive background Brad> information (such as Jim) than I do fingerprints. You'll be much better off to trust this fingerprinting tool than depend on my memory. :-) From brad at stop.mail-abuse.org Mon Oct 25 22:48:45 2004 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Mon, 25 Oct 2004 22:48:45 +0200 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: <4513.1098736775@gromit.rfc1035.com> References: <4513.1098736775@gromit.rfc1035.com> Message-ID: At 9:39 PM +0100 2004-10-25, Jim Reid wrote: > Nope. Roy and Jakob's tool can already fingerprint Nominum's DNS > implementations. And just about anyone else's for that matter. I know about fpdns.pl. I was using it before it was officially released. Early discussions with Roy lead to the very gross fingerprinting methods I used in my DNS Comparison presentation that I gave at LISA 2002 and RIPE 44. None of that is to say that someone couldn't come along and make some modifications to the code that one of these programs runs, which would result in a different fingerprint being generated. If they then called this program by a totally different name, it might not be easy to tell that it's just a relatively minor modification to an existing program already in the database. > Besides, > I very much doubt if anyone would create a code fork and all the > aggravation flowing from that -- support overheads, regression > testing, documentation, software maintenance, etc -- just to confuse a > fingerprinting tool. It wouldn't necessarily take a big change in the code to result in a change to the fingerprint. If a customer is large enough and pays enough money, who's to say that even large changes wouldn't be made to the code, if the customer requested them? > And of course the tool could easily be updated to > take account of any obfuscation like that. Why would anyone choose to > enter that zero-sum game? Sure, but you have to know that there is obfuscation before you can try to compensate for it. So long as word never got out, people would not necessarily be likely to figure out what's going on. > You'll be much better off to trust this fingerprinting tool than > depend on my memory. :-) The tool is very robust and encodes a great deal of very useful information, but I think you do not give yourself enough credit. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From lasse at jarlskov.dk Fri Oct 22 00:40:58 2004 From: lasse at jarlskov.dk (Lasse Jarlskov) Date: Fri, 22 Oct 2004 00:40:58 +0200 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: <5.1.0.14.2.20041021102217.00acdff8@mail.iucc.ac.il> References: <5.1.0.14.2.20041021102217.00acdff8@mail.iucc.ac.il> Message-ID: <4negn0tni17tcbsanopuv8g764q3fdddbu@4ax.com> On Thu, 21 Oct 2004 10:40:05 +0200, you wrote: >It has to do with .eu: About .eu. I always thought that ccTLDs could only be assigned if they are on ISO-3166-1. Indeed thats what http://www.icann.org/icp/icp-1.htm says. Yet, acording to http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1.html EU is not on that list. With these rules, how can .eu be assigned to anyone? Regards, /Jarlskov From jay at nominet.org.uk Sun Oct 24 19:45:39 2004 From: jay at nominet.org.uk (Jay Daley) Date: Sun, 24 Oct 2004 18:45:39 +0100 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: Message-ID: Brad Brad wrote on 24/10/2004 02:58:15 pm: > At 1:05 PM +0200 2004-10-24, Iljitsch van Beijnum wrote: > > > For instance, see > >http://www.nominet.org.uk/Statistics/RegistrationStatistics/ > > Around 90% of all registered .uk domains are .co.uk domains. > > Anyone know what the distribution of company sizes are for those > registrations? > We have not been asking for those details for long enough to have a firm answer. In addition we suspect there is some distortion caused by companies that put themselves down as private individuals in order to opt-out of the whois. Maybe in a year or so we might be able to start publishing those figures, after we go through a major data restructuring exercise.. BTW we breakdown the organisational type into 13 different categories! Jay From bortzmeyer at nic.fr Tue Oct 26 10:14:17 2004 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 26 Oct 2004 10:14:17 +0200 Subject: [dns-wg] Re: Elimination of 2nd level ccTLD domain names In-Reply-To: <4negn0tni17tcbsanopuv8g764q3fdddbu@4ax.com> References: <5.1.0.14.2.20041021102217.00acdff8@mail.iucc.ac.il> <4negn0tni17tcbsanopuv8g764q3fdddbu@4ax.com> Message-ID: <20041026081417.GA10415@nic.fr> On Fri, Oct 22, 2004 at 12:40:58AM +0200, Lasse Jarlskov wrote a message of 19 lines which said: > I always thought that ccTLDs could only be assigned if they are on > ISO-3166-1. Indeed thats what http://www.icann.org/icp/icp-1.htm > says. And before that, RFC 1591. But both these documents do not handle the case of disappearing countries (see .SU and .YU). Most Internet users want stable names and therefore would not agree with the disparition of a domain. > Yet, acording to > http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1.html > EU is not on that list. Rules always have exceptions :-) In Europe, see .AC, .GG, .IM and .JE, which are in the root but were never in ISO-3166 (I always mention this when people say that things were better with Jon Postel). From pk at TechFak.Uni-Bielefeld.DE Tue Oct 26 10:44:28 2004 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Tue, 26 Oct 2004 10:44:28 +0200 Subject: [dns-wg] Re: Elimination of 2nd level ccTLD domain names In-Reply-To: Your message of "Tue, 26 Oct 2004 10:14:17 +0200." <20041026081417.GA10415@nic.fr> Message-ID: <200410260844.i9Q8iT103700@grimsvotn.TechFak.Uni-Bielefeld.DE> Stephane Bortzmeyer wrote: > > EU is not on that list. > > Rules always have exceptions :-) http://www.icann.org/minutes/prelim-report-25sep00.htm#00.74 is where the EU reads that EU is available for delegation. There has been lots of discussion and argument around this application of the "reserved codes" list, let's not rehash that here. > In Europe, see .AC, .GG, .IM and .JE, which are in the root but were > never in ISO-3166 (I always mention this when people say that things > were better with Jon Postel). Those codes came from a list of the UPU (see www.upu.int and the 'post' TLD ...) and are also on the ISO3166 "reserved" list, see also http://www.iso.org/iso/en/prods-services/iso3166ma/04background-on-iso-3166/iso3166-1-and-ccTLDs.html The list of reserved code points is officially only available from the ISO 3166/MA via email: http://www.iso.org/iso/en/prods-services/iso3166ma/10faq/frequently-asked-questions.html#Q08 -Peter From tjd-dnswg at phlegethon.org Tue Oct 26 11:10:50 2004 From: tjd-dnswg at phlegethon.org (Tim Deegan) Date: Tue, 26 Oct 2004 10:10:50 +0100 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: References: <5.1.0.14.2.20041021102217.00acdff8@mail.iucc.ac.il> <5.1.0.14.2.20041021125710.055daeb0@imap.cwi.nl> <20041021120148.GF69081@ocelot.phlegethon.org> <4177C0C7.8030000@central.tee.gr> Message-ID: <20041026091050.GA92058@ocelot.phlegethon.org> At 21:56 +0200 on 21 Oct (1098395800), Brad Knowles wrote: > How long do you have to wait before you recycle? Five years, though apparently this is expected to be extended to fifty. > What if > recycling still isn't enough to solve the collision problem for a > given set of initial characters? Some country gets an unfortunate two-letter code. They're not going to stop issuing ISO 3166-1 codes just because they run out of good matches. Tim. -- Tim Deegan sooner or later end up singing a duet with Mr Blue Bird and other forest creatures, and then there's nothing for it but a flamethrower. [ Terry Pratchett, "Carpe Jugulum" ] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From bortzmeyer at nic.fr Tue Oct 26 16:04:32 2004 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 26 Oct 2004 16:04:32 +0200 Subject: [dns-wg] Re: Elimination of 2nd level ccTLD domain names In-Reply-To: References: <417CFE59.30608@central.tee.gr> Message-ID: <20041026140432.GB3226@nic.fr> On Mon, Oct 25, 2004 at 04:29:39PM +0200, Brad Knowles wrote a message of 63 lines which said: > It [NSD] pre-calculates all possible questions and all possible > answers before it loads the zone(s), and then creates a jump table. It is not entirely true since version 2.0 (ns2.nic.fr runs 2.1.2). It was the original algorithm but it was changed to accomodate DNSsec where a default reply of NXDOMAIN (for every domain not found in the jump table) was not a proper reply. See http://www.nlnetlabs.nl/nsd/ > I remember at RIPE 44 that we got a report from the folks up at > SUNET, who had tried using NSD to serve the ccTLDs they handle, and > even though it was a monster machine with many gigabytes of memory, > that still wasn't enough. ns2.nic.fr is a secondary of ".nl" (the largest zone it serves) and of many in-addr.arpa subdomains and ccTLDs. It serves twelve millions records. Here it is (see VSZ and RSS for its memory consumption): USER PID %CPU %MEM VSZ RSS TTY S STARTED TIME COMMAND nsd 209888 1.7 18.4 669M 564M ?? R 15:26:03 0:22.27 /usr/local/sbin/nsd -a 192.93.0.4 -a 2001:660:3005:1::1:2 -n 4 From brad at stop.mail-abuse.org Tue Oct 26 17:00:46 2004 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Tue, 26 Oct 2004 17:00:46 +0200 Subject: [dns-wg] Re: Elimination of 2nd level ccTLD domain names In-Reply-To: <20041026140432.GB3226@nic.fr> References: <417CFE59.30608@central.tee.gr> <20041026140432.GB3226@nic.fr> Message-ID: At 4:04 PM +0200 2004-10-26, Stephane Bortzmeyer wrote: > ns2.nic.fr is a secondary of ".nl" (the largest zone it serves) and of > many in-addr.arpa subdomains and ccTLDs. It serves twelve millions > records. Here it is (see VSZ and RSS for its memory consumption): Yes, but can you also load a copy of every other ccTLD that is within Europe? All of Poland? Germany? All the other countries? All their in-addr.arpa zones? What would happen if you had to load ten times as much information? At the time I was doing my research in 2002, the largest zone I could get a copy of was .tv (over 460,000 records). At that time, .cz was about 387,000 records, .hu was about 299,000 records, .pl was about 291,000 records, and .se was about 290,000 records. What are these numbers today? How many records are there across all the ccTLDs that comprise the countries which are in the EU? How many records are there for Turkey? Now, what about all their respective in-addr.arpa zones? How much memory would be required to load all these zones onto a single NSD server? Could you still handle it if the requirements jumped by a factor of ten? Are the operating systems ready to support those kinds of memory requirements? I think that's the scale of problem that is facing us with a flat .eu zone, and far more rapidly than anyone here is giving credit. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From pk at TechFak.Uni-Bielefeld.DE Tue Oct 26 18:30:39 2004 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Tue, 26 Oct 2004 18:30:39 +0200 Subject: [dns-wg] Re: Elimination of 2nd level ccTLD domain names In-Reply-To: Your message of "Tue, 26 Oct 2004 17:00:46 +0200." Message-ID: <200410261630.i9QGUd805200@grimsvotn.TechFak.Uni-Bielefeld.DE> Brad, > I think that's the scale of problem that is facing us with a flat > .eu zone, and far more rapidly than anyone here is giving credit. my impression is we're about to enter an infinite loop. Your view of how fast and how large a EU TLD may grow seems rather ``optimistic'' and is probably not shared by many in this group. While still you might be right, we would now have to discuss growth rates based on market potential etc. But then, I don't see where having this discussion on this particular list would lead us. -Peter From Piet.Beertema at cwi.nl Tue Oct 26 20:22:06 2004 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Tue, 26 Oct 2004 20:22:06 +0200 Subject: [dns-wg] Re: Elimination of 2nd level ccTLD domain names In-Reply-To: <200410261630.i9QGUd805200@grimsvotn.TechFak.Uni-Bielefeld. DE> References: Message-ID: <5.1.0.14.2.20041026200503.00afd288@imap.cwi.nl> > > I think that's the scale of problem that is facing us with a flat > > .eu zone, and far more rapidly than anyone here is giving credit. > >my impression is we're about to enter an infinite loop. That in fact is the case already. >While still you might be right, we would now have to discuss growth >rates based on market potential etc. Now you hit upon an interesting issue. In NL we were more or less forced a couple of years ago to open up registration for private persons too, the reasoning behind it being 'fixed' e-mail addresses even when people moved to another ISP, which happened frequently. Initially we 'solved' this by introducing numeric SLD's (123.nl), under which they could register names. That was not a success, to put it mildly: all in all we registered less than 1000 domains of that kind. Main reason: people didn't like the numeric "extension". More recently .NL itself was opened up for private persons too, but now we see a vastly different situation from a couple of years ago: because of the massive amounts of spam 'fixed' addresses are not en vogue anymore and lots of people have loads of addresses. Which is just one reason why I don't expect TLD's to explode and a good example of a problem that solves itself. Piet From jim at rfc1035.com Tue Oct 26 20:28:07 2004 From: jim at rfc1035.com (Jim Reid) Date: Tue, 26 Oct 2004 19:28:07 +0100 Subject: [dns-wg] Re: Elimination of 2nd level ccTLD domain names In-Reply-To: Message from Brad Knowles of "Tue, 26 Oct 2004 17:00:46 +0200." Message-ID: <1210.1098815287@gromit.rfc1035.com> Brad, this discussion is not achieving anything. Please stop. If/when zones get to the size that they present operational or management problems, solutions to those issues will be available, They are already available today. [Moore's law will mean cheaper and bigger RAM chips (and CPUs), 100Gb+ disks are becoming the norm and there are plenty of 64-bit architectures and Operating Systems.] Which solution or solutions a TLD registry adopts will be their decision. Having a structured name space won't make much difference: it just moves or defers the pain points. From jaap at NLnetLabs.nl Wed Oct 27 10:56:56 2004 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Wed, 27 Oct 2004 10:56:56 +0200 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: Your message of Thu, 21 Oct 2004 10:40:05 +0200. <5.1.0.14.2.20041021102217.00acdff8@mail.iucc.ac.il> Message-ID: <200410270856.i9R8uuVG097147@open.nlnetlabs.nl> I'm new to this particular WG For a Charter of this WG, see http://www.ripe.net/ripe/wg/dns/index.html but I'd like to raise an issue that I feel is best discussed in a European DNS forum. It has to do with .eu: According to my understanding, there will be direct 2nd level domains - like ibm.eu or ripe.eu or even tonyblair.eu. Up till now, most countries employed a hierarchical structure such as ac.xx or co.xx or org.xx. What do we lose by eliminating 2nd level domains? Since .eu is a totally new TLD - perhaps not much, but what happens to countries that then decide to follow the same path as Singapore recently did (they are cc'ed to this email): http://www.nic.net.sg/newsroom/20040816030345.html Are there any limitations to what a 2nd level domain name can be (not referring to trademarks)? I.e. would a single digit or letter be allowed? Would co.sg be allowed (up till now com.sg was the main commercial 2nd level domain)? Note that these questions are really concerning the local naming policy in a domain. There is no global answer to these questions. It really depends on the local policy. I seem to remember that the introduction of SLDs in the sg domain was at request of the local community. Are other countries considering following the same path? I'm not aware of others but it might. Thise type of questions are best asked at a more policy oriented mailing list, such as cctld-discuss at wwtld.org. jaap From jaap at NLnetLabs.nl Wed Oct 27 11:14:14 2004 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Wed, 27 Oct 2004 11:14:14 +0200 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: Your message of Thu, 21 Oct 2004 13:32:20 +0100. <20041021123220.GG69081@ocelot.phlegethon.org> Message-ID: <200410270914.i9R9EE1r097552@open.nlnetlabs.nl> > At the very least, any policy that prohibits two-letter SLDs (on=20 > the basis of potential conflicts with ccTLDs) should acknowledge this=20 > future problem. How about: "At the present rate-of-change of ISO 3166-1, we must solve the problems mentioned in RFC 1535 at some time in the next six hundred years"? :) If I read 1535 correctly, it deals with setting up a correct search list for a resolver. It doesn't deal with ccTLD domains. jaap From jaap at NLnetLabs.nl Wed Oct 27 11:19:08 2004 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Wed, 27 Oct 2004 11:19:08 +0200 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: Your message of Thu, 21 Oct 2004 15:06:14 +0200. Message-ID: <200410270919.i9R9J8px097719@open.nlnetlabs.nl> At 1:32 PM +0100 2004-10-21, Tim Deegan wrote: > How about: "At the present rate-of-change of ISO 3166-1, we must solve > the problems mentioned in RFC 1535 at some time in the next six hundred > years"? :) See my other message. This is a problem that is looming much faster than you are giving it credit. If it is a problem, there is nothing what we can do about it. You should turn to the ISO 3366-1 maintenance group or, alternatively, turn to ICANN that they change the current policy of using 3366-1 for accignment of cctld names. jaap From jaap at NLnetLabs.nl Wed Oct 27 11:38:49 2004 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Wed, 27 Oct 2004 11:38:49 +0200 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: Your message of Thu, 21 Oct 2004 21:56:40 +0200. Message-ID: <200410270938.i9R9cn4r098174@open.nlnetlabs.nl> >> When they run out of two-letter ccTLDs that they can hand out, what >> do you think they're going to do? > > Recycle. IIRC, CS used to symbolise Chechosolvakia (sp?) and now it > stands for Serbia & Montenegro. How long do you have to wait before you recycle? What if recycling still isn't enough to solve the collision problem for a given set of initial characters? I've been told that there has been some discussions with the 3166-1 maintenance agency about this when the CS label got recycled. The agency is aware of the problems this might cause and has promised to adapt its policy. Basically, when recycling, wait years to reuse the old code. jaap From jaap at NLnetLabs.nl Wed Oct 27 11:50:24 2004 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Wed, 27 Oct 2004 11:50:24 +0200 Subject: [dns-wg] Re: ORSN-SERVERS.NET In-Reply-To: Your message of Fri, 22 Oct 2004 11:41:05 +0200. <005901c4b81b$40bccf80$6e8392d9@client.hildesheim.wfi.de> Message-ID: <200410270950.i9R9oOZW098476@open.nlnetlabs.nl> In few days you will found an tool to compare the ORSN database with the ICANN root servers in realtime on our homepage. How many days is a few days? jaap From tjd-dnswg at phlegethon.org Wed Oct 27 11:51:01 2004 From: tjd-dnswg at phlegethon.org (Tim Deegan) Date: Wed, 27 Oct 2004 10:51:01 +0100 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: <200410270914.i9R9EE1r097552@open.nlnetlabs.nl> References: <20041021123220.GG69081@ocelot.phlegethon.org> <200410270914.i9R9EE1r097552@open.nlnetlabs.nl> Message-ID: <20041027095101.GA21392@ocelot.phlegethon.org> At 11:14 +0200 on 27 Oct (1098875654), Jaap Akkerhuis wrote: > If I read 1535 correctly, it deals with setting up a correct search list for a > resolver. It doesn't deal with ccTLD domains. No, but it's relevant. The reason for refusing to register two-letter SLDs is to avoid having SLDs that are the same as existing or future (cc)TLDs, which would aggravate the search-list problem: "This is clearly unacceptable. Further, it could only be made worse with domains like COM.EDU, MIL.GOV, GOV.COM, etc." Tim. -- Tim Deegan 31. The Minister may take such steps as he considers necessary for the destruction of any musk rats found at large. [ The Musk Rats Act, 1933 ] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From jaap at NLnetLabs.nl Wed Oct 27 12:07:57 2004 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Wed, 27 Oct 2004 12:07:57 +0200 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: Your message of Sun, 24 Oct 2004 20:07:36 +0100. <2295.1098644856@gromit.rfc1035.com> Message-ID: <200410271007.i9RA7vHW099051@open.nlnetlabs.nl> That said, I do believe that huge text files for zone files and name server configurations will eventually move to some sort of database back-end. This is the direction that most DNS implementations seem to be moving towards. Some TLDs have already adopted this approach and I'd be surprised if others didn't follow. The drawback of using a direct database back-end is that this means that are close ties between the nameserver and the database. If one of the two fails, you have a problem. That is why I don't see zone files go away. Whit a zone file you can easely change the name server for a new one when needed. jaap From jaap at NLnetLabs.nl Wed Oct 27 12:16:44 2004 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Wed, 27 Oct 2004 12:16:44 +0200 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: Your message of Mon, 25 Oct 2004 16:29:39 +0200. Message-ID: <200410271016.i9RAGiaj099269@open.nlnetlabs.nl> At 4:23 PM +0300 2004-10-25, Yiorgos Adamopoulos wrote: > Actually you do not have to run a database instance > on every node where you want to run a DNS server. Why not have the > Database system produce the zone files for the nameserver of your taste > (be it NSD, tinydns, BIND, etc) and then rsync to the actual servers? Well, for NSD, using large zones will cause it to eat memory exponentially. It pre-calculates all possible questions and all possible answers before it loads the zone(s), and then creates a jump table. Eh? This is complete nonsense (or I don't know what the word exponential means). There rest of this messages is full of FUD. jaap From jaap at NLnetLabs.nl Wed Oct 27 12:23:04 2004 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Wed, 27 Oct 2004 12:23:04 +0200 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: Your message of Mon, 25 Oct 2004 21:03:33 +0200. Message-ID: <200410271023.i9RAN4xx099416@open.nlnetlabs.nl> I have been talking about nothing *but* ccTLDs in Europe, and how this flat namespace model will not continue to scale. > Plus the fact that a generic, worldwide and *flat* TLD like > .com still hasn't grown such as to become unmanageable? It has grown to the point where it is not manageable. It was unmanageable a long time ago, and things have been going further down the toilet ever since. Yeah. Tell Verisign that they cannot run a nameserver for .com. And you're going to have a problem that will be an order of magnitude larger than .com. It will be quite a while befor an other TD will hit the 30M domain count ad the info, biz, and other gTLDs have showed. jaap From bortzmeyer at nic.fr Wed Oct 27 12:23:19 2004 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 27 Oct 2004 12:23:19 +0200 Subject: [dns-wg] Re: Elimination of 2nd level ccTLD domain names In-Reply-To: References: <417CFE59.30608@central.tee.gr> Message-ID: <20041027102319.GA18857@nic.fr> On Mon, Oct 25, 2004 at 04:29:39PM +0200, Brad Knowles wrote a message of 63 lines which said: > Well, for NSD, using large zones will cause it to eat memory > exponentially. Here is the NSD maintainer's analysis: http://open.nlnetlabs.nl/pipermail/nsd-users/2004-October/000276.html From jim at rfc1035.com Wed Oct 27 12:47:51 2004 From: jim at rfc1035.com (Jim Reid) Date: Wed, 27 Oct 2004 11:47:51 +0100 Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: Message from Tim Deegan of "Wed, 27 Oct 2004 10:51:01 BST." <20041027095101.GA21392@ocelot.phlegethon.org> Message-ID: <2636.1098874071@gromit.rfc1035.com> >>>>> "Tim" == Tim Deegan writes: Tim> No, but it's relevant. The reason for refusing to register Tim> two-letter SLDs is to avoid having SLDs that are the same as Tim> existing or future (cc)TLDs, which would aggravate the Tim> search-list problem: Tim> "This is clearly unacceptable. Further, it could only be Tim> made worse with domains like COM.EDU, MIL.GOV, GOV.COM, etc." In that case, perhaps someone could start a thread on Why Search Lists Are Evil? Maybe then we could finally bring this discussion to a close. As Peter already said, how a TLD structures its name space (or not) and determines what names can be registered there is a local policy issue. It is not an appropriate topic for this list or the WG. Let's suppose the WG considered this subject, reached consensus and published a RIPE document. [Yes, I know this is fantasy but bear with me.] Would any TLD care? Would they annoy their users by forcing them to rename already registered domains to comply with this document? The reality is there already are lots of SLDs in use today that have labels that are TLDs. .com exists for just about every TLD, including com.com. (Sigh.) If this creates problems for broken resolvers and unwise search lists, then the way to fix that is to solve the underlying misconfigurations. Tinkering with the name space or treating some labels as "special" is the wrong approach. I now ask everyone to please stop posting on this thread. The discussion is not appropriate for this list and isn't a suitable subject for the WG. If you disagree with this, please send mail to dns-wg-chair at ripe.net -- not this list! -- explaining why the discussion should continue and its relevance to the WG. From olaf at ripe.net Wed Oct 27 13:01:14 2004 From: olaf at ripe.net (Olaf M. Kolkman) Date: Wed, 27 Oct 2004 13:01:14 +0200 Subject: [dns-wg] Announcement: "DNSSEC HOWTO" Message-ID: <20041027130114.6cece16d.olaf@ripe.net> Dear Colleagues, [Apologies for duplicates] We are happy to announce the availability of a "DNSSEC HOWTO" at: http://www.ripe.net/disi/dnssec_howto/ (html) http://www.ripe.net/disi/dnssec_howto/dnssec_howto.pdf (pdf) The document forms part of a RIPE NCC project on the deployment of DNSSEC and describes how to set up DNSSEC. The HOWTO covers the following topics: * Part I, 'Securing DNS data', about the aspects of DNSSEC that deal with data security. * Part II, 'Securing communication between Servers', covering aspects that deal with server to server security and transaction security. The document is based on the so-called DNSSEC-bis specifications that where finalized by the IETF and are now in the RFC editors queue [I-D.ietf-dnsext-dnssec-intro, I-D.ietf-dnsext-dnssec-protocol and I-D.ietf-dnsext-dnssec-records]. This document will be subject to change. Please regularly check for new versions at: http://www.ripe.net/disi. Your corrections and additions are appreciated. ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC From jim at rfc1035.com Wed Oct 27 13:06:31 2004 From: jim at rfc1035.com (Jim Reid) Date: Wed, 27 Oct 2004 12:06:31 +0100 Subject: [dns-wg] name servers with database back-ends In-Reply-To: Message from Jaap Akkerhuis of "Wed, 27 Oct 2004 12:07:57 +0200." <200410271007.i9RA7vHW099051@open.nlnetlabs.nl> Message-ID: <2668.1098875191@gromit.rfc1035.com> >>>>> "Jaap" == Jaap Akkerhuis writes: Jaap> The drawback of using a direct database back-end is that Jaap> this means that are close ties between the nameserver and Jaap> the database. If one of the two fails, you have a problem. Indeed. The database back-end becomes a SPoF. To some extent that can be mitigated by the fancy high-availability replication techniques that the likes of Oracle & Sybase offer. For a fancy price of course. Since SPoFs in the DNS are bad, I would hope important zones ran on homogeneous DNS implementations with identical hardware, OS and system administration. So if a TLD did use a name server with a database back-end, I hope they'd couple that with something like dynamic updates to a DNS hosting provider that ran a different implementation. And maybe did anycasting as well. I compare loading Gb-sized text zone files to teaching an elephant to ballet dance. It can be made to work if sufficient energy is expended though the results are not pretty. From jim at rfc1035.com Wed Oct 27 13:16:07 2004 From: jim at rfc1035.com (Jim Reid) Date: Wed, 27 Oct 2004 12:16:07 +0100 Subject: [dns-wg] Analysis of NSD In-Reply-To: Message from Stephane Bortzmeyer of "Wed, 27 Oct 2004 12:23:19 +0200." <20041027102319.GA18857@nic.fr> Message-ID: <2684.1098875767@gromit.rfc1035.com> >>>>> "Stephane" == Stephane Bortzmeyer writes: >> Well, for NSD, using large zones will cause it to eat memory >> exponentially. Stephane> Here is the NSD maintainer's analysis: Stephane> http://open.nlnetlabs.nl/pipermail/nsd-users/2004-October/000276.html While there is no reason to dispute the analysis from NSD's authors, I do think it would be nice if there was an independent analysis of NSD. And other DNS implementations for that matter. The work Brad did a couple of years ago was a step in that direction. I would also encourage operators to share their experiences of different name server implementations here: performance, protocol compliance, features, management & support issues, SLAs with hosting providers, etc, etc. Capturing and documenting this anecdotal information would be very useful. From jim at rfc1035.com Wed Oct 27 13:18:40 2004 From: jim at rfc1035.com (Jim Reid) Date: Wed, 27 Oct 2004 12:18:40 +0100 Subject: [dns-wg] Announcement: "DNSSEC HOWTO" In-Reply-To: Message from "Olaf M. Kolkman" of "Wed, 27 Oct 2004 13:01:14 +0200." <20041027130114.6cece16d.olaf@ripe.net> Message-ID: <2695.1098875920@gromit.rfc1035.com> Olaf, thanks very much to you and your colleagues for producing this. I wonder if it would be appropriate to have this published as a RIPE document. Any comments from the WGs? From jim at rfc1035.com Wed Oct 27 13:48:37 2004 From: jim at rfc1035.com (Jim Reid) Date: Wed, 27 Oct 2004 12:48:37 +0100 Subject: [dns-wg] Re: name servers with database back-ends In-Reply-To: <2668.1098875191@gromit.rfc1035.com> Message-ID: <2773.1098877717@gromit.rfc1035.com> > Since SPoFs in the DNS are bad, I would hope important zones ran on > homogeneous DNS implementations with identical hardware, OS and > system administration. Whoops! That should of course be "...zones did NOT run on...". From hank at mail.iucc.ac.il Wed Oct 27 15:18:24 2004 From: hank at mail.iucc.ac.il (Hank Nussbacher) Date: Wed, 27 Oct 2004 15:18:24 +0200 (IST) Subject: [dns-wg] Elimination of 2nd level ccTLD domain names In-Reply-To: <200410270856.i9R8uuVG097147@open.nlnetlabs.nl> References: <200410270856.i9R8uuVG097147@open.nlnetlabs.nl> Message-ID: > Are other countries considering following the same path? > > I'm not aware of others but it might. Thise type of questions are > best asked at a more policy oriented mailing list, such as > cctld-discuss at wwtld.org. > > jaap This list has been more than helpful. Thanks, Hank From jorgen at hovland.cx Thu Oct 28 04:47:13 2004 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Thu, 28 Oct 2004 03:47:13 +0100 Subject: [dns-wg] Analysis of NSD References: <2684.1098875767@gromit.rfc1035.com> Message-ID: <064c01c4bc98$6e8d2050$c8401cac@jjobbpc> ----- Original Message ----- From: "Jim Reid" > I would also encourage operators to share their experiences of > different name server implementations here: performance, protocol > compliance, features, management & support issues, SLAs with hosting > providers, etc, etc. Capturing and documenting this anecdotal > information would be very useful. > Hello We are running our own implementation of a domain name server for our hosting company. Its unfortunately not publicy available and I have no additional information, but I thought the implementations might be interesting anyway. We have been running this software for 2 years now. The nameserver is using SQL as a direct back-end but all servers loads data into memory for optimisation reasons during startup. They sort the data into a tree-like structure but doesn't calculate all possible queries or answers. This reduces the amount of ram needed. Besides not all records return static data. We have a few special features so it could easily eat a million gb of ram if we did do it. Some of these are autogeneration of forward/reverse dns based on wildcard/regexp records (so that 100 billion ipv6 addresses doesn't make 200 billion records in dns but only 2) and different replies depending on the country origin of the source ip of the querying nameserver/client. The answer depends on another external database in other words. We also dropped all RRs which no customer have ever asked for (we add it on demand though). When it comes to zone updates we use a tcp/ip connection to the master server instead of altering the database directly. We don't need to probe for db changes this way. The user issues a command and the nameserver replies ok or error and so on. You can only add/del/change data, not list/view it. A change results in that the master updates the local memory of the change only and then the sql server, finally it sends the update to any connected slaves. Slaves are registered with the master through a permanent tcp connection and receive updates whenever somebody alters data in a non zone-transfer/axfr compatible way. We actually don't have support for normal zone transfers at all. The master sends the actual change, not the entire zone or a zone reload request. So both master and slaves updates their local copy instantly. If a slave gets disconnected from the master, it will reload the whole database from the sql server when reconnected to the master in order to ensure no loss of data since the master doesn't keep track on the status of any of the slaves. This reload takes seconds for a small/medium sized database (10k+). When the data has been loaded and sorted the nameserver replaces it with the existing local copy and deletes it from memory. This ensures no downtime. Serial numbers are simply autocalculated from the current time and its not possible for a user to do anything about it. The response latency is the same as with bind but it uses significantly less memory. I havent really done the research to know why. Since we use a tcp connection to the nameserver as way of managing zones, the wrong things you can do is very few. We do have a different policy with regards to valid characters (iso-xx, utf8, idn). The nameserver accepts anything and it's up to the customer to decide what they want. Browsers like msie and internet daemons using different encodings will be able to use the same host name when the customer have the ability to add all possible encoded versions of it (hope I'm not starting an argument here.). Cheers, Joergen Hovland ENK From johani at autonomica.se Thu Oct 28 10:02:10 2004 From: johani at autonomica.se (=?ISO-8859-1?Q?Johan_Ihr=E9n?=) Date: Thu, 28 Oct 2004 10:02:10 +0200 Subject: [dns-wg] Analysis of NSD In-Reply-To: <064c01c4bc98$6e8d2050$c8401cac@jjobbpc> References: <2684.1098875767@gromit.rfc1035.com> <064c01c4bc98$6e8d2050$c8401cac@jjobbpc> Message-ID: Hi J?rgen, On Oct 28, 2004, at 04:47, J?rgen Hovland wrote: > and different replies depending on the country origin of the source ip > of the querying nameserver/client. Oops. What's the justification for that? And what about maintaining DNS coherency? Any ideas on how to make this work with DNSSEC (I realize you're not doing DNSSEC today, but this would seem to be fundamentally incompatible with any DNSSEC use whatsoever). > When it comes to zone updates we use a tcp/ip connection to the > master server instead of altering the database directly. We don't need > to probe for db changes this way. Well, that makes sense, but no one in their right mind is probing for changes since NOTIFY was defined many years ago. > The user issues a command and the nameserver replies ok or error and > so on. You can only add/del/change data, not list/view it. A change > results in that the master updates the local memory of the change only > and then the sql server, finally it sends the update to any connected > slaves. Slaves are registered with the master through a permanent tcp > connection and receive updates whenever somebody alters data in a non > zone-transfer/axfr compatible way. We actually don't have support for > normal zone transfers at all. The master sends the actual change, not > the entire zone or a zone reload request. So both master and slaves > updates their local copy instantly. > If a slave gets disconnected from the master, it will reload the whole > database from the sql server when reconnected to the master in order > to ensure no loss of data since the master doesn't keep track on the > status of any of the slaves. This reload takes seconds for a > small/medium sized database (10k+). When the data has been loaded and > sorted the nameserver replaces it with the existing local copy and > deletes it from memory. This ensures no downtime. What happens to updates (to the master) that occur *during* the reload? My guess is that they get added to "the tail" of the reload to ensure that no change is left out during the reload. But in that case it seems to me that you already have the zone sorted in "transaction order" and the only thing needed to steer around the complete reloads would be some sort of version stamp that is shared between slave and master. Doesn't really have to be the SOA serial, you can use whatever you want. If you need to serve zones of non-trivial size that would seem to be a good idea. > Serial numbers are simply autocalculated from the current time and its > not possible for a user to do anything about it. I.e. the SOA serial is *changed* by the slave. This too won't fly too well with DNSSEC. > The response latency is the same as with bind but it uses > significantly less memory. I havent really done the research to know > why. Since we use a tcp connection to the nameserver as way of > managing zones, the wrong things you can do is very few. Regards, Johan Ihr?n Autonomica From td at nominet.org.uk Thu Oct 28 10:40:06 2004 From: td at nominet.org.uk (Jay Daley) Date: Thu, 28 Oct 2004 09:40:06 +0100 Subject: [dns-wg] Analysis of NSD In-Reply-To: Message-ID: Johan Johan wrote on 28/10/2004 09:02:10: > > When it comes to zone updates we use a tcp/ip connection to the > > master server instead of altering the database directly. We don't need > > to probe for db changes this way. > > Well, that makes sense, but no one in their right mind is probing for > changes since NOTIFY was defined many years ago. As it happens we use probing not NOTIFY since it gives a greater level of control over the number of secondaries being updated at once (and the bandwidth) and the order in which they are updated. This does rely on strict calculations of the timings of changes and probes but that is fairly easy to do. Jay Daley Nominet UK From pk at TechFak.Uni-Bielefeld.DE Thu Oct 28 10:45:49 2004 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Thu, 28 Oct 2004 10:45:49 +0200 Subject: [dns-wg] Analysis of NSD In-Reply-To: Your message of "Thu, 28 Oct 2004 09:40:06 BST." Message-ID: <200410280845.i9S8jnM10933@grimsvotn.TechFak.Uni-Bielefeld.DE> Jay Daley : > As it happens we use probing not NOTIFY since it gives a greater level of > control over the number of secondaries being updated at once (and the NOTIFY already specifies precautions against a 'rush', although implementations may differ and depending on the size of the zone 'at once' may have different meanings. > bandwidth) and the order in which they are updated. This does rely on > strict calculations of the timings of changes and probes but that is > fairly easy to do. How about sending the NOTIFY messages out of band instead of relying upon retry (and not refresh?)? There's a little 'DoS' potential, though. -Peter From johani at autonomica.se Thu Oct 28 10:48:46 2004 From: johani at autonomica.se (=?ISO-8859-1?Q?Johan_Ihr=E9n?=) Date: Thu, 28 Oct 2004 10:48:46 +0200 Subject: [dns-wg] Analysis of NSD In-Reply-To: References: Message-ID: <2E2E01F8-28BE-11D9-A2BA-000393DB5596@autonomica.se> Hi Jay, On Oct 28, 2004, at 10:40, Jay Daley wrote: > Johan > > Johan wrote on 28/10/2004 09:02:10: > >>> When it comes to zone updates we use a tcp/ip connection to the >>> master server instead of altering the database directly. We don't >>> need > >>> to probe for db changes this way. >> >> Well, that makes sense, but no one in their right mind is probing for >> changes since NOTIFY was defined many years ago. > > As it happens we use probing not NOTIFY since it gives a greater level > of > control over the number of secondaries being updated at once (and the > bandwidth) and the order in which they are updated. This does rely on > strict calculations of the timings of changes and probes but that is > fairly easy to do. Certainly. But that only works if you relax the goal of more or less instant propagation of changes (to the slaves). I.e. that way you compromise synchronicity (is there such a word?) between slaves for the to you more important goal of managing your data streams. In your case the size of the data is non-trivial, so I understand the reasoning. Johan PS. I choose the word synchronicity rather than coherence, because as long as each slave publish exactly the same data for the same SOA serial they are technically coherent (to the version of the data they *have*) although they may be temporarily out of sync (with slaves having acquiered more recent data). From td at nominet.org.uk Thu Oct 28 11:07:25 2004 From: td at nominet.org.uk (Jay Daley) Date: Thu, 28 Oct 2004 10:07:25 +0100 Subject: [dns-wg] Analysis of NSD In-Reply-To: <200410280845.i9S8jnM10933@grimsvotn.TechFak.Uni-Bielefeld.DE> Message-ID: Peter Peter wrote on 28/10/2004 09:45:49: > Jay Daley : > > > As it happens we use probing not NOTIFY since it gives a greater level of > > control over the number of secondaries being updated at once (and the > > NOTIFY already specifies precautions against a 'rush', although > implementations > may differ and depending on the size of the zone 'at once' may have different > meanings. Just to give you an idea, the total size of the zone files is around 250MB and as we do a full transfer every day these take about 2 hours per secondary. This will change soon as we move to incremental updates, at which point we may well use NOTIFY. From looking at our logs the largest number of zone files changes on one day is generally about 250,000 DNs being added or removed. Jay Daley Nominet UK From jim at rfc1035.com Thu Oct 28 11:08:22 2004 From: jim at rfc1035.com (Jim Reid) Date: Thu, 28 Oct 2004 10:08:22 +0100 Subject: [dns-wg] NOTIFY In-Reply-To: Message from Peter Koch of "Thu, 28 Oct 2004 10:45:49 +0200." <200410280845.i9S8jnM10933@grimsvotn.TechFak.Uni-Bielefeld.DE> Message-ID: <4643.1098954502@gromit.rfc1035.com> >>>>> "Peter" == Peter Koch writes: >> As it happens we use probing not NOTIFY since it gives a >> greater level of control over the number of secondaries being >> updated at once (and the Peter> NOTIFY already specifies precautions against a 'rush', Peter> although implementations may differ and depending on the Peter> size of the zone 'at once' may have different meanings. Yes. But BIND's implementation of this feature is meant for the case when there are lots of zones that get changed and reloaded. [And there are no control hooks for setting the delay interval IIRC.] The server staggers the sending of NOTIFYs to reduce the potential for an axfr storm. The feature doesn't really help when there's a huge zone. Like co.uk... >> bandwidth) and the order in which they are updated. This does >> rely on strict calculations of the timings of changes and >> probes but that is fairly easy to do. Peter> How about sending the NOTIFY messages out of band instead Peter> of relying upon retry (and not refresh?)? There's a little Peter> 'DoS' potential, though. How about rndc refresh or rndc retransfer in 9.3? It's not really an out of band NOTIFY, though the effect is the same. Note the new Subject since this thread isn't talking abouut an analysis of NSD any more. From jim at rfc1035.com Thu Oct 28 11:31:55 2004 From: jim at rfc1035.com (Jim Reid) Date: Thu, 28 Oct 2004 10:31:55 +0100 Subject: [dns-wg] NOTIFY In-Reply-To: Message from =?ISO-8859-1?Q?Johan_Ihr=E9n?= of "Thu, 28 Oct 2004 10:48:46 +0200." <2E2E01F8-28BE-11D9-A2BA-000393DB5596@autonomica.se> Message-ID: <4709.1098955915@gromit.rfc1035.com> >>>>> "Johan" == =?ISO-8859-1?Q?Johan Ihr=E9n?= writes: Johan> i.e. that way you compromise synchronicity (is Johan> there such a word?) There is. It means to agree in time or to have the property of agreeing in time. The extract from Wikipedia is appropriate: For the album by The Police see Synchronicity. Synchronicity is a term that was used by the Swiss psychologist Carl Jung to describe the alignment of universal forces with one's own life experience. Jung believed that some (if not all) coincidences were not mere chance, but instead a literal "co-inciding", or alignment of forces in the universe to create an event or circumstance. For most of the people here, I suppose their life experiences are aligned with the universal, not mere chance forces of consistent DNS data. :-) Johan> PS. I choose the word synchronicity rather than coherence, Johan> because as long as each slave publish exactly the same data Johan> for the same SOA serial they are technically coherent (to Johan> the version of the data they *have*) although they may be Johan> temporarily out of sync (with slaves having acquiered more Johan> recent data). Hmmm. Your suggestion of synchronicity works given the definition above. However I would have called that coherence: two or more servers publishing identical data for a given SOA serial. The name servers would be consistent if they all had the same data and SOA serial. But consistency usually has another meaning in the DNS: the same query always gets the same answer no matter where the query is made from. So perhaps strict consistency could mean when all authoritative servers have identical data for some zone. It doesn't really matter what terminology we use. Just as long as we agree on its meaning. "When I use a word, it means what I want it to mean." The quote's from Alice in Wonderland I think. From jorgen at hovland.cx Thu Oct 28 14:09:48 2004 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Thu, 28 Oct 2004 13:09:48 +0100 Subject: [dns-wg] Analysis of NSD References: <2684.1098875767@gromit.rfc1035.com> <064c01c4bc98$6e8d2050$c8401cac@jjobbpc> Message-ID: <06d301c4bce7$0683e170$c8401cac@jjobbpc> ----- Original Message ----- From: "Johan Ihr?n" > Hi J?rgen, > > On Oct 28, 2004, at 04:47, J?rgen Hovland wrote: > >> and different replies depending on the country origin of the source ip of >> the querying nameserver/client. > > Oops. > > What's the justification for that? And what about maintaining DNS > coherency? Any ideas on how to make this work with DNSSEC (I realize > you're not doing DNSSEC today, but this would seem to be fundamentally > incompatible with any DNSSEC use whatsoever). Hi Johan Load balancy. A bit similar to what Akamai is doing. Regarding dnsssec we aren't quite there yet and don't have a solution to it. > > What happens to updates (to the master) that occur *during* the reload? My > guess is that they get added to "the tail" of the reload to ensure that no > change is left out during the reload. But in that case it seems to me that > you already have the zone sorted in "transaction order" and the only thing > needed to steer around the complete reloads would be some sort of version > stamp that is shared between slave and master. Doesn't really have to be > the SOA serial, you can use whatever you want. The slave connects and registers with the master first, locks sql in read-only mode, clears unprocessed zone change messages from the master (there is about 0.001% chance of any zone change messages at this stage anyway) and then reloads from sql. Changes sent by the master during this stage will be held in a queue and not processed before reload is finished. This should guarantee that the local zone data is equal to the master. If the slave should die during the lock a certain timeout would unlock it. We do a complete reload since it only takes 3 seconds. This is where it becomes interesting. I am quite confident that comparing SOA/zone changes would actually take longer time. At least for us using SQL since a SQL query will take prox 20ms before a reply is given. Lets say 10% of the domains were altered. This is a pretty high number though. You have to get the new SOA's from SQL. Lets just say that this has already been done. Now, 10% altered zones out of 30 millions equals to 1000 minutes in latency only to deal with sql zone retrieve calls, not the processing of the data. I am quite sure a raw dump would require less time and less cpu resources by the sql server and perhaps even on the slave depending on the size of each zone. If you only have a few large zones then of course the result would not be the same. However if you have frequent updates on these few large zones you would probably have to reload everything anyway. You could always try reducing the amount of sql calls by grouping them together, but that might look "ugly". Nameservers doesn't usually lose connectivity anyway, but of course they do time to time. There is also a solution doing transaction logging when a slave gets disconnected. We skipped this because it is easier to add and delete new slaves without having to configure the master without. A transaction log could also get very high if the slave was down for a large amount of time and the implications generally about knowing if a slave actually performed the change or not made us skip this. Joergen Hovland ENK From pim at bit.nl Thu Oct 28 15:07:20 2004 From: pim at bit.nl (Pim van Pelt) Date: Thu, 28 Oct 2004 13:07:20 +0000 Subject: [dns-wg] Jumping the gun on SIDN! Message-ID: <20041028130720.GB30090@hog.ipng.nl> Hi, With some relief and pride, I'd like to show you that the dutch registry SIDN has enabled their registrars to offer IPv6 glue. One can send in a request using a freeform ticket. I happen to have been the first, so since todays serial of 200410280, there are new records in the nl. zone. Yaay! ; <<>> DiG 9.3.0 <<>> @ns.domain-registry.nl NS bit.nl. ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1989 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 6 ;; QUESTION SECTION: ;bit.nl. IN NS ;; AUTHORITY SECTION: bit.nl. 86400 IN NS nsauth1.bit.nl. bit.nl. 86400 IN NS nsauth2.bit.nl. bit.nl. 86400 IN NS nsauth3.bit.nl. ;; ADDITIONAL SECTION: nsauth1.bit.nl. 86400 IN A 213.136.12.51 nsauth2.bit.nl. 86400 IN A 213.136.12.59 nsauth3.bit.nl. 86400 IN A 212.204.192.11 nsauth1.bit.nl. 86400 IN AAAA 2001:7b8:3:2c::53 nsauth2.bit.nl. 86400 IN AAAA 2001:7b8:3:2d::53 nsauth3.bit.nl. 86400 IN AAAA 2001:898:1001:1003::53 ;; Query time: 46 msec ;; SERVER: 193.176.144.2#53(ns.domain-registry.nl) ;; WHEN: Thu Oct 28 13:04:59 2004 ;; MSG SIZE rcvd: 222 The dutch registry will implement and enable IPv6 in their infrastructure also, so I'm told by SIDN. -- Met vriendelijke groet, BIT BV / Ing P.B. van Pelt PBVP1-RIPE (PGPKEY-4DCA7E5E) From jefsey at jefsey.com Thu Oct 28 14:21:23 2004 From: jefsey at jefsey.com (JFC (Jefsey) Morfin) Date: Thu, 28 Oct 2004 14:21:23 +0200 Subject: [dns-wg] Re: ORSN-SERVERS.NET In-Reply-To: References: <00aa01c4b829$f0aebd50$6e8392d9@client.hildesheim.wfi.de> Message-ID: <6.1.2.0.2.20041028125528.03c207a0@mail.jefsey.com> At 21:57 24/10/2004, Jay Daley wrote: >Markus >Markus wrote on 22/10/2004 12:26:13 pm: > > > We are only the > > european (independent) copy of the stable ICANN root server system :-)) > >I really do not understand this. How are you in anyway more independent >than k-root or i-root? Jay, I will try to review this key point for the internet development. what ORSN does is risk containment. Suppose the ICANN/NTIA root is hacked. The ORSN file is not affected. This provides a protection. Now, obviously, if the delay in updating the ORSN file is too long it is going to pollute the namespace with old data. This is why trouble shouting calls for a report on possible differences. Such report must be taken both ways: - a way to know that ORSN is outdated - an alarm that the ICANN/NTIA root may be hacked. This kind of issue has been identified by the dot-root project of a DNS test bed we carried last years. This has lead us to work on local roots concepts and eventually on the authoritative root matrix (which is not documented, but implemented in reality through the additional name servers entered in the top level through ccTLD db.files for example). This also lead to the AFRAC project (http://afrac.org) to unlock root files (like the ICANN/NTIA root file) as this is true for any other application root file, through contextual root files for what we named "externets" (ie an external global view of the internet). For example, a Japanese externet can be all the users and hosts which freely chose to belong to it. End to end relations may then be limited to these externet members (only people able to read Japanese). You can belong to many externets. In the case of a nation, we identified that a national externet is a regalian duty. What does that mean? It means that many things may happen which affect your sure national use of the DNS. In 99.99% of the case that you use an US, a French, an European or a East-Timor root server is the same. But in critical occasions you will want to use a nameserver which will follow the rules which protect your skin. We developed this kind of thinking in parallel to the White House - we proposed ICANN to work on an "ICP-4" document on netsecurity in December 2001 at the DNSO/BC with a few large operators and corporations,. We then introduced the dot-root project to work on this along the lines of the ICP-3 document which investigates the possible end of an authoritative file and defines the conditions for test bedding we stick to [we added a few]). The White House (Dick Clarke) worked along the same lines after 9/11 and came with a very powerful evaluation showing that the internet represented a nuclear equivalent risk to the USA through the vulnerability of critical infrastructures and the impact on the US economy and way of life of a major dysfunction. We could measure it through the impact of the East Coast Black Out - should it have happened in Feb blizzard, the impact would have been devastating. This eventually lead to the http://whitehouse.gov/pcipb national strategy, the first visible impact we all know is the DoD IPv6 commitment. Let imagine that a terrorist atomic bomb blows Washington-West (the top worldwide target and an US working hypothesis). The propagation through the internet would be times devastating than the bomb itself on the USA. Regalian US duty will be to reserve most of the remaining internet bandwidth to civil security information and economy protection. P2P, adult, etc. traffic will not be a priority. The DNS is the control tool. We do not want to suffer from that in Europe or in the rest of the world, because there is no reason and because it would propagate the terror (and make the attempt more attractive and therefore more likely). So an European regalian duty is DNS risk containment, to protect us from the results of an attack of the US and to protect the US from being attacked. This is a very common strategy in network security. This means that every Gov has a regalian duty, not to load the ICANN/NTIA file, but to copy it like ORSN does. This copying must be carried with a take-over procedure to cope with a special national situation. A critical problem may be local. Or there may be an external attack. Let for example consider the Iraq invasion and the ".iq" management. The USA attacked ".iq" through spam DoS and lead Iraq to stop all their servers. An Iraqi externet would have made the Iraqi machine to switch to the Iraqi root they could have build the way they wanted (this same externet reasoning applies to IPv6 addresses and national numbering zones we support and document for years and the ITU now openly investigates - please remember that ITU is not an "internet opponent" but the Rep of regalian concerns). A very common hypothesis is a "Tchernobyl" like incident. TV waves pollution will make ADSL screens the best way to inform and calm the people through stable screams, with a major user demand peak. The control of the DNS would be vital. Another interesting point is that published reports are that only 2.5% of the root calls are legitimate, addressing based externets are a way to protect users at peak critical times. Their support in IPv6 numbering plan is a regalian demand that we should see develop in the coming months. It is also a network security issue to avoid pollution of the DNS in such cases. Obviously this is not the only resulting user architectural changes implied by the ICANN ICP-3 and WSIS real world consequences, as some mails documented it about DNS database usages. jfc morfin From johani at autonomica.se Thu Oct 28 15:38:46 2004 From: johani at autonomica.se (=?ISO-8859-1?Q?Johan_Ihr=E9n?=) Date: Thu, 28 Oct 2004 15:38:46 +0200 Subject: [dns-wg] Analysis of NSD In-Reply-To: <06d301c4bce7$0683e170$c8401cac@jjobbpc> References: <2684.1098875767@gromit.rfc1035.com> <064c01c4bc98$6e8d2050$c8401cac@jjobbpc> <06d301c4bce7$0683e170$c8401cac@jjobbpc> Message-ID: Hi J?rgen, On Oct 28, 2004, at 14:09, J?rgen Hovland wrote: >>> and different replies depending on the country origin of the source >>> ip of the querying nameserver/client. >> >> Oops. >> >> What's the justification for that? And what about maintaining DNS >> coherency? Any ideas on how to make this work with DNSSEC (I realize >> you're not doing DNSSEC today, but this would seem to be >> fundamentally incompatible with any DNSSEC use whatsoever). > > Load balancy. A bit similar to what Akamai is doing. Regarding > dnsssec we aren't quite there yet and don't have a solution to it. Hmm. Urgl. But I see your point (much as I don't like it). I think such things are rather evil (i.e. I'd rather have intelligent clients making informed decisions that have just barely sentient servers making decisions on my behalf based on assumptions about my environment). But I can understand that there's a demand for that type of service given that the average client is not intelligent at all but rather downright retarded. I want to see DNSSEC happen, so I'm naturally concerned when I see designs that I believe to be incompatible with DNSSEC, but I can understand that DNSSEC support has not been your most requested feature so far and sympathize with the lack of a solution. >> What happens to updates (to the master) that occur *during* the >> reload? My guess is that they get added to "the tail" of the reload >> to ensure that no change is left out during the reload. But in that >> case it seems to me that you already have the zone sorted in >> "transaction order" and the only thing needed to steer around the >> complete reloads would be some sort of version stamp that is shared >> between slave and master. Doesn't really have to be the SOA serial, >> you can use whatever you want. > > The slave connects and registers with the master first, locks sql in > read-only mode, clears unprocessed zone change messages from the > master (there is about 0.001% chance of any zone change messages at > this stage anyway) and then reloads from sql. Changes sent by the > master during this stage will be held in a queue and not processed > before reload is finished. This should guarantee that the local zone > data is equal to the master. If the slave should die during the lock a > certain timeout would unlock it. > > We do a complete reload since it only takes 3 seconds. This is where > it becomes interesting. Wait. Are you saying that a complete reload of the zone (where all the data moves from the master to the slave) takes 3 seconds? For how large a zone? Cannot be very large. Or are you saying that the nameserver basically closes the connection to the DB backend and then reopens it to read the data fresh (i.e. there is massive data movement between nameserver and DB backend within the slave, but only DB syncronization magic goes over the wire from the master)? Or are you saying that the slave does the sql reads over the wire from the DB (i.e. the SQL DB is not locally replicated on the slave)? I know next to nothing about DB machinery when it comes to stuff like replication, so please excuse my ignorance. > I am quite confident that comparing SOA/zone changes would actually > take longer time. At least for us using SQL since a SQL query will > take prox 20ms before a reply is given. Lets say 10% of the domains > were altered. This is a pretty high number though. You have to get the > new SOA's from SQL. Lets just say that this has already been done. > Now, 10% altered zones out of 30 millions equals to 1000 minutes in > latency only to deal with sql zone retrieve calls, not the processing > of the data. I am quite sure a raw dump would require less time and > less cpu resources by the sql server and perhaps even on the slave > depending I agree to the efficiency of a raw dump. However, I'm really dense today so I don't really understand why you're using a number as high as 30M *zones*. No offense, but no one ought to put that much infrastructure into any single system regardless of the underlying technology. I think a more realistic example would be to look at 30K zones and 1 minute. And furthermore I don't understand why it is not possible to parallellize those calls. Especially since they not all go to the same master. Or perhaps they do in your case? Is it possible to have a slave slave multiple zones from different masters with multiple TCP sessions in different directions? > on the size of each zone. If you only have a few large zones then of > course the result would not be the same. However if you have frequent > updates on these few large zones you would probably have to reload > everything anyway. You could always try reducing the amount of sql I mostly agree. If you have a few large zones (typically TLDs) my guess would be that even with a rather high volume of changes most of the changes would concern a smaller part of the data and hence IXFRs still make sense as long as you're able to keep the transaction logs. I.e. I have no idea whatsoever about the change frequency of .co.uk for example, but I'd be really surprised if not more than 60% stayed unchanged for a year. > calls by grouping them together, but that might look "ugly". > Nameservers doesn't usually lose connectivity anyway, but of course > they do time to time. Exactly. And that's the situation that interests me. That "ordinary operation" works just fine doesn't surprise me at all. > There is also a solution doing transaction logging when a slave gets > disconnected. We skipped this because it is easier to add and delete > new slaves without having to configure the master without. A > transaction log could also get very high if the slave was down for a > large amount of time and the implications generally about knowing if a > slave actually performed the change or not made us skip this. This is exactly the reasoning behind how IXFR works. I.e. a slave can request an IXFR with all the transactions from version N until now, but the master alway has the right to respond with an AXFR. This way the master may "jettison" the transaction log if it grows too much to be convenient to keep. As to knowing if a slave performed a change or not that is also taken care of by the SOA serial. So, since you don't have that (or something similar OOB wrt to DNS data as I suggested) I understand your reasoning. Johan From johani at autonomica.se Thu Oct 28 15:55:36 2004 From: johani at autonomica.se (=?ISO-8859-1?Q?Johan_Ihr=E9n?=) Date: Thu, 28 Oct 2004 15:55:36 +0200 Subject: [dns-wg] Re: Elimination of 2nd level ccTLD domain names In-Reply-To: <5.1.0.14.2.20041026200503.00afd288@imap.cwi.nl> References: <5.1.0.14.2.20041026200503.00afd288@imap.cwi.nl> Message-ID: <0B29087B-28E9-11D9-A2BA-000393DB5596@autonomica.se> Hi Piet, > Now you hit upon an interesting issue. In NL we were more or less > forced a couple of years ago to open up registration for private > persons too, the reasoning behind it being 'fixed' e-mail addresses > even when people moved to another ISP, which happened frequently. > Initially we 'solved' this by introducing numeric SLD's (123.nl), > under which they could register names. That was not a success, to > put it mildly: all in all we registered less than 1000 domains of > that kind. Main reason: people didn't like the numeric "extension". > More recently .NL itself was opened up for private persons too, but > now we see a vastly different situation from a couple of years ago: > because of the massive amounts of spam 'fixed' addresses are not > en vogue anymore and lots of people have loads of addresses. Which > is just one reason why I don't expect TLD's to explode and a good > example of a problem that solves itself. Interesting. While I've many times have seen spam described as a problem this it the first time ever I've seen it described as a solution to another problem ;-) Johan From jim at rfc1035.com Thu Oct 28 16:14:35 2004 From: jim at rfc1035.com (Jim Reid) Date: Thu, 28 Oct 2004 15:14:35 +0100 Subject: [dns-wg] Re: ORSN-SERVERS.NET In-Reply-To: Message from "JFC (Jefsey) Morfin" of "Thu, 28 Oct 2004 14:21:23 +0200." <6.1.2.0.2.20041028125528.03c207a0@mail.jefsey.com> Message-ID: <4972.1098972875@gromit.rfc1035.com> >>>>> "JFC" == JFC (Jefsey) Morfin writes: JFC> what ORSN does is risk containment. Suppose the ICANN/NTIA JFC> root is hacked. The ORSN file is not affected. This provides JFC> a protection. Could I please have some of whatever drugs you're taking? :-) IIUC this ORSN nonsense uses the root zone file as a starting point. So presumably any errors that get introduced there will be passed on to ORSN and its fellow travellers, no? JFC> Let imagine that a terrorist atomic bomb blows JFC> Washington-West (the top worldwide target and an US working JFC> hypothesis). The propagation through the internet would be JFC> times devastating than the bomb itself on the USA. First of all, I think most people would accept that any loss of life is far, far more devastating than the ability to route packets and make DNS lookups. Secondly, the root zone doesn't change much: TLDs renumber one of their servers now and again. Even if a major catastrophe destroyed the ability to change the root zone for a while -- I very much doubt that -- this would at worst be a minor inconvenience for TLD operators and the DNS in general. Good TLD managements will keep the old name servers running for at least a month or two after a renumbering. In fact a strong case can be made for NOT changing the root zone after such an event for stability reasons. Finally, suppose Something Bad has happened and the root can't be changed. Why would a TLD then choose to update their info in this bogus ORSN root while the info in the real root was unchanged? Wouldn't that lead to precisely the sort of inconsistency and network partitioning that the ORSN people claim they want to avoid? From jorgen at hovland.cx Thu Oct 28 16:44:26 2004 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Thu, 28 Oct 2004 15:44:26 +0100 Subject: [dns-wg] Analysis of NSD References: <2684.1098875767@gromit.rfc1035.com> <064c01c4bc98$6e8d2050$c8401cac@jjobbpc> <06d301c4bce7$0683e170$c8401cac@jjobbpc> Message-ID: <072301c4bcfc$a0c286a0$c8401cac@jjobbpc> ----- Original Message ----- From: "Johan Ihr?n" To: "J?rgen Hovland" Cc: Sent: Thursday, October 28, 2004 2:38 PM Subject: Re: [dns-wg] Analysis of NSD > Hi J?rgen, > > On Oct 28, 2004, at 14:09, J?rgen Hovland wrote: > >> We do a complete reload since it only takes 3 seconds. This is where it >> becomes interesting. > > Wait. Are you saying that a complete reload of the zone (where all the > data moves from the master to the slave) takes 3 seconds? For how large a > zone? Cannot be very large. Yes it's a rather small db with only 10k domains. This number is of course growing so the implementation had to support our future demands. > > Or are you saying that the nameserver basically closes the connection to > the DB backend and then reopens it to read the data fresh (i.e. there is > massive data movement between nameserver and DB backend within the slave, > but only DB syncronization magic goes over the wire from the master)? > > Or are you saying that the slave does the sql reads over the wire from the > DB (i.e. the SQL DB is not locally replicated on the slave)? > All nameservers connect to the same SQL server (only the master has read-write). Master is always connected due to updates issued by web/asp connections etc. Slaves are only connected during startup and during a reconnect to the master. We could replicate the db but then we would have some more syncronisation issues and we really don't see the point doing this for now. We use replication only for backup purposes. If the sql server is down then the slaves wont reload during master reconnect right away. They will retry for a few times before giving up. > I agree to the efficiency of a raw dump. However, I'm really dense today > so I don't really understand why you're using a number as high as 30M > *zones*. No offense, but no one ought to put that much infrastructure into > any single system regardless of the underlying technology. > I think a more realistic example would be to look at 30K zones and 1 > minute. And furthermore I don't understand why it is not possible to > parallellize those calls. > The 30M was just to show some large numbers. There won't be less domains in the future than now thats for sure. A 30K ns with the same 10% would only result in 1minute latency, but this is still a lot more than what a full dump would use including handling the data and everything to having a fresh copy. > Especially since they not all go to the same master. Or perhaps they do in > your case? Is it possible to have a slave slave multiple zones from > different masters with multiple TCP sessions in different directions? There can be only one to rule them all, but a slave can also be a master for other slaves again although we don't use this feature. >> on the size of each zone. If you only have a few large zones then of >> course the result would not be the same. However if you have frequent >> updates on these few large zones you would probably have to reload >> everything anyway. You could always try reducing the amount of sql > > I mostly agree. If you have a few large zones (typically TLDs) my guess > would be that even with a rather high volume of changes most of the > changes would concern a smaller part of the data and hence IXFRs still > make sense as long as you're able to keep the transaction logs. I.e. I > have no idea whatsoever about the change frequency of .co.uk for example, > but I'd be really surprised if not more than 60% stayed unchanged for a > year. > > > This is exactly the reasoning behind how IXFR works. I.e. a slave can > request an IXFR with all the transactions from version N until now, but > the master alway has the right to respond with an AXFR. This way the > master may "jettison" the transaction log if it grows too much to be > convenient to keep. Sorry I should have said transaction log slash IXFR, not just transaction log. Anyway you are absolutely correct but we chose to skip this feature. IXFR is definately a good way to deal with zone synchronization (for existing zones as far as I am aware of). The dump implementation we use synchronizes everything including new and deleted zones. Joergen Hovland ENK From grin at grin.hu Thu Oct 28 18:07:57 2004 From: grin at grin.hu (Peter Gervai) Date: Thu, 28 Oct 2004 18:07:57 +0200 Subject: [dns-wg] ripe policy about reverse dns? Message-ID: <20041028160755.GT2947@narya.grin.hu> Hello, I tend to remember that RIPE had a strict policy about delegated address space reverse DNS: adresses must have a valid reverse and delegated (sub) blocks must be registered in RIPE db. I wanted to refer to the document mentioning these requirements but I was not able to find them. Navigating on www.ripe.net helped nothing: reverse dns part shows the procedure, refers to a page "about ripe policies" which contains only links to RFC and other RIPE documents, which in turn are about the procedure and not any policy. Maybe there are any hidden one mentioning that "you should have reverse on your addresses" but I kindly ask your help where to look for it. If this requirement would have been dropped then I'd be extremely happy to know about it. Thank you, Peter ps: Reason is a(nother) big provider with many /19 and with no reverse or RIPE entry (other than the /19) whatsoever, and occasional spam from these reverseless and nameless blocks. From jefsey at jefsey.com Thu Oct 28 18:14:43 2004 From: jefsey at jefsey.com (JFC (Jefsey) Morfin) Date: Thu, 28 Oct 2004 18:14:43 +0200 Subject: [dns-wg] Re: ORSN-SERVERS.NET In-Reply-To: <4972.1098972875@gromit.rfc1035.com> References: <4972.1098972875@gromit.rfc1035.com> Message-ID: <6.1.2.0.2.20041028175130.03c019a0@mail.jefsey.com> At 16:14 28/10/2004, Jim Reid wrote: > >>>>> "JFC" == JFC (Jefsey) Morfin writes: > > JFC> what ORSN does is risk containment. Suppose the ICANN/NTIA > JFC> root is hacked. The ORSN file is not affected. This provides > JFC> a protection. > >Could I please have some of whatever drugs you're taking? :-) Dear Mr. Reid, I have given you a public source: http://whitehouse.gov/pcipb. I suppose that your speed in responding did not permit you to fully inhalate that long document. I am sure that you have in your own country some Intelligence or Critical Risks service which can brief you on your national blend. >IIUC this ORSN nonsense uses the root zone file as a starting >point. So presumably any errors that get introduced there will be >passed on to ORSN and its fellow travellers, no? You presume wrong in this case. The last one which presume risk containment was OK was named "Titanic". Let stop criticizing for the fun of it, and let us start criticizing things for the serious of them and security and in this case national security. > JFC> Let imagine that a terrorist atomic bomb blows > JFC> Washington-West (the top worldwide target and an US working > JFC> hypothesis). The propagation through the internet would be > JFC> times devastating than the bomb itself on the USA. > >First of all, I think most people would accept that any loss of life >is far, far more devastating than the ability to route packets and >make DNS lookups. I am afraid you missed the point. A WH evaluation in a preparatory document, established the death toll of an accumulation of network incident affecting critical installations or population behaviors to 2 millions deaths (in Chicago if my memories are correct). It also documented the number of typical attack which would lead to a situation and their hyperbolic increase in number and penetration over the last two years. Let understand there are two situations. One is the one you consider which is to keep in mind and which is much unlikely. This would be a root file hacking. The problem is the one that Brazil and others documented at the WSIS. It would be quite hurting in term of cost and the indirect death toll would in most of the cases be low and difficult to establish (non performed access to vital services for examples, accidents resulting from a stress, duress, etc. created). The other situation which the big one is when there is critical attack on some network systems of importance and that a response is to be provided. Then Authorities are to take decisions which are necessarily create technical, political or even military conflicts. I took the case of Iraq as a situation everyone can understand and everyone accepts as an exception. The what will create a problem is the consequence of that decision (reallocating a ccTLD for example - ie an e-embargo on a contry without UN mandate - which is disapproved by some other countries which will introduce their own ccTLD manager creating a pollution, which may chain to others). When Peter De Blanc told Mike Roberts that he should not push ccTLDs to use their nulcear arsenal, this is exactly what he meant, and the impact today would not be far. Obviously there are many other issues to this. And I know you are you cute and experienced enough to imagine them, what it implies for the DNS, etc. All the best. jfcm >Secondly, the root zone doesn't change much: TLDs renumber one of >their servers now and again. Even if a major catastrophe destroyed the >ability to change the root zone for a while -- I very much doubt that >-- this would at worst be a minor inconvenience for TLD operators and >the DNS in general. Good TLD managements will keep the old name >servers running for at least a month or two after a renumbering. In >fact a strong case can be made for NOT changing the root zone after >such an event for stability reasons. > >Finally, suppose Something Bad has happened and the root can't be >changed. Why would a TLD then choose to update their info in this >bogus ORSN root while the info in the real root was unchanged? >Wouldn't that lead to precisely the sort of inconsistency and network >partitioning that the ORSN people claim they want to avoid? From td at nominet.org.uk Thu Oct 28 18:53:59 2004 From: td at nominet.org.uk (Jay Daley) Date: Thu, 28 Oct 2004 17:53:59 +0100 Subject: [dns-wg] Re: ORSN-SERVERS.NET In-Reply-To: <6.1.2.0.2.20041028125528.03c207a0@mail.jefsey.com> Message-ID: Jefsey I have read this message several times and I still do not understand it. I have an eerie feeling that we might live in parallel universes. However, I have attempted a sensible reply. "JFC (Jefsey) Morfin" wrote on 28/10/2004 13:21:23: > > Jay, > I will try to review this key point for the internet development. > > what ORSN does is risk containment. Suppose the ICANN/NTIA root is hacked. > The ORSN file is not affected. This provides a protection. Now, obviously, > if the delay in updating the ORSN file is too long it is going to pollute > the namespace with old data. This is why trouble shouting calls for a > report on possible differences. Such report must be taken both ways: > - a way to know that ORSN is outdated > - an alarm that the ICANN/NTIA root may be hacked. This is plain nonsense. Are you saying that ORSN examines any changes made in the root zone by hand and then contact the TLD manager to make sure those changes were correct? If not then how does anyone know if it has been hacked? > > This kind of issue has been identified by the dot-root project of a DNS > test bed we carried last years. This has lead us to work on local roots > concepts and eventually on the authoritative root matrix (which is not > documented, but implemented in reality through the additional name servers > entered in the top level through ccTLD db.files for example). Are you saying there is a whole group of ccTLDs who have added ORSN to their configs? If so then who? > > This also lead to the AFRAC project (http://afrac.org) to unlock root files > (like the ICANN/NTIA root file) as this is true for any other application > root file, through contextual root files for what we named "externets" (ie > an external global view of the internet). For example, a Japanese externet > can be all the users and hosts which freely chose to belong to it. End to > end relations may then be limited to these externet members (only people > able to read Japanese). You can belong to many externets. In the case of a > nation, we identified that a national externet is a regalian duty. I have looked up regalian in the dictionary and I am completely lost. What do you think it means? > > What does that mean? > > It means that many things may happen which affect your sure national use of > the DNS. In 99.99% of the case that you use an US, a French, an European or > a East-Timor root server is the same. But in critical occasions you will > want to use a nameserver which will follow the rules which protect your > skin. What rules would they be? > We developed this kind of thinking in parallel to the White House - > [weird stuff snipped] > This eventually lead to the http://whitehouse.gov/pcipb > national strategy, the first visible impact we all know is the DoD IPv6 > commitment. This is all extremely odd. Can you point me to a particular page in that huge mass of documents that has some direct relevance to ORSN? > > [really weird stuff snipped] > > This means that every Gov has a regalian duty, not to load the ICANN/NTIA > file, but to copy it like ORSN does. This copying must be carried with a > take-over procedure to cope with a special national situation. A critical > problem may be local. What is the difference between a copy and a copy (sorry loading)? > [more weird stuff snipped] > Jay From randy at psg.com Thu Oct 28 19:24:14 2004 From: randy at psg.com (Randy Bush) Date: Thu, 28 Oct 2004 10:24:14 -0700 Subject: [dns-wg] Re: ORSN-SERVERS.NET References: <00aa01c4b829$f0aebd50$6e8392d9@client.hildesheim.wfi.de> <6.1.2.0.2.20041028125528.03c207a0@mail.jefsey.com> Message-ID: <16769.11070.927364.501398@roam.psg.com> it would be kind if you alternate root folk would take your discussion over to an alternate list in an alternate universe. we're trying to operate the real internet, and that's hard enough. randy From jon at lawrence.org.uk Thu Oct 28 20:14:58 2004 From: jon at lawrence.org.uk (Jon Lawrence) Date: Thu, 28 Oct 2004 19:14:58 +0100 Subject: [dns-wg] Re: ORSN-SERVERS.NET In-Reply-To: <16769.11070.927364.501398@roam.psg.com> References: <00aa01c4b829$f0aebd50$6e8392d9@client.hildesheim.wfi.de> <6.1.2.0.2.20041028125528.03c207a0@mail.jefsey.com> <16769.11070.927364.501398@roam.psg.com> Message-ID: <200410281914.58254.jon@lawrence.org.uk> On Thursday 28 October 2004 18:24, Randy Bush wrote: > it would be kind if you alternate root folk would take your > discussion over to an alternate list in an alternate universe. > we're trying to operate the real internet, and that's hard > enough. > Maybe I'm thick, but I still don't get it. What is the advantage of ORSN over the ICANN root ? Jon From jim at rfc1035.com Thu Oct 28 20:32:18 2004 From: jim at rfc1035.com (Jim Reid) Date: Thu, 28 Oct 2004 19:32:18 +0100 Subject: [dns-wg] Re: ORSN-SERVERS.NET In-Reply-To: Message from Jon Lawrence of "Thu, 28 Oct 2004 19:14:58 BST." <200410281914.58254.jon@lawrence.org.uk> Message-ID: <5489.1098988338@gromit.rfc1035.com> >>>>> "Jon" == Jon Lawrence writes: Jon> Maybe I'm thick, but I still don't get it. What is the Jon> advantage of ORSN over the ICANN root ? I have no idea. However this list is not the place to discuss this topic further. It's essentially a local policy matter and is therefore inappropriate for the DNS WG. If someone wants to set up a mailing list to debate this, please go ahead and do so. Tell us where it is and how to subscribe and unsubscribe. Other than that, I would appreciate it if the discussion of alternate roots stopped in this list. Thanks. From jakob at rfc.se Thu Oct 28 22:39:47 2004 From: jakob at rfc.se (Jakob Schlyter) Date: Thu, 28 Oct 2004 22:39:47 +0200 (CEST) Subject: [dns-wg] Jumping the gun on SIDN! In-Reply-To: <20041028130720.GB30090@hog.ipng.nl> References: <20041028130720.GB30090@hog.ipng.nl> Message-ID: On Thu, 28 Oct 2004, Pim van Pelt wrote: > nsauth1.bit.nl. 86400 IN A 213.136.12.51 > nsauth2.bit.nl. 86400 IN A 213.136.12.59 > nsauth3.bit.nl. 86400 IN A 212.204.192.11 > nsauth1.bit.nl. 86400 IN AAAA 2001:7b8:3:2c::53 > nsauth2.bit.nl. 86400 IN AAAA 2001:7b8:3:2d::53 > nsauth3.bit.nl. 86400 IN AAAA 2001:898:1001:1003::53 IIRC there are still bind8 server out there that will choke on zone where all nameservers have both IPv4 and IPv6 addresses - it might be a good idea to keep at least one IPv4-only server. jakob From jefsey at jefsey.com Thu Oct 28 23:24:42 2004 From: jefsey at jefsey.com (JFC (Jefsey) Morfin) Date: Thu, 28 Oct 2004 23:24:42 +0200 Subject: [dns-wg] Re: ORSN-SERVERS.NET In-Reply-To: <5489.1098988338@gromit.rfc1035.com> References: <5489.1098988338@gromit.rfc1035.com> Message-ID: <6.1.2.0.2.20041028230855.0e1436f0@mail.jefsey.com> At 20:32 28/10/2004, Jim Reid wrote: > >>>>> "Jon" == Jon Lawrence writes: > > Jon> Maybe I'm thick, but I still don't get it. What is the > Jon> advantage of ORSN over the ICANN root ? > >I have no idea. > >However this list is not the place to discuss this topic further. It's >essentially a local policy matter and is therefore inappropriate for >the DNS WG. If someone wants to set up a mailing list to debate this, >please go ahead and do so. Tell us where it is and how to subscribe >and unsubscribe. Other than that, I would appreciate it if the >discussion of alternate roots stopped in this list. Thanks. Jim, Jay asked a question I responded. Then _you_asked a question I responded too. Hardly a discussion. I will be glad to keep responding, as this is a key issue (cf. RFC 3869, 3.2.1 last paragraph), but you may want to keep your mails private as did others. As Randy says, we try to run the real internet in here. We agree, even if I am not sure about what "real" means in this case? Anyway, I apologize if I gave anyone the feeling that I was talking about "alternate root" or a "local policy matter". This was not the intent nor the case. jfc From bortzmeyer at nic.fr Fri Oct 29 09:19:52 2004 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 29 Oct 2004 09:19:52 +0200 Subject: [dns-wg] Re: Re: ORSN-SERVERS.NET In-Reply-To: References: <6.1.2.0.2.20041028125528.03c207a0@mail.jefsey.com> Message-ID: <20041029071952.GA2202@nic.fr> On Thu, Oct 28, 2004 at 05:53:59PM +0100, Jay Daley wrote a message of 99 lines which said: > > nation, we identified that a national externet is a regalian duty. > > I have looked up regalian in the dictionary and I am completely > lost. What do you think it means? Webster: Regalian \Re*ga"li*an\ (-an), a. Pertaining to regalia; pertaining to the royal insignia or prerogatives. --Hallam. It means it is a duty of the Governement / State to manage a "national externet" (a concept which is much fuzzier than "regalian duty"). From jay at nominet.org.uk Thu Oct 28 18:44:48 2004 From: jay at nominet.org.uk (Jay Daley) Date: Thu, 28 Oct 2004 17:44:48 +0100 Subject: [dns-wg] Re: ORSN-SERVERS.NET In-Reply-To: <6.1.2.0.2.20041028125528.03c207a0@mail.jefsey.com> Message-ID: Jefsey I have read this message several times and I still do not understand it. I have an eerie feeling that we might live in parallel universes. However, I have attempted a sensible reply. "JFC (Jefsey) Morfin" wrote on 28/10/2004 13:21:23: > > Jay, > I will try to review this key point for the internet development. > > what ORSN does is risk containment. Suppose the ICANN/NTIA root is hacked. > The ORSN file is not affected. This provides a protection. Now, obviously, > if the delay in updating the ORSN file is too long it is going to pollute > the namespace with old data. This is why trouble shouting calls for a > report on possible differences. Such report must be taken both ways: > - a way to know that ORSN is outdated > - an alarm that the ICANN/NTIA root may be hacked. This is plain nonsense. Are you saying that ORSN examines any changes made in the root zone by hand and then contact the TLD manager to make sure those changes were correct? If not then how does anyone know if it has been hacked? > > This kind of issue has been identified by the dot-root project of a DNS > test bed we carried last years. This has lead us to work on local roots > concepts and eventually on the authoritative root matrix (which is not > documented, but implemented in reality through the additional name servers > entered in the top level through ccTLD db.files for example). Are you saying there is a whole group of ccTLDs who have added ORSN to their configs? If so then who? > > This also lead to the AFRAC project (http://afrac.org) to unlock root files > (like the ICANN/NTIA root file) as this is true for any other application > root file, through contextual root files for what we named "externets" (ie > an external global view of the internet). For example, a Japanese externet > can be all the users and hosts which freely chose to belong to it. End to > end relations may then be limited to these externet members (only people > able to read Japanese). You can belong to many externets. In the case of a > nation, we identified that a national externet is a regalian duty. I have looked up regalian in the dictionary and I am completely lost. What do you think it means? > > What does that mean? > > It means that many things may happen which affect your sure national use of > the DNS. In 99.99% of the case that you use an US, a French, an European or > a East-Timor root server is the same. But in critical occasions you will > want to use a nameserver which will follow the rules which protect your > skin. What rules would they be? > We developed this kind of thinking in parallel to the White House - > [weird stuff snipped] > This eventually lead to the http://whitehouse.gov/pcipb > national strategy, the first visible impact we all know is the DoD IPv6 > commitment. This is all extremely odd. Can you point me to a particular page in that huge mass of documents that has some direct relevance to ORSN? > > [really weird stuff snipped] > > This means that every Gov has a regalian duty, not to load the ICANN/NTIA > file, but to copy it like ORSN does. This copying must be carried with a > take-over procedure to cope with a special national situation. A critical > problem may be local. What is the difference between a copy and a copy (sorry loading)? > [more weird stuff snipped] > Jay From kurtis at kurtis.pp.se Sun Oct 24 14:11:09 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Sun, 24 Oct 2004 14:11:09 +0200 Subject: [dns-wg] Re: ORSN-SERVERS.NET In-Reply-To: <00aa01c4b829$f0aebd50$6e8392d9@client.hildesheim.wfi.de> References: <005901c4b81b$40bccf80$6e8392d9@client.hildesheim.wfi.de> <00aa01c4b829$f0aebd50$6e8392d9@client.hildesheim.wfi.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-10-22, at 13.26, Markus Grundmann/ORSN wrote: > >> You can't have it both ways. Either you have an independent >> root-zone, or >> it is ICANN based. If you have any technical concerns about the >> database management of the ICANN sanctioned servers, then you would >> have a >> point if the argument would be valid. It seems to me however you have >> political concerns with regards to database management (as in who >> manages > > Yes! ORSN has an political background but I think that is not bad. > Projects like ORSC (*ggrr*) undermines DNS. ! And not ORSN ! And your added value is? Besides increased risk of serving false data, and spreading FUD? - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQXucC6arNKXTPFCVEQJJ0QCgndWaOKDLQGxiFVQFT0QjLww2ItIAoKtz DdPYtohQdFFxFUwa26enTB5M =eKeD -----END PGP SIGNATURE-----