On 2015-08-10 13:12, Mark Andrews wrote:
Authoritative servers (listed in NS records) shouldn't be recursive.
This prevents leakage of cache data. This provide consistent
answers. The server also doesn't have to decide what type of answer
to give (recursive vs authoritative). Glue doesn't get overridden
by answers, etc.
Recurive servers (honouring RD=1) however can be authoritative for
zones. This proves robustness in the presence of link failures.
Faster than ttl expiry of local zone changes (provided that notify
messages are sent).
Unfortunately this has become strict seperation lore which really
wasn't ever the intent.
Mark
Though it didn't work out the one time we had an extended link blockage (due
to a full log volume - no log no pass) At first local resolution continued
working, until all the recursion slots (10,000) filled up on my (4) recursive
servers, which are authoritative slave for local domain...had them stop
answer anything.
Otherwise, its normally how we get local changes out quickly despite usually
have a 1 day TTL. Though when its a domain that we host that they want to
see a quick local change....we sometimes do nasty cache flushes to make that
change appear. I have a script that takes care of that....which goes through
all the servers without delays (I've debated on which is better, or if it
doesn't matter.) I've played around with flushname/flushtree, but they don't
seem always work....
So, I'm considering trying to separate things again.
--
Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator
with LOPSA Professional Recognition.
For: Enterprise Server Technologies (EST) -- & SafeZone Ally
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
