Ignoring Expires

[Barry Margolin]

In article <200004170829.KAA07350 at mail.emit.pl>,
Ian Carr-de Avelon  <avelon at emit.pl> wrote:
>Can I (easily) get bind to ignore short expiry times? I am seeing 
>progressively more zones moving to headers like: 
>>                                        30M             ; refresh
>>                                        30M             ; retry
>>                                        30M             ; expiry
>>                                        10M )           ; minimum
>Including zones which don't changes through months. 

Some DNS administrators don't know what these fields really mean.  They
think they need to reduce all of them so that changes will propagate
quickly.  And of course they ignore BIND's log messages warning when expire
is too close to refresh.

>During periods of congestion this causes unnecessary degradation of service
>to our end users.
>Browsers waste time while bind performs a lookup, and if that fails are 
>in some cases unwilling to pass the request to a proxy server, which may
>well have the page available. Email clients are kept waiting while 
>the domain is verified and then often time out. Our only other option 
>is to accept all mail, with the result that any typing mistake in the
>address is only caught when the email is returned.
>Can I set an option to make all expires a minimum of a couple of days?
>If not, can someone please put that on a wish list? It would also be
>nice if failed retries could be rerun via a cron job outside peak
>periods to keep things connected.

I wouldn't mind something like this as well.  Apparently Microsoft's DNS
Manager defaults to 1 day as the Expire time for new zones, whereas most
people in the know recommend at least a week.

I periodically run a little script that scans all our slave zone files
looking for expires of a day or less, and then I notify the customers
responsible for those domains.  It sure would be nice if we could get out
of this tedious duty.  On the other hand, it gives us an opportunity to
educate our customers, and they appreciate this.

-- 
Barry Margolin, barmar at genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.