Ted Lindgreen wrote: > OK, let's just write it out: > With expire = Y: > Suppose the last successful AXFR was on day 4. Then on day 7 the > SIGs expire. From day 8 until day 12 the zone remains valid.
suppose last successful SOA check was on day 1. SIGs expire on day 7, zone expires on day 8. That gives you 6 days to detect and fix the problem. > With expire = Y-X: > Last successful AXFR was on day 4. > On day 7 both SIGs expire and zone has turned invalid. That has zone already expired on day six. With the new values, the zone expires on day three (1 + (7 - 5)). So, you pay a rather high price to avoid handing out stale data (expired signatures) from a server which may have a *temporary* problem. What is worse (and for whom): expired SIGnatures (on old data) or an expired zone? Since one of the primary reasons for zone expiration I've seen is that someone introduced a syntax error at the primary master causing that server to go non-authoritative (a BINDism, I must admit), I'd rather have a longer window for problem detection at the risk of handing out expired SIGs at a later point in time. Losing all secondaries at once is tough. At least, something needs to be said about the relation of X and Y. -Peter #---------------------------------------------------------------------- # To unsubscribe, send a message to <[EMAIL PROTECTED]>.
