Subject: RE: Anycast root metrics and analysis

From: "Larson, Matt" <[email-masked]>
Date: Mon, 6 Nov 2000 16:39:40 -0500

> What's more the comparative stability of the root zone actually makes that
harder (it is 
> easy to set up and test update procedures for a database that changes
every day, much
> harder for one that only changes once a year or so).

FWIW, the root zone is generated twice daily, along with the com, net, org,
arpa and edu zones, all from the same back-end database.  In the case of the
root zone, the only thing that usually changes is the SOA serial number,
which is date-based.

Matt
--
Matt Larson <[email-masked]>
VeriSign Global Registry Services / www.verisign-grs.com

---

From: Jerry Scharf <[email-masked]>
Date: Mon, 06 Nov 2000 14:41:43 -0800

Remember that some day (hopefully sooner rather than later) this zone is going 
to be signed, most likely with a working key signed against a static metakey. 
Every time the working key changes, every SIG in the zone changes, so there 
will be much more to the root zone in the future. I don't think anyone has an 
answer on how long the working keys last, but it might be something like 
monthly.

I don't think this changes the anycast stuff in any way, but it does change 
the significance of coherence of the slaves (expired SIGs on an authoratative 
root server would be 'a bad thing.') Perhaps there should be something that 
takes a server offline if a zone transfer hasn't happened and the SIGs are 
close to expiry time. This is just as true for old style servers.

I had been thinking about a requirement for external monitoring of any server 
that wants to join the root set. It would be an interesting project and I 
would be willing to contribute time to making that happen. A web site that 
everyone knows where to go to look at the root server set structure could go a 
good way towards mitigating the confusion factor of anycast.

jerry