separation of authoritative and recursive functions on internal networks

Grant Taylor gtaylor at
Mon Feb 8 00:00:59 UTC 2016

On 02/07/2016 04:12 PM, Reindl Harald wrote:
> define OK

Will it cause any problems if the slave server is not listed as an NS?

> for internal use NS records don't matter at all because the
> only thing which matters is that the machines listed in /etc/resolv.conf
> respond correctly

I think I understand the intent behind what you are trying to say.  (NS 
(delegation) records aren't needed for internal zones -as long as- 
clients that use them are configured correctly.)

I do question the scalability of that intent.  If I expand the SOHO 
analogy to be a larger corporate + multiple branch offices scenario, I 
can see how internal delegation w/ associated NS records would be needed.

> if it comes to the internet - it makes no sense have nameservers which
> are not listed as NS records

I disagree.

> Warn     SOA MNAME entry     WARNING: SOA MNAME
> ( is not listed as a primary nameserver at
> your parent nameserver!

My master name server,, is internet 
accessible, but it is not listed as a NS because I want all public 
queries to go through my slaves, ns{1..5}  Yet, people can 
direct queries to my master name server if they have a specific reason 
to do so.

I've previously asked Cricket Lou and Matt Larson, via Mr-DNS, if this 
type of configuration (having an Master Name server not listed in the NS 
records) is a problem and they indicated that it's not 100% ideal, but 
it will not cause any problems as long as the listed NS servers are 
accessible and used for delegation from the parent.  I.e. if your MNAME 
server is behind a firewall that will only allow the slave NS servers to 
communicate with it.

What was your intent in pointing that out?  That has nothing to do with 
my original question.

Further, I don't see any response to my question, mixing recursive and 
authoritative resolvers in a SOHO scenario that is not internet accessible.

Grant. . . .
unix || die

More information about the bind-users mailing list