Re: Zone Immortality
At 14:28 +1000 8/21/08, Mark Andrews wrote:[color=blue]
> * Outlaw loops.
> * Don't reset the expire counter on refresh from peers only
> on transfer from peers.[/color]
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.[/color]
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:[color=blue]
>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.[/color]
The problem is distinguishing between a master and a slave.
At 14:52 +0900 8/21/08, Masataka Ohta wrote:[color=blue]
>A hidden assumption of 1034 is that such convergence will occur
>within a period much shorter than the expiration period.[/color]
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.[/color]
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 [email]firstname.lastname@example.org[/email] with
the word 'unsubscribe' in a single line as the message text body.