Re: DNS primer

[Dave Howe <[EMAIL PROTECTED]>]

Roland Perry wrote:
> The *DNS* is not a distributed database in what I'd claim to be the 
> normal sense. It's a set of Mirrors of a number of stand-alone 
> databases. OK, there exists software which will query the relevant 
> individual stand-alone database, and that software is capable of 
> accessing a Mirror if necessary; which kind of gives that impression.
how else would you describe a distributed database? there are plenty of 
implimentations which keep a full copy of each on every node - but just 
as many that keep the master copy on a given node, and transparently 
relay queries to a remote node on demand.

> But each Mirror has to be maintained (uploaded) {with a few modern 
> exceptions} explicitly by the database owners. 
  Nope, that has never been true.
  In the past, mirrors (ie, secondaries) and caches have expired 
"stale" records after a number of minutes specified by the writer of the 
record - for the benefit of caches, you can even specify 0 if you wish, 
so that those records are queried each and every time (some ISPs 
override this however for performance reasons).
  This is however obviously a pull architecture - cache servers go to 
the primary or secondary (or secondaries) and pull data they are 
interested in selectively, if they have not already got that record in 
store and it has not gone stale.  The new structure (for secondaries, 
which by necessity pull the entire zone, not just a single record) is of 
a notification tree - whenever the master (primary) is updated, it 
broadcasts an "update available" packet to all the secondaries it knows 
of. each then contacts its master and downloads a fresh copy - and then 
broadcasts a similar notification to all the secondaries that *it* knows 
about, so that if they are unable to obtain a copy from the master, they 
can obtain it from a secondary that *did* obtain it from the master.
  notifications contain only the unique serial number for the zone file 
update - so notifications of an update for which the secondary has a 
current file already are ignored, regardless of source.

> There's no automatic
> propagation of changes between the different mirrors, nor is there a 
> scheme to force the early flushing of cached information where that 
> exists in the channel between the database and the end user.
Indeed, cache flushing is a major problem - some ISPs abuse the standard 
by hardcoding expiries to values larger than their authors intended (and 
some authors shorten expiries to stupidly small lengths in the belief 
this somehow makes their data more accessable)
DNS as an index though is pretty static - and a DNS record will *even 
worst case* be updated and propagated across the world faster than that 
packet of papers can make it from your old GP to your new one.

> So the mechanisms in place to feed and water the DNS are entirely 
> different to those that would need to be deployed to implement a truly 
> distributed database of data that might be accessed by end users via 
> http. Akamai would be a better system to look at.
  Akamai is almost entirely a load balancing system - *data* caching in 
a similar way to dns caching, but controlled from the author side rather 
than the recipient.
  I have no idea why you are so down on the internet's control and 
delivery mechanisms - they are robust, can carry stupid levels of 
workload on relatively low-spec hardware, 8 yr old kids can now produce 
good web content if they care to, and its all COS hardware/software.