separation of authoritative and recursive functions on internal networks

[Lawrence K. Chen, P.Eng.]

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