Re: DNS primer

[Roland Perry <[EMAIL PROTECTED]>]

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

You are right about the several (2+) copies and the different network, 
and the resilience issue (particularly form the users point of view - 
querying whichever seems to be most "alive"). I'm struggling to 
reconcile your description of a secondary that both isn't updated unless 
there's a need, and which also automatically gets its data from the 
master. The maintainer has to make decisions about when the data is 
updated, and where from - and as I described before it's traditionally a 
snapshot process, not a dynamic database.

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

Bending the rules like that (or not) is not relevant to the mechanisms 
for updating the zones.

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

Glad we agree.

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

So you think the DNS would be a suitable prototype for a distributed NHS 
database [remember, that's the proposition we are discussing] if it was 
set to a cache time of (say) 10 minutes [the time it takes you to walk 
from the prescribing GP to the pharmacist].

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

Glad we agree.

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

Not my DNS server, but those of (eg) cctlds.

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

Read about the post 9/11 situation, then. As a major source of 
protracted-loss-of-connectivity it rattled quite a few cages.

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

I'm not sure how useful that is, given that everyone will know that the 
record in question is in a bunker in the East Midlands (and its backup).

Or were you thinking that every doctor or hospital department I'd ever 
visited would hang onto its fragment of my medical record on a local 
server, and these would somehow get patched together into a coherent and 
holistic view by some master-index?
--
Roland Perry