North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Follow-up to "ROOT SERVERS"

  • From: Kai Schlichting
  • Date: Fri Aug 25 11:26:54 2000

At Friday 10:24 AM 8/25/00, "Verd, Brad" <[email protected]> wrote:

>NSI is modifying the current zone generation process to eliminate the
>existing small interval during which the com zone database file is not
>present on this nameserver. Until then, NSI is manually querying the root
>zone to ensure no delegations have been automatically dropped. 

It's unbelievable how people cling to inadequate solutions that no longer
serve their needs adequately.

Why are we still relying on the zone AXFR mechanism with plain,
unauthenticated TCP transfers going to or from IP host that could
temporarily be located in outer Mongolia (no offense) if one decides
to use BGP announcements as a temporary "relocator"? Strategically
such relocation would happen minutes before such zone transfers start.

There is a small number of zones that are too important to go missing,
corrupted or hijacked:
Why are these all-important zones not transferred via a secure (and likely
freely available) mechanism like SCP (part of ssh) using RSA authentication?

Why isn't the same done for a checksum file for each zone, which is then
compared to the transferred file, with DNS servers only reloading the
zone on a SIGHUP once the authenticity and correctness of the zone has
been confirmed? The number of parameters to verify correctness should
be in the single digits: approximate length of zone(s), serial #, presence
of zone(s), SOA info, other cursory checks. Anything missing? Pages
should be blasted out to key people within seconds, and the server
detecting the fault should hold "status quo" until it either solves
the problem itself, or receives manual help.

All of this takes at most a few hours to implement : whip up a bunch
of Perl scripts (throw in a few weeks of beta testing!), it won't work
less reliable than what we have right now, apparently : I have
done similar secure shuttling of files for applications in the
financial industry where correctness and prevention of loss in
transport was everything, but timing came right after. That software
is still in use today, with (as I believe) virtually no maintenance
or bugfixes applied in the last 2 years, and what could have been
10KB of code, became about 50 as interaction with an NT server
was required...