Re: DNS primer

[Roland Perry <[EMAIL PROTECTED]>]

In article <[EMAIL PROTECTED]>, Dave Howe <[EMAIL PROTECTED]>
writes
>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.

I'd think of it (in the context of resilience, which is where this is
all coming from) very much in the same sense as a RAID drive. Some
scheme (from a selection of schemes) whereby the data is automatically
distributed (and updated) around several nodes such that the complete
loss of any one node will be [relatively] transparent.

To that extent the RAID 1 nature of DNA almost qualifies, but updates
are not automatically propagated, so it fails.

>> But each Mirror has to be maintained (uploaded) {with a few modern
>>exceptions} explicitly by the database owners.

>  Nope, that has never been true.

<panto>
Oh yes it has.
</panto>

>  In the past, mirrors (ie, secondaries)

Let's not unnecessarily introduce the primary/secondary thing, it's not
relevant to the main point.

>and caches have expired "stale" records after a number of minutes
>specified by the writer of the record

Yes, the caches will expire records, typically after 7 days (although I
think one of the cctlds that fell over post 9/11 was working with 21
days.

All that does is make the cache reload. It doesn't ensure that all the
places the cache might be reloading from are in synch. Nor can the
record-holders go back to all the caches within the period and say
"sorry, can you reset that time to 1 hour please".

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

Yes, but that's not relevant.

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

OK so far.

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

My DNS servers do none of this. It may well be that some DNS servers are
migrating to such a system, and that's why I qualified my earlier
remarks with:

        "But each Mirror has to be maintained (uploaded) {with a few
        modern exceptions} explicitly by the database owners."

But all the rest need the data owner to run a specific job (usually at a
set time each day) to reload a completely new copy of the data. [And
whether that's from HQ to Primary and in parallel HQ to Secondary, or HQ
to Primary and later Primary to Secondary, is a minor implementation
detail].

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

At 21 days I think it might be a tie; but it's not about propagating
single copies, is it? It's about being in the casualty department and
them being able to access the constantly updated central record which
will reveal what exactly pills it was that the GP prescribed 4 hours ago
that you are now suffering the serious allergic reaction to.

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

Sounds to me just what the NHS central health records needs.

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

I'm not "down" on them. They do work very well - for what they were
designed to do. My complaint is that it's simply an entirely
inappropriate model to use for an NHS database. And just because the DNS
works well doesn't mean that every distributed database implemented on
the Internet will inherit some fairy dust and work just as well itself.

-- 
Roland Perry