In <199702180144.TAA23839@Jupiter.Mcs.Net>, Karl Denninger <karl@Mcs.Net> wrote:

...

And shouldn't "root servers" have recursive queries turned off?:

Until VERY recently they weren't on the existing roots. And, by the way, while we're talking about that, what is this about hosting the 800,000-some- odd NSI domains on the roots?

Nice dodge. But you do then admit to having recursion available on your "new improved r00t n@m3s3rv3rs" for several months, until someone else pointed it out to you? "They did the same thing a while back!" isn't an acceptable answer. (I don't even think it's true. I haven't seen a recursive query answered via a root nameserver since I started actively doing DNS administration over a year ago.) Even if that is so, you shouldn't have made the same mistake, especially *after* the operators of the IANA root servers corrected the misconfiguration.

The point at hand, though, is that we haven't had *any* operational incidents since eDNS was launched that could be in any way traced to the other root servers. None at all.

Meanwhile, there have been several service-affecting issues on the IANA-sponsored roots in the same time frame.

I haven't seen any problems because of these supposed "service-affecting issues". Perhaps you should check the quality of your network connectivity?

What was that edict again? "Rough consensus and operational code"? We certainly do seem to have that.

The code's fine; it just appears you don't know how to configure it correctly. Try reading the BIND Operations Guide (BOG) next time; it says explicitly that the root nameservers should run with "options no-recursion". -- Michael Handler <handler@sub-rosa.com> Washington, D.C.

...

BTW, there are 2010-complient roots going in. And, if you secondary root from us, you'll get that update automatically when it happens.....

And, if you secondary "." from MCS, you will get data that only a small fraction of the net sees,

Along with all the data that the legacy nameservers have, and along with better performance (since we're not trying to run 800,000 zones on the same machines)

and it will conflict with data that large portions of the net see,

Really? What conflict? You mean the one which isn't real yet -- that the IAHC *created*?

and it will conflict with other petty fiefdoms run by other provincial wannabes who think that THEY and not MCS ought to run/own ".".

We don't claim to own or run ".". In fact, our solution has you *SECONDARYING* ".", which means that in general, other than the requirement for you to be able to reach a source for that file on a every-few-days basis (to check the SOA record) you no longer NEED connectivity to the root domain. This is demonstrably superior; you no longer need to make that query for ".", as you already know who is authoritative for all the TLDs under ".". -- -- 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, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal

On Tue, 18 Feb 1997 13:01:06 -0600 (CST), karl@mcs.net writes:

...

In fact, our solution has you *SECONDARYING* ".", which means that in general, other than the requirement for you to be able to reach a source for that file on a every-few-days basis (to check the SOA record) you no longer NEED connectivity to the root domain.

This is demonstrably superior; you no longer need to make that query for ".", as you already know who is authoritative for all the TLDs under ".".

Yiiii... Having everyone secondary "." sounds demonstrably inferior to me. Just think what would happen if every nameserver that is authoritative for a .com domain started secondarying ".". There are approximately 50,000 name servers that are authoritative for .com (according to the .com zone file from the InterNIC). That would mean that the system ROOT-NS.MCS.NET would waste around 5 queries per second because those 50,000 name servers would be trying to check the SOA (at the time that I write this, the eDNS servers list a 3 *hour* refresh interval for the root zone with a 15 *minute* retry interval). Just think what will happen to poor ROOT-NS.MCS.NET when the serial number changes!

With system currently in use, those 50,000 name servers would generate around 6 queries per second as those name servers refresh their list of root name servers - and those queries would be distributed fairly evenly among all of the root servers.

And to top it all off, there are probably at least 2-3 times as many name servers that are not authoritative for a .com domain. Boy, that ROOT-NS.MCS.NET must be one huge piece of iron...

Hmmm... under your scheme, every name server would have authoritative information for the root zone. So, really, the other eDNS root servers are pointless, since they will never be contacted. That leaves ROOT-NS.MCS.NET as a *single point of failure*. Plus, think of the hassles when it's decided that the IP address of ROOT-NS.MCS.NET needs to change.

Well, the LONG TERM solution is to secondary and list the "known to be good" roots. You CAN run the cache file if you want -- but then you get the same problem that everyone else has -- that the IANA needs to change the roots too, and guess what -- there's a boatload of cache files out there. Actually, root-ns is a beefy piece of hardware, and it runs NOTHING other than this. I'm not worried about the load. The SOA times need to come down, but frankly, 5 queries/second is diddly-squat on a production machine, and lost in the noise. The point here is that if you can't reach one of the roots for a period of time, its no disaster -- you know where the data is, so you just go there directly. Yes, there are scaling problems. Yes, there are with the IANA system. When we have enough RFC-2010 roots in place then of course this changes. But for right now it gives better stability AND better performance than the IANA system -- which is, I believe, the point. -- -- 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, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal

-----BEGIN PGP SIGNED MESSAGE----- On Tue, 18 Feb 1997 15:22:27 -0600 (CST), karl@mcs.net writes:

Well, the LONG TERM solution is to secondary and list the "known to be good" roots.

You CAN run the cache file if you want -- but then you get the same problem that everyone else has -- that the IANA needs to change the roots too, and guess what -- there's a boatload of cache files out there.

The cache file is only a hint - when a name server starts up it uses the information in the cache file to contact one of the root name servers and gets the latest list of root name servers from there. Actually, you probably only need to know about one other name server that has a list of root name servers. However, if you ever have to renumber ROOT-NS.MCS.NET, you're in trouble because there's no way for most name servers to update their configuation files automatically to take notice of the new location of the primary server.

Actually, root-ns is a beefy piece of hardware, and it runs NOTHING other than this. I'm not worried about the load. The SOA times need to come down, but frankly, 5 queries/second is diddly-squat on a production machine, and lost in the noise.

The point here is that if you can't reach one of the roots for a period of time, its no disaster -- you know where the data is, so you just go there directly.

Yes, there are scaling problems. Yes, there are with the IANA system. When we have enough RFC-2010 roots in place then of course this changes. But for right now it gives better stability AND better performance than the IANA system -- which is, I believe, the point.

I don't care how beefy ROOT-NS.MCS.NET is, it's not going to handle the load of all the zone transfers when you update the root zone's serial number. You can make attempts to balance the zone transfer load among name servers but that's a manual process and you're bound to overload one of your root servers. The current system automatically balances the load across all of the root name servers. [A copy of the headers and the PGP signature follow.]  Date: Wed, 19 Feb 1997 00:27:21 -0600 From: "Jeffrey C. Ollie" <jeff@ollie.clive.ia.us> In-reply-to: Your message of "Tue, 18 Feb 1997 15:22:27 CST." <199702182122.PAA23440@Jupiter.Mcs.Net> Subject: Re: [NANOG] Just got on this thing (perhaps very belatedly) - root server trouble? To: nanog@merit.edu -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: AnySign 1.4 - A Python tool for PGP signing e-mail and news. iQCVAwUBMwqdTZwkOQz8sbZFAQGEvwP/Qp69lT1YoJB0AePADmapx1ckXIKrQhh5 0U0KCWhQQpl1JrISWVOeOisSogl8eVqn4fdXv6duh0TWpQlNOhQybkYpAfkZlw8L Htng+qHwRxwCzLZzV3HZp+JzwnZuLKwk7X8jbk5Xg7D0FSkLagFv5nO3k9rjnSGB 1uB3t6sy9Kg= =r9y9 -----END PGP SIGNATURE----- -- Jeffrey C. Ollie | Should Work Now (TM) Python Hacker, Mac Lover |

What is your point? IMHO it's far better for NSI to accept the applications without working SOA. Otherwise you lock people into paying ISPs to hold domains for them. While that might give you business, it's not something that NSI should enforce, or should have to enforce. Furthermore, the NSI registration system has become FAR more reliable since the removal of that check. In order to ensure that SOAs are always available they would have to continually check all the zones. I personally do not trust anyone, not you, not NSI, not even myself to do that without dropping zones accidentally now and then. Why introduce those problems into the system when it works just fine without them? Furthermore, when I ran a similar survey four months ago things didn't seem nearly this bad. Although I was only taking the com.zone NS records and querying them for "nic." NS records. I was happy to see that less than 1% of them were corrupted by a bogus "nic." tld. Dean On Tue, 18 Feb 1997, Karl Denninger wrote:

...

There are approximately 50,000 name servers that are authoritative for .com (according to the .com zone file from the InterNIC).

No. There are approximately 50,000 unique nameserver hostnames. At least 1/3rd of these, according to the survey I'm running right now, are completely bogus and simply don't exist.

The survey that I'm running to study penetration of the eDNS roots gives a best guess of the ACTUAL .COM domains which are resolvable to be somewhere between 30% and 60% of the zones listed.

We're about 10% of the way through the list right now (started early this morning) so what I have at this point has statistical significance.

You hear that right folks. About 30% of the nameservers which supposedly are authoritative for .COM domains are either: 1) Non-existant (they don't resolve to an IP address) 2) Unreachable or 3) Don't know what "." is (!)

Now, if it turns out that the number of so-called delegations which aren't really backed by authority records is also 30% of the listing, then that means that of the 790,000+ domains in the COM zone, only about 265,000 are "real", in that they have both a nameserver online AND a proper authority record on that nameserver.

This is a direct result of NSI accepting applications for domains, and listing them, without checking for authoritative SOA records before issuing the records in the COM zone!

I'm apalled at these numbers. In general, DNS is so broken and polluted right now that anyone who wants to take cheap shots at the eDNS system had better clean up their own yard first.

The huge majority of eDNS registrars verify SOA and authority records before allowing the zone to issue. I know that we do here, and I was shocked at the number of bogus registrations that I had seen over the last few months.

Now that I've actually studied the existing .COM zone, I'm no longer astonished. What blows me away is the apparent fact that this large of a percentage of the data out there is absolute trash, and nobody has cleaned up the yard.

BTW, "entropy" doesn't explain this. 7 out of 8 registrations in COM are less than 18 months old according to NSI.

-- -- 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, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal

If the NIC would introduce the concept of "holding" a domain, where that would be a state of the domain being paid for (and thus not available) but not "activated" yet, thus not in DNS, then you could go to positive SOA verification, thus getting rid of the junk. This recognizes that there are people/firms who want to "buy" the domain name, but do not want to be beholden to an ISP to "hold" it, and it also recognizes that allowing just anyone to process a request throught the NIC without a valid SOA in place is a BAD IDEA for many different reasons... Doug On Tue, 18 Feb 1997, Dean Gaudet wrote:

What is your point? IMHO it's far better for NSI to accept the applications without working SOA. Otherwise you lock people into paying ISPs to hold domains for them. While that might give you business, it's not something that NSI should enforce, or should have to enforce.

Furthermore, the NSI registration system has become FAR more reliable since the removal of that check. In order to ensure that SOAs are always available they would have to continually check all the zones. I personally do not trust anyone, not you, not NSI, not even myself to do that without dropping zones accidentally now and then. Why introduce those problems into the system when it works just fine without them?

Furthermore, when I ran a similar survey four months ago things didn't seem nearly this bad. Although I was only taking the com.zone NS records and querying them for "nic." NS records. I was happy to see that less than 1% of them were corrupted by a bogus "nic." tld.

Dean

On Tue, 18 Feb 1997, Karl Denninger wrote:

...

...

There are approximately 50,000 name servers that are authoritative for .com (according to the .com zone file from the InterNIC).

No. There are approximately 50,000 unique nameserver hostnames. At least 1/3rd of these, according to the survey I'm running right now, are completely bogus and simply don't exist.

The survey that I'm running to study penetration of the eDNS roots gives a best guess of the ACTUAL .COM domains which are resolvable to be somewhere between 30% and 60% of the zones listed.

We're about 10% of the way through the list right now (started early this morning) so what I have at this point has statistical significance.

You hear that right folks. About 30% of the nameservers which supposedly are authoritative for .COM domains are either: 1) Non-existant (they don't resolve to an IP address) 2) Unreachable or 3) Don't know what "." is (!)

Now, if it turns out that the number of so-called delegations which aren't really backed by authority records is also 30% of the listing, then that means that of the 790,000+ domains in the COM zone, only about 265,000 are "real", in that they have both a nameserver online AND a proper authority record on that nameserver.

This is a direct result of NSI accepting applications for domains, and listing them, without checking for authoritative SOA records before issuing the records in the COM zone!

I'm apalled at these numbers. In general, DNS is so broken and polluted right now that anyone who wants to take cheap shots at the eDNS system had better clean up their own yard first.

The huge majority of eDNS registrars verify SOA and authority records before allowing the zone to issue. I know that we do here, and I was shocked at the number of bogus registrations that I had seen over the last few months.

Now that I've actually studied the existing .COM zone, I'm no longer astonished. What blows me away is the apparent fact that this large of a percentage of the data out there is absolute trash, and nobody has cleaned up the yard.

BTW, "entropy" doesn't explain this. 7 out of 8 registrations in COM are less than 18 months old according to NSI.

-- -- 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, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal