Controversial SOA values ?
Michael Milligan
milli at acmebw.com
Fri Dec 24 08:50:28 UTC 1999
> > Michael Milligan - Acme Byte & Wire LLC - milli at acmebw.com
>
> > It depends on how long you think is too long to be giving out
> > stale data. I personally consider non-contact with your master
> > zone server past a week as too long.
>
> Thanks Mike. Here is what I'm concerned about, if mother nature
> or some other emergency results in the primary going out of
> service, wouldn't it still be better to have stale data and the slaves
> operating than have the whole zone colapse ? Arguably, one of
> the slaves could be converted to a master--bla, bla, but "what if"
> that can't be done? Isn't it still better to let the system stay
> operating ?
After a week? If you can't get your master back online within a week,
something is horribly wrong with your service planning...
FYI, the slaves will continue handling the load and answering queries -- up
*until* the expire timer pops -- while your primary is down. They will be
complaining loudly in syslog that they can't reach the master, but they'll
still provide answers to all comers.
>
> > > Likewise, with "notify" updates, why not have a refresh of 1D ?
> >
> > Because NOTIFYs can get dropped, they are just UDP packets. If
> > your zone changes more often than once a day, the refresh needs to
> > be shorter than 1D.
>
> I would be grateful if you could elaborate on "notifys can get dropped,
they are just UDP packets." I see no such explanation in the DNS & BIND
book.
>
Uh, that's basic TCP/IP stuff. UDP is just a fancy IP packet, and packets
can get dropped. UDP is best effort, it's not guaranteed to get there.
That's why you still need polling to check for freshness.
Regards,
Mike
--
Michael Milligan - Acme Byte & Wire LLC - milli at acmebw.com
More information about the bind-users
mailing list