Mailing List Archive

On Tuesday, February 18, 1997 12:05 PM, Brett L. Hawn[SMTP:blh@nol.net] wrote:
@ On Tue, 18 Feb 1997, Matt Ranney wrote:
<snip>
@
@ Or better yet, to teach the idiots at NSI how to maintain a database.
@
@
@ [-] Brett L. Hawn (blh @ nol dot net) [-]
@ [-] Networks On-Line - Houston, Texas [-]
@ [-] 713-467-7100 [-]
@
@
@

Wait a minute....please completely read the following
before you start calling people idiots....

@@@@ http://rs.internic.net/nic-support/nicnews/feb97/registry.html

"What It Means To Be a Registry"
...

@@@@@@@@@@@@

--
Jim Fleming
Unir Corporation

e-mail:
JimFleming@unety.net
JimFleming@unety.s0.g0 (EDNS/IPv8)

- - - - - - - - - - - - - - - - -

[.data about ~30% of .com zones not backed by SOA records removed]

<sthaug@nethelp.no> on 02/18/97 23:09 said:
>
> Karl Denninger <karl@Mcs.Net> on 02/18/97 18:59 said:
> >
> > 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.
>
> For once we agree. NSI should have stopped this practice long ago. You'll
> be pleased to hear that there are other name registries (for instance the
> one serving the "no" (Norway) TLD that actually perform this check.
>
> Note that checking when an application is received isn't really enough.
> In Norway we run regular (monthly) checks of all the second-level domains
> under "no", and we always find a number of name servers which have ceased
> being authoritative in the time since last check.
>
> Steinar Haug, Nethelp consulting, sthaug@nethelp.no

I couldn't agree more. There are any number of both political and
technical reasons that the SOA should be checked on zones before they appear
in any root nameservers, and it doesn't seem that large a task to prevent
bogus zones from making it into the root nameservers.

Why non-SOA zones shouldn't make it into the root nameservers:
- lame zones are inherently broken; why allow brokeness to exist?
- if it's not in the nameserver, the "owner" of the nameserver hasn't
given explicit permission for it to be there (see below under
"lawsuits")
- filling the root nameservers with bad NS pointers only wastes
time with timeout queries that stick around too long (not a
big deal with people who have no data at all in either server,
but what about zones that one of the nameservers is lame? That
would cause the 5-10 second lag time for a "valid" zone when
the "invalid" nameserver was asked abouft it.)
- people who point secondary at non-SOA nameservers without telling
the secondary that this is expected break not only themselves,
but bring complaints against the innocent "secondary" provider
who has complaints that "Your nameserver is broken!"

How to prevent bogus SOA's:
- before propogating the name into the roots, check for SOA
- if SOA fails, then list the name in some sort of "Reserved"
status, just like names that are pending payment, but
make it possible for a name to remain in "Reserved" status
forever (see "lawsuits-2" below)
- if initial SOA test fails, check SOA every X number of days
until valid.
- every X number of months, check to ensure SOA is still present
in listed nameservers.
- If invalid, wait another Y days, and try again. After Z
iterations of failures, pull the NS pointers and list the
zone as "Reserved" for XX number of days or until someone calls
in and whines, at which point check SOA by hand.


Diatribe:

There have been occasions where persons have sent in top-level domain
registrations with nameservers listed as secondary that had _nothing_ to do
with the primary, and had never even heard of the primary. If foo.com
wanted to point their secondary at any particular nameserver (or even a
random IP address!) there is nothing that anyone can do to prevent them.
Suddenly, an innocent bystanding nameserver admin starts getting flames from
SPAM victims and other sundry folk simply because their name happens to be
in the NS list for that zone.

I also hate trying to dig around (no pun intended) to find if there is any
information at all that is valid for a zone, if the old ISP is still in
business, if that network just isn't visible from where I am, etc. I am
involved with a lot of transfers, and I'd rather know that the old
nameservers are just non-existant rather than trying to sleuth things down.

Lawsuits:

Imagine that the domain "humongouscompany.com" is registered with
ns.bigprovider.com and ns2.bigprovider.com. Recently angered by the current
sale of routers in China by Humongouscompany, and _equally_ angered at the
recent banning of his IP address from smallprovider.com's IRC server, a
clever hacker spoofs an email message from the admin contact at
humongouscompany.com and requests that the nameservice be moved from
[ns,ns2].bigprovider.com and pointed at [ns,ns2].smallprovider.com. The
next root nameserver reboot, humongouscompany.com is out of luck, as there
are no records in place for that zone in [ns,ns2].smallprovider.com's
nameservers. Smallprovider is completely innocent here, but guess who gets
slammed in that morning's TechWizDaily?

Lawsuits-2:

Well, a good argument has been made that "if an SOA is required, then
there is criteria for getting added to the root nameserver, and the NIC has
to be impartial and take all comers who have the $100 to register." OK, no
problem. Just register the name, make it impossible for anyone else to take
that particular combination of letters/numbers, but don't point the zone
anywhere.

Summary:

These ideas have been floated past some of the registration managment at
the InterNIC, and hopefully they'll take this into consideration. This
would prevent the 30% attrition that Karl reports that he's discovered. Any
comments? Does anyone else feel that the NIC should go back to checking
SOA's with the addition of an additional "no-SOA" or "Reserved" status?

JT

---
John Todd
jtodd@fox-den.com

- - - - - - - - - - - - - - - - -

On Tue, 18 Feb 1997, Brett L. Hawn wrote:

[...]
> joe@my.*&^ed.domain.com, they try and email him.. you get the picture. Day
> after day we see dozens of lame delegation errors. Very often for the same
> domains time and time again. I don't usually agree with Karl but in this
> case he's right.

So the rate at which these servers serve queries is measured in
queries/second, and we are worried about dozens of failed queries per
day?

Don't get me wrong, if NSI isn't getting paid to keep all those
domains in the database, then they shouldn't be there, but it doesn't
seem like as big a problem as Karl is making it out to be.
--
Matt Ranney - mjr@ranney.com

This is how I sign all my messages.

- - - - - - - - - - - - - - - - -

In <v02140b1daf2ff1f4b577@[207.135.64.133]>,
Chris Russo <crusso@alink.net> wrote:

> As was mentioned before, you shouldn't have to pay an ISP to have a domain
> name reserved.

Yes, you should. Currently, to register a domain, both with the InterNIC
and the AlterNUTS, you need to specify at least two nameservers to
serve DNS data for your domain. If you list an ISP's nameservers on
your domain registration, you sure as hell should pay that ISP.

You can take this issue the other way, and say that the InterNIC shouldn't
require two nameservers on the initial registration, but I think that's
a bad idea. The two-nameserver requirement raises at least a minimum
bar that rampant domain-grabbers have to jump.

This has nothing at all to do with NANOG. I've set Reply-To: to
rs-talk@internic.net, the InterNIC's list for discussing registry
issues.

--
Michael Handler <handler@sub-rosa.com> Washington, D.C.
know your faults / know your friends / be prepared / to take revenge -- MoLG
- - - - - - - - - - - - - - - - -

On Tue, 18 Feb 1997, Karl Denninger wrote:

> Folks, we run the network (this *IS* NANOG, right? :-) Let's start actually
> running it for a change... DNS is one of those things that we ought to be
> able to do right, and do in an open and competitive format.

Seems to me that we on NANOG are concerned with mostly issues that fall at
layers 2-4. You are talking about things like competition that really are
only marginally related to most people on NANOG.

Michael Dillon - Internet & ISP Consulting
Memra Software Inc. - Fax: +1-250-546-3049
http://www.memra.com - E-mail: michael@memra.com

- - - - - - - - - - - - - - - - -

> As was mentioned before, you shouldn't have to pay an ISP to have a domain
> name reserved.

I don't see why "having a domain name reserved" need be the same thing
as "having NS records in the root nameservers". Why not just allow
registrations that reserve a domain administratively and simply have
it not exist in the DNS?
--
Shields, CrossLink.
- - - - - - - - - - - - - - - - -

On Tuesday, February 18, 1997 11:18 AM, Michael Dillon[SMTP:michael@memra.com] wrote:
@ On Tue, 18 Feb 1997, Karl Denninger wrote:
@
@ > Folks, we run the network (this *IS* NANOG, right? :-) Let's start actually
@ > running it for a change... DNS is one of those things that we ought to be
@ > able to do right, and do in an open and competitive format.
@
@ Seems to me that we on NANOG are concerned with mostly issues that fall at
@ layers 2-4. You are talking about things like competition that really are
@ only marginally related to most people on NANOG.
@
@ Michael Dillon - Internet & ISP Consulting
@ Memra Software Inc. - Fax: +1-250-546-3049
@ http://www.memra.com - E-mail: michael@memra.com
@
@
@

I can not wait until the day comes when we
see our friend from Canada, Mr. Michael Dillon,
trying to invade the floor of the United States
Senate or the House of Representatives to
tell those folks what they are allowed to discuss.

Something tells me that they will not really
care that you are on the Board of Directors
of the ISP/C Mr. Dillon. Of course, you are
welcome to prove me wrong.

--
Jim Fleming
Unir Corporation

e-mail:
JimFleming@unety.net
JimFleming@unety.s0.g0 (EDNS/IPv8)

- - - - - - - - - - - - - - - - -

At 4:44 PM -0800 2/18/97, Matt Ranney wrote:
>Don't get me wrong, if NSI isn't getting paid to keep all those
>domains in the database, then they shouldn't be there, but it doesn't
>seem like as big a problem as Karl is making it out to be.

NSI's bookkeeping is so confused, they're really not sure who has paid and
who hasn't. From what I can tell, they are only deleting domains that
haven't paid in about 6 months AND do not have authoratative nameservice
working. And it appears of that domain has a registered nameserver in its
namespace, then even if the nameserver isn't responding it does not get
removed.

My theory is their database is so screwed up and in such a fragile state,
they're scared to make any big changes to it. Removing a domain with a
registered nameserver in it seems like it is a "big change".

Add the the fact that they are showing non-payment for many domains that
have actually made payment, they don't want to shut off the domain while
trying to sort out the paperwork.




- - - - - - - - - - - - - - - - -

At 4:08 PM -0800 2/18/97, Chris Russo wrote:
>As was mentioned before, you shouldn't have to pay an ISP to have a domain
>name reserved.

And you shouldn't have to pay for phone service to have a phone number
reserved.

HUH?

Then maybe NSI should have a policy for reserving domains without making
them "live", much like they do with the on-hold domains.

But for the time being, since you must have 2 nameservers listed to apply
for a domain, you're going to need someone to provide that nameservice for
you. Just like if you're going to reserve an 800 or 888 number, you need a
long distance company to service it, even if it is routing that number to a
disconnect recording.


- - - - - - - - - - - - - - - - -

On Tue, 18 Feb 1997, Jim Fleming wrote:

> @ Or better yet, to teach the idiots at NSI how to maintain a database.

> Wait a minute....please completely read the following
> before you start calling people idiots....
>
> @@@@ http://rs.internic.net/nic-support/nicnews/feb97/registry.html
>
> "What It Means To Be a Registry"

If you're going to do, do it right or don't do it at all, its that simple.
I'm sick of watching NSI screw up their database on a weekly basis.

[-] Brett L. Hawn (blh @ nol dot net) [-]
[-] Networks On-Line - Houston, Texas [-]
[-] 713-467-7100 [-]

- - - - - - - - - - - - - - - - -

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
> >
>
>

- - - - - - - - - - - - - - - - -

It appears that I'm about to add Karl to my mailproc rules since he really
does belong next to Jim Fleming. But before I do that...

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

In what order? With 1,000,000 name servers (remember, you're talking
LONG TERM here) this is a hell of a lot of SOA queries against the first
server in the list.

> 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.

Or you could use existing technology (invented by Mark Andrews in this case)
and solve the REAL problem without also dealing with Karl's odd politics:

zone "." {
type stub;
file "root.cache.stub";
masters {
192.36.148.17; 192.203.230.10; 128.8.10.90;
192.33.4.12; 128.9.0.107; 128.63.2.53;
198.41.0.4; 198.41.0.11; 198.41.0.10;
192.112.36.4; 192.5.5.241;
};
check-names warn;
allow-update { none; };
allow-transfer { any; };
allow-query { any; };
};

That's on BIND 8.1. If you're running BIND 4.9.5 it's a lot simpler. What
this does is do a ". NS" query (with UDP) and store the results. If there
is no answer, the "masters" list becomes like a "forwarders" for the zone,
which in this case makes it just like an explicated hint zone.

> Actually, root-ns is a beefy piece of hardware, and it runs NOTHING other
> than this. I'm not worried about the load.

You should be worried about what you'll do when its address changes. That
is, you would have to worry if this name server was ever going to matter in
the larger scheme of things, which it is not.

- - - - - - - - - - - - - - - - -

-----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 do you think happens to the nameservers on the net when they're asked
> for a domain that doesn't have functional servers, and they sit and churn
> trying to resolve the names?

They use 30 bytes of memory per such query, during the time it takes to
get back an NXDOMAIN, which is then cached for at least five minutes.

Perhaps you had a point to make?
- - - - - - - - - - - - - - - - -

> Thats fair, I guess. Perhaps some of those $100 in fees for unused
> domains could be used to buy more RAM for root server operators.

This has in fact been done. NSI sent me a replacement for F.ROOT-SERVERS.NET:

MESSAGE Alpha boot: available memory from
_0xe46000 to 0x1fffe000
Digital UNIX V4.0B (Rev. 564); Mon
_Dec 23 14:52:07 PST 1996
physical memory = 512.00 megabytes.
available memory = 497.74 megabytes.
using 1958 buffers containing 15.29
_megabytes of memory
AlphaStation 255/300 system
DECchip 21071
- - - - - - - - - - - - - - - - -

On Tue, 18 Feb 1997, Paul A Vixie wrote:

> > Thats fair, I guess. Perhaps some of those $100 in fees for unused
> > domains could be used to buy more RAM for root server operators.
>
> This has in fact been done. NSI sent me a replacement for F.ROOT-SERVERS.NET:
>
> MESSAGE Alpha boot: available memory from
> _0xe46000 to 0x1fffe000
> Digital UNIX V4.0B (Rev. 564); Mon
> _Dec 23 14:52:07 PST 1996
> physical memory = 512.00 megabytes.
> available memory = 497.74 megabytes.
> using 1958 buffers containing 15.29
> _megabytes of memory
> AlphaStation 255/300 system
> DECchip 21071

Hey, that's great.

So are you seeing performance problems from all the bloat that they
are allowing to creep into the tables?
--
Matt Ranney - mjr@ranney.com

This is how I sign all my messages.

- - - - - - - - - - - - - - - - -

On Tue, 18 Feb 1997, Jim Fleming wrote:

> Wait a minute....please completely read the following
> before you start calling people idiots....
>
> @@@@ http://rs.internic.net/nic-support/nicnews/feb97/registry.html
>
> "What It Means To Be a Registry"

Wah, wah, wah. How hard they've worked to overcome challenges and how
they've accepted the responsibility for... Bleah. This sounds like a
prospectus or something. How can they make maintaining a database this
difficult? It's like InterNIC is *trying* to mess things up.

shag

Judd Bourgeois PGP key ID 0xEDC21CA1
shagboy@world.std.com 25DDE4AF C5AFEF51 6905DC77 360F0387
To all my friends - It's not the end
The earth has not swallowed me yet - 311, "Freak Out"

- - - - - - - - - - - - - - - - -