uDNS Root Name Servers Taking Shape
As promised, it looks like the uDNS[1] Root Name Server Confederation is taking shape. The founders appear to be taking a careful approach and are adding more servers. The eDNS Root Name Server Confederation will remain stable to continue to serve ISPs. There are 5 servers in the eDNS Root Name Server Confederation. The major Root Name Server Confederations are now: AlterNIC InterNIC eDNS name.space NSI/ISI uDNS When the uDNS Root Name Server Confederation reaches 4 servers, it will be added to the automated reportin system that helps to keep all of the Root Name Server Confederations in "synch". [1] ========================================= ; <<>> DiG 2.1 <<>> @208.195.108.8 . any ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 ;; flags: qr aa rd ra; Ques: 1, Ans: 4, Auth: 3, Addit: 3 ;; QUESTIONS: ;; ., type = ANY, class = IN ;; ANSWERS: . 172800 SOA root.starfire.douglas.ma.us. hostmaster.starfire.douglas.ma.us. ( 1997052900 ; serial 43200 ; refresh (12 hours) 900 ; retry (15 mins) 604800 ; expire (7 days) 172800 ) ; minimum (2 days) . 518400 NS root.starfire.douglas.ma.us. . 518400 NS hp.manhattan.com. . 518400 NS DONTSERF.MAKEWAVES.NET. ;; AUTHORITY RECORDS: . 518400 NS root.starfire.douglas.ma.us. . 518400 NS hp.manhattan.com. . 518400 NS DONTSERF.MAKEWAVES.NET. ;; ADDITIONAL RECORDS: root.starfire.douglas.ma.us. 86400 A 208.195.108.8 hp.manhattan.com. 172800 A 199.103.194.137 DONTSERF.MAKEWAVES.NET. 172800 A 204.94.43.1 ;; Total query time: 5393 msec ;; FROM: doormat.unety.net to SERVER: 208.195.108.8 ;; WHEN: Fri May 30 01:31:17 1997 ;; MSG SIZE sent: 17 rcvd: 254 ============================================
[1] ========================================= ; <<>> DiG 2.1 <<>> @208.195.108.8 . any ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 ;; flags: qr aa rd ra; Ques: 1, Ans: 4, Auth: 3, Addit: 3 ;; QUESTIONS: ;; ., type = ANY, class = IN
;; ANSWERS: . 172800 SOA root.starfire.douglas.ma.us. hostmaster.starfire.douglas.ma.us. ( 1997052900 ; serial 43200 ; refresh (12 hours) 900 ; retry (15 mins) 604800 ; expire (7 days) 172800 ) ; minimum (2 days) . 518400 NS root.starfire.douglas.ma.us. . 518400 NS hp.manhattan.com. . 518400 NS DONTSERF.MAKEWAVES.NET.
;; AUTHORITY RECORDS: . 518400 NS root.starfire.douglas.ma.us. . 518400 NS hp.manhattan.com. . 518400 NS DONTSERF.MAKEWAVES.NET.
;; ADDITIONAL RECORDS: root.starfire.douglas.ma.us. 86400 A 208.195.108.8
Multi-homed condition unknown and suspect due to truncated BGP path. Approximate bandwidth from the core to this point on the network from us at this point in time: 34.56kbps, or a good modem line :-) hop packets min rtt BW (ttl) in out (mS) k bps Address MTU=8166 MTU=4352 MTU=2002 MTU=1492 TT = 10 9 13 53.55 = 34.56 208.195.108.8 root.starfire.douglas.ma.us **** NOTICE: THIS NAMESERVER IS RUNNING WITH RECURSION ENABLED AND IS NOT A TRUE ROOT.
hp.manhattan.com. 172800 A 199.103.194.137
Aggregated by (and complete path from) Open Advisors. Appears to be multi-homed. Approximate bandwidth to this point on the network: 65.28kbps, or a single-channel ISDN equivalent. hop packets min rtt BW (ttl) in out (mS) k bps Address = 15 17 18 318.58 = 65.28 199.103.194.137 **** NOTICE: THIS NAMESERVER IS RUNNING WITH RECURSION ENABLED AND IS NOT A TRUE ROOT.
DONTSERF.MAKEWAVES.NET. 172800 A 204.94.43.1
Alternic under a different name, operated by Diane Boling, and running with both nameservers on the same subnet. Linked to Seanet, which appears to be multihomed. Approximate bandwidth to this point on the network: 629kbps (my god, they have one root with a fractional T1 worth of bandwidth available!) **** NOTICE: THIS NAMESERVER IS ALSO RUNNING WITH RECURSION ENABLED AND IS NOT A TRUE ROOT. I rest my case. Only one of these has anything approaching reasonable connectivity, all appear to be off single-point failure circuits (except possibly manhattan.com), and all are running in non-RFC2010 mode. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 99 Analog numbers, 77 ISDN, http://www.mcs.net/ Voice: [+1 312 803-MCS1 x219]| NOW Serving 56kbps DIGITAL on our analog lines! Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
On Thu, 29 May 1997 18:03:13 -0500, Karl wrote:
;; ADDITIONAL RECORDS: root.starfire.douglas.ma.us. 86400 A 208.195.108.8 Multi-homed condition unknown and suspect due to truncated BGP path.
Yup, not multihomed until the new router comes in. :-(
Approximate bandwidth from the core to this point on the network from us at this point in time: 34.56kbps, or a good modem line :-)
Gee, it's a T1 from here, must be a problem on your end. <grin>
THIS NAMESERVER IS RUNNING WITH RECURSION ENABLED
Yup, until next week when we get the new box up.
AND IS NOT A TRUE ROOT.
Says you, the grand high holy keeper of the ONE TRUE ROOTS. Ha!
hp.manhattan.com. 172800 A 199.103.194.137 Aggregated by (and complete path from) Open Advisors. Appears to be multi-homed.
Yup.
Approximate bandwidth to this point on the network: 65.28kbps, or a single-channel ISDN equivalent.
You really should check your lines Karl, a multihomed server on a single channel ISDN, I don't think so...
**** NOTICE: THIS NAMESERVER IS RUNNING WITH RECURSION
Hmm... the name.boot file has it set off. I'll check it out. AND IS NOT A TRUE ROOT. <yawn>
DONTSERF.MAKEWAVES.NET. 172800 A 204.94.43.1 Alternic under a different name, operated by Diane Boling, and running with both nameservers on the same subnet. Linked to Seanet, which appears to be multihomed.
Yup.
Approximate bandwidth to this point on the network: 629kbps (my god, they have one root with a fractional T1 worth of bandwidth available!)
Well, I guess your lines came back up! <grin>
**** NOTICE: THIS NAMESERVER IS ALSO RUNNING WITH RECURSION ENABLED
could be. AND IS NOT A TRUE ROOT. <yawn>
I rest my case. Only one of these has anything approaching reasonable connectivity, all appear to be off single-point failure circuits (except possibly manhattan.com), and all are running in non-RFC2010 mode.
Yah, we really need RFC2010 servers to run 1/2% of the internet - NOT! Seriously, our schedule calls for 5 dedicated, non-recursive servers up by next week this time, with T1 of better connectivity. We plan full RFC2010 by the time we reach 5% visibility. Feel free to market your system's RFC2010 compliance as an absolute must for servers that handle a fraction of a percent of the internet's DNS requests, I'd be surprised if any of the "internet aware" people on these lists you are posting to care... Take care, Ron Kimball for the uDNS council
kook fight in the parking lot at 3 o'clock after school! On Fri, 30 May 1997, Ron Kimball wrote:
On Thu, 29 May 1997 18:03:13 -0500, Karl wrote:
;; ADDITIONAL RECORDS: root.starfire.douglas.ma.us. 86400 A 208.195.108.8 Multi-homed condition unknown and suspect due to truncated BGP path.
Yup, not multihomed until the new router comes in. :-(
Approximate bandwidth from the core to this point on the network from us at this point in time: 34.56kbps, or a good modem line :-)
Gee, it's a T1 from here, must be a problem on your end. <grin>
THIS NAMESERVER IS RUNNING WITH RECURSION ENABLED
Yup, until next week when we get the new box up.
AND IS NOT A TRUE ROOT.
Says you, the grand high holy keeper of the ONE TRUE ROOTS. Ha!
hp.manhattan.com. 172800 A 199.103.194.137 Aggregated by (and complete path from) Open Advisors. Appears to be multi-homed.
Yup.
Approximate bandwidth to this point on the network: 65.28kbps, or a single-channel ISDN equivalent.
You really should check your lines Karl, a multihomed server on a single channel ISDN, I don't think so...
**** NOTICE: THIS NAMESERVER IS RUNNING WITH RECURSION
Hmm... the name.boot file has it set off. I'll check it out.
AND IS NOT A TRUE ROOT.
<yawn>
DONTSERF.MAKEWAVES.NET. 172800 A 204.94.43.1 Alternic under a different name, operated by Diane Boling, and running with both nameservers on the same subnet. Linked to Seanet, which appears to be multihomed.
Yup.
Approximate bandwidth to this point on the network: 629kbps (my god, they have one root with a fractional T1 worth of bandwidth available!)
Well, I guess your lines came back up! <grin>
**** NOTICE: THIS NAMESERVER IS ALSO RUNNING WITH RECURSION ENABLED
could be.
AND IS NOT A TRUE ROOT.
<yawn>
I rest my case. Only one of these has anything approaching reasonable connectivity, all appear to be off single-point failure circuits (except possibly manhattan.com), and all are running in non-RFC2010 mode.
Yah, we really need RFC2010 servers to run 1/2% of the internet - NOT!
Seriously, our schedule calls for 5 dedicated, non-recursive servers up by next week this time, with T1 of better connectivity. We plan full RFC2010 by the time we reach 5% visibility. Feel free to market your system's RFC2010 compliance as an absolute must for servers that handle a fraction of a percent of the internet's DNS requests, I'd be surprised if any of the "internet aware" people on these lists you are posting to care...
Take care, Ron Kimball for the uDNS council
Will the Newdom, Edns, Udns, Ufp, Confederations, Federations, and morons alike please take it to your respective lists. NANOG, as has been stated so often even you guys can get it, is for operations issues. DNS "as is" is an operations issue. DNS "as you wish it were" is something for you to discuss till you're blue in the face. I'm tired of this drivel, and you keep adding lists and idiots I can't killfile it fast enough. Ehud
On Thu, 29 May 1997 18:03:13 -0500, Karl wrote:
;; ADDITIONAL RECORDS: root.starfire.douglas.ma.us. 86400 A 208.195.108.8 Multi-homed condition unknown and suspect due to truncated BGP path.
Yup, not multihomed until the new router comes in. :-(
Approximate bandwidth from the core to this point on the network from us at this point in time: 34.56kbps, or a good modem line :-)
Gee, it's a T1 from here, must be a problem on your end. <grin>
THIS NAMESERVER IS RUNNING WITH RECURSION ENABLED
Yup, until next week when we get the new box up.
AND IS NOT A TRUE ROOT.
Says you, the grand high holy keeper of the ONE TRUE ROOTS. Ha!
hp.manhattan.com. 172800 A 199.103.194.137 Aggregated by (and complete path from) Open Advisors. Appears to be multi-homed.
Yup.
Approximate bandwidth to this point on the network: 65.28kbps, or a single-channel ISDN equivalent.
You really should check your lines Karl, a multihomed server on a single channel ISDN, I don't think so...
**** NOTICE: THIS NAMESERVER IS RUNNING WITH RECURSION
Hmm... the name.boot file has it set off. I'll check it out.
AND IS NOT A TRUE ROOT.
<yawn>
DONTSERF.MAKEWAVES.NET. 172800 A 204.94.43.1 Alternic under a different name, operated by Diane Boling, and running with both nameservers on the same subnet. Linked to Seanet, which appears to be multihomed.
Yup.
Approximate bandwidth to this point on the network: 629kbps (my god, they have one root with a fractional T1 worth of bandwidth available!)
Well, I guess your lines came back up! <grin>
**** NOTICE: THIS NAMESERVER IS ALSO RUNNING WITH RECURSION ENABLED
could be.
AND IS NOT A TRUE ROOT.
<yawn>
I rest my case. Only one of these has anything approaching reasonable connectivity, all appear to be off single-point failure circuits (except possibly manhattan.com), and all are running in non-RFC2010 mode.
Yah, we really need RFC2010 servers to run 1/2% of the internet - NOT!
Seriously, our schedule calls for 5 dedicated, non-recursive servers up by next week this time, with T1 of better connectivity. We plan full RFC2010 by the time we reach 5% visibility. Feel free to market your system's RFC2010 compliance as an absolute must for servers that handle a fraction of a percent of the internet's DNS requests, I'd be surprised if any of the "internet aware" people on these lists you are posting to care...
Take care, Ron Kimball for the uDNS council
I have already been labelled a kook. C'mon DNS people. Please move your discussions elsewhere..... On Thu, 29 May 1997, Ehud Gavron wrote:
Will the Newdom, Edns, Udns, Ufp, Confederations, Federations, and morons alike please take it to your respective lists.
NANOG, as has been stated so often even you guys can get it, is for operations issues. DNS "as is" is an operations issue. DNS "as you wish it were" is something for you to discuss till you're blue in the face.
I'm tired of this drivel, and you keep adding lists and idiots I can't killfile it fast enough.
Ehud
On Thu, 29 May 1997 18:03:13 -0500, Karl wrote:
;; ADDITIONAL RECORDS: root.starfire.douglas.ma.us. 86400 A 208.195.108.8 Multi-homed condition unknown and suspect due to truncated BGP path.
Yup, not multihomed until the new router comes in. :-(
Approximate bandwidth from the core to this point on the network from us at this point in time: 34.56kbps, or a good modem line :-)
Gee, it's a T1 from here, must be a problem on your end. <grin>
THIS NAMESERVER IS RUNNING WITH RECURSION ENABLED
Yup, until next week when we get the new box up.
AND IS NOT A TRUE ROOT.
Says you, the grand high holy keeper of the ONE TRUE ROOTS. Ha!
hp.manhattan.com. 172800 A 199.103.194.137 Aggregated by (and complete path from) Open Advisors. Appears to be multi-homed.
Yup.
Approximate bandwidth to this point on the network: 65.28kbps, or a single-channel ISDN equivalent.
You really should check your lines Karl, a multihomed server on a single channel ISDN, I don't think so...
**** NOTICE: THIS NAMESERVER IS RUNNING WITH RECURSION
Hmm... the name.boot file has it set off. I'll check it out.
AND IS NOT A TRUE ROOT.
<yawn>
DONTSERF.MAKEWAVES.NET. 172800 A 204.94.43.1 Alternic under a different name, operated by Diane Boling, and running with both nameservers on the same subnet. Linked to Seanet, which appears to be multihomed.
Yup.
Approximate bandwidth to this point on the network: 629kbps (my god, they have one root with a fractional T1 worth of bandwidth available!)
Well, I guess your lines came back up! <grin>
**** NOTICE: THIS NAMESERVER IS ALSO RUNNING WITH RECURSION ENABLED
could be.
AND IS NOT A TRUE ROOT.
<yawn>
I rest my case. Only one of these has anything approaching reasonable connectivity, all appear to be off single-point failure circuits (except possibly manhattan.com), and all are running in non-RFC2010 mode.
Yah, we really need RFC2010 servers to run 1/2% of the internet - NOT!
Seriously, our schedule calls for 5 dedicated, non-recursive servers up by next week this time, with T1 of better connectivity. We plan full RFC2010 by the time we reach 5% visibility. Feel free to market your system's RFC2010 compliance as an absolute must for servers that handle a fraction of a percent of the internet's DNS requests, I'd be surprised if any of the "internet aware" people on these lists you are posting to care...
Take care, Ron Kimball for the uDNS council
uDNS mail. Hit D now.
On Thu, 29 May 1997 18:03:13 -0500, Karl wrote:
Approximate bandwidth from the core to this point on the network from us at this point in time: 34.56kbps, or a good modem line :-)
Gee, it's a T1 from here, must be a problem on your end. <grin>
THIS NAMESERVER IS RUNNING WITH RECURSION ENABLED
Yup, until next week when we get the new box up.
Why? Run out of pee-cee's for your little isp? Or do you have to wait until your buddy gets hired at his new ISP so you can move the quake server?
**** NOTICE: THIS NAMESERVER IS RUNNING WITH RECURSION
Hmm... the name.boot file has it set off. I'll check it out.
Somehow I fear putting my DNS in the hands of someone who says "Hmm..." over a named.boot file.
Seriously, our schedule calls for 5 dedicated, non-recursive servers up by next week this time, with T1 of better connectivity.
"Oh, we'll have quadruple this Real Soon Now(tm). We decided that it was a Good Thing to release this project with a crappy server and crappy links.. but honest.. we're fixing it!"
We plan full RFC2010 by the time we reach 5% visibility.
So.. never, right? I dont get it. Why wait until later to do things _right_? ..jgkr
On Thu, 29 May 1997 23:14:36 -0400 (EDT), Jamie Rishaw wrote:
uDNS mail. Hit D now.
Kind of like "Intel Inside". <grin>
Yup, until next week when we get the new box up. Why? Run out of pee-cee's for your little isp? Or do you have to wait until your buddy gets hired at his new ISP so you can move the quake server?
No, I've spent all my time recently responding to email. <grin> Seriously, I have two boxes sitting ithe corner of the server room, waiting for me to load Linux on them...
Hmm... the name.boot file has it set off. I'll check it out. Somehow I fear putting my DNS in the hands of someone who says "Hmm..." over a named.boot file.
What do you say when reading one over that isn't doing quite what you had in mind, "hoho!"?
Seriously, our schedule calls for 5 dedicated, non-recursive servers up by next week this time, with T1 of better connectivity. "Oh, we'll have quadruple this Real Soon Now(tm). We decided that it was a Good Thing to release this project with a crappy server and crappy links.. but honest.. we're fixing it!"
Our root server operators got uppidy and shut down the zone as of a couple hours from now, we didn't have a whole lot of time to "get it right" :-(
We plan full RFC2010 by the time we reach 5% visibility. So.. never, right?
<grin>
I dont get it. Why wait until later to do things _right_?
Oh, we will probably be RFC2010 in a month or two, but until we have serious hits happening, we aren't too worried about it. More important things need to be resolved in our operations. Come on over to the udns list and lend a hand. :-) Take care, Ron
Jamie Rishaw wrote:
Seriously, our schedule calls for 5 dedicated, non-recursive servers up by next week this time, with T1 of better connectivity.
"Oh, we'll have quadruple this Real Soon Now(tm). We decided that it was a Good Thing to release this project with a crappy server and crappy links.. but honest.. we're fixing it!"
We plan full RFC2010 by the time we reach 5% visibility.
So.. never, right?
I dont get it. Why wait until later to do things _right_?
Because we're not used to being members of organizations in which major decisions are driven by short-notice ultimatums. Because we had to act quickly when it became apparent that the root servers were likely to be arbitrarily reloaded with a set of TLDs less than the full set originally registered as eDNS TLDs. Because we are used to organizations that provide stability and reliability as key elements to foster an environment hospitable to business. Respectfully submitted, Richard Shu
I would really appreciate it, as I'm sure may other subscribers of the NANOG would, if you DNS combatants would take this discussion elsewhere, to a more appropriate list. I'm on the verge of constructing filters so that I don't have to see this cruft -- short of that, I'm now considering unsubscribing to the list. The signal/noise ratio has degenerated dramatically. Please remove nanog@merit.edu from the CC: line. - paul At 08:42 AM 05/30/97 -0400, Richard Shu wrote:
Because we're not used to being members of organizations in which major decisions are driven by short-notice ultimatums.
Because we had to act quickly when it became apparent that the root servers were likely to be arbitrarily reloaded with a set of TLDs less than the full set originally registered as eDNS TLDs.
Because we are used to organizations that provide stability and reliability as key elements to foster an environment hospitable to business.
Respectfully submitted, Richard Shu
On Fri, May 30, 1997 at 08:42:41AM -0400, Richard Shu wrote:
Jamie Rishaw wrote:
Seriously, our schedule calls for 5 dedicated, non-recursive servers up by next week this time, with T1 of better connectivity.
"Oh, we'll have quadruple this Real Soon Now(tm). We decided that it was a Good Thing to release this project with a crappy server and crappy links.. but honest.. we're fixing it!"
We plan full RFC2010 by the time we reach 5% visibility.
So.. never, right?
I dont get it. Why wait until later to do things _right_?
Because we're not used to being members of organizations in which major decisions are driven by short-notice ultimatums.
Because we had to act quickly when it became apparent that the root servers were likely to be arbitrarily reloaded with a set of TLDs less than the full set originally registered as eDNS TLDs.
Because we are used to organizations that provide stability and reliability as key elements to foster an environment hospitable to business.
Respectfully submitted, Richard Shu
Because the people who made eDNS TLDs resolve, the root server operators, got tired of people who were claiming TLDs with no ability to register in them, were collusively operated in violation of the charter, were being held out as "businesses" when in fact said "businesses" didn't legally exist under the laws of the state the "registry" claimed to be in, that some of the "registries" were unable to even quote a *PRICE* over the phone for registration (and it was nowhere to be found online either) and further the roots refused to continue when it became apparent that the RAs and Registries had no intent of resolving ANY of those problems. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 99 Analog numbers, 77 ISDN, http://www.mcs.net/ Voice: [+1 312 803-MCS1 x219]| NOW Serving 56kbps DIGITAL on our analog lines! Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
participants (10)
-
Ben Black -
Ehud Gavron -
hostmaster＠starfire.douglas.ma.us -
jamie＠dilbert.iagnet.net -
Jim Fleming -
Karl Denninger -
Karl Denninger
-
Marc Hurst -
Paul Ferguson -
Richard Shu