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