Re: DNS primer

[Dave Howe <[EMAIL PROTECTED]>]

(sorry about the delayed reply - been away for the weekend)

Roland Perry wrote:
> Let's not unnecessarily introduce the primary/secondary thing, it's
> not relevant to the main point.
how else would you describe a system where there are redundant second
copies (ie, full mirrors) that are under the maintainers control, and
not explicitly updated unless there is some terrible need for a fast
refresh of their data?
From the earliest days of the Bind package, it has been convention to
have no less than two authoritive copies of each zone - one master, and
at least one slave that automatically obtains its data from the master
without any human intervention - and ideally, on differnet networks so
that loss of connectivity will not remove both from service.

> > 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.
In theory, the cache expiries are specified explicitly by the owner of
the zone - in practice, ISPs often hardcode this in their proxies for
their own benefit.

> 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".
no, it doesn't, and change propagation can be a bugbear of major DNS
changes; a propagation time of two or three *days* is not uncommon,
although few ISPs push the envelope for DNS expiry beyond that. However,
the fact that *your* isp's cache of a record may be inaccurate is not
the fault of that record's owner, and in fact it is possible to bypass
your isp's cache and obtain data from primary or secondary servers directly.

> > - 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.
yes, it is. if your records change rapidly, you specify a short expiry -
one hour, say - so that no record in cache can live more than one hour
before being refreshed from the master. as this is an index rather than
a data source, such delays are acceptable - you can live with having to
not switch off a webserver for two days if that is how long you continue
to receive requests after the record goes stale, but there is always a
tradeoff between freshness of records and bandwidth usage, and the DNS
system does well.

> 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:
depends on what dns software you are using - its a feature of bind 9,
and not always turned on.

> "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].
Then whomever set up your DNS server is an idiot (and I can say this
unreservedly; automatic secondary updating by pull architecture has been
a feature of a properly configured DNS install for more years than I can
conveniently remember, certainly since the days I was still using bind v4)


> > 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.
I would be interested in what ISPs actually cache dns data for three
weeks in the face of a stale copy - I have heard of some badly
configured dns zones that *specify* a record expiry of three weeks, in 
the mistaken belief it makes their servers somehow more stable, but 
never seen it myself and considered it a urban myth...

> > > 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.
it also is a load/staleness balance, on a purely monodirectional level -
and quite possibly, loss of a prime source entirely can cause the
mirrors to drop dead in under ten minutes (because the staleness value
is set so low the records expire rapidly)
caching is caching, however you impliment it.

> 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.
it will work well as an index - ie, telling you where to find a given
patient's master record, as that data is relatively static. This is of 
course how DNS works *now*, so it is unsurprising that it could fit that 
role well. How well the http(s) model of data access and web caching 
will work as a data unavailability buffer is another matter - novell's 
NDS is an example of a distributed database with explict mirroring and a 
push architecture, perhaps better suited if you wish to consider data 
redundancy to the level of keeping data available on the network in 
spite of loss of a site or subnet; however, if the (DNS like) index 
works correctly but the data is still unreachable, you could worst case 
phone the physical repository concerned and ask them to fax you whatever 
info it was you needed.