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.
http://www.intodns.com/ Warn SOA MNAME entry WARNING: SOA MNAME (tncsrv06.tnetconsulting.net) is not listed as a primary nameserver at your parent nameserver!
My master name server, tncsrv06.tnetconsulting.net, 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}.linode.com. 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 _______________________________________________ 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
