At 14:28 +1000 8/21/08, Mark Andrews wrote:
> * Outlaw loops.
> * Don't reset the expire counter on refresh from peers only
> on transfer from peers.

I'd reset the expiry only after the successful transfer of an zone
with an incremented serial number. That would take care of loops.

> * Use DNSSEC to make data go stale.

Don't do that. Don't overload the meaning of the RRSIG temporal
fields. They are meant to protect the cryptography, not convey any
meaning of the data.

At 1:00 -0400 8/21/08, Brian Dickson wrote:
>If a zone is transfered *from* a slave, the values for the TTLs should
>be modified downwards by the local EXPIRE timer. Only transfers from a
>zone master should have the original TTL values from the SOA used for timers.

The problem is distinguishing between a master and a slave.

At 14:52 +0900 8/21/08, Masataka Ohta wrote:
>A hidden assumption of 1034 is that such convergence will occur
>within a period much shorter than the expiration period.

Many assumptions of that era no longer are valid.

>If not, you have an administrative problem a lot more serious
>than a small variation of expiraiton period.

Not necessarily. There are applications of DNS on disjointed
networks such as very remote places (which hardly exist anymore),
sea-going vessels, inter-planetary applications.
Edward Lewis +1-571-434-5468

Never confuse activity with progress. Activity pays more.

to unsubscribe send a message to with
the word 'unsubscribe' in a single line as the message text body.