North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: Just got on this thing (perhaps very belatedly) - root server trouble?
[data about ~30% of .com zones not backed by SOA records removed] <email@example.com> 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, firstname.lastname@example.org 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 email@example.com - - - - - - - - - - - - - - - - -