Re: [ga] Redelegation issues

["Olivier MJ Crepin-Leblond" <ocl@gih.com>]

>From: "Marc Schneiders" <marc@fuchsia.bijt.net>
>Sent: Wednesday, June 05, 2002 6:47 PM
>Subject: Re: [ga] Redelegation issues

[...]

> 
> What is the average time ICANN needs to change ccTLD nameservers in the
> root zone? Not hours, not days, not weeks...
> 

If ICANN decides to change ccTLD nameservers in the root zone,
they can do this instantaneously, and the root zone will get updated
within 24 hours. However, the DNS is such that in order to reduce
DNS-related traffic, nameservers cache information that they hold.
It takes a certain amount of time for the information to therefore get
propagated across the network, and it is this time of propagation
which makes the network unstable since some nameservers will
still think that the old root for ZA is in use.

For ZA, the information is currently:

>Authoritative answers can be found from:
>za
>        origin = apies.frd.ac.za
>        mail addr = mlawrie.apies.nrf.ac.za
>        serial = 200206030   ( <- this is a serial number)
>        refresh = 21600 (6H) 
>        retry   = 3600 (1H)
>        expire  = 2592000 (4w2d)
>        minimum ttl = 86400 (1D)  

refresh = number of seconds between a check on the serial number on
the zone of the primary and the next attempt. here: 6 hours
retry = if a refresh attempt fails, it will retry after this amount of time
and here it is 1 hour
expire = if refresh and retry attempts fail what is the length of time
after which the server will stop serving the zone and here, surprise,
it has been set at 4 weeks and 2 days !!!
ttl = time to live. The time for a cached DNS record to stay cached
until it is purged. here it is 1 day

So as you can see, if a local nameserver has cached information
pertaining to the root ZA zone, there is a period of time it will still
interrogate the old nameservers (including secondary nameservers
for the zone) even though ICANN has re-delegated the zone to another 
root. 
This introduces instability because the reply that will be given when 
interrogating the nameservers may be non-authoritative (cached, and 
providing a pointer to an old nameserver) or authoritative (providing 
a pointer to a new nameserver). That's not good.

Of course, you may say "oh, but I thought that the DNS was designed
to withstand a thermo-nuclear war, so why is it so fragile when changing
root zone delegation?" Well, the DNS was never designed with the
idea of changing root servers in mind. As you can see from above, it is
designed to keep name <-> IP Number translation stable even though
the authoritative root nameserver could be off-line for an extended time.
It plays for stability when parameters do not change, but instability
when they do change, especially when it is a drastic step of changing
root altogether.

I hope this helps.

Cheers,

--
Olivier MJ Crepin-Leblond, Ph.D. |--> Global Information Highway Limited
E-mail:<ocl@gih.com> | Tel:+44 (0)7956 84 1113 | Fax:+44 (0)20 7937 7666
Web: http://www.gih.com/ & http://www.nsrc.org/codes/country-codes.html

--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html