Just got on this thing (perhaps very belatedly) - root server trouble?

Wed Feb 19 00:42:38 UTC 1997

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

<sthaug at nethelp.no> on 02/18/97 23:09 said:
>
> Karl Denninger  <karl at 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 at 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 at fox-den.com