Private & separate DNS domains
kcd at chrysler.com
Tue Apr 8 15:55:40 UTC 2014
Regardless of what you've been told, the resolvers ("nameserver"s) in
/etc/resolv.conf are tried *in*sequence*, and if a valid response (where
NXDOMAIN _is_ a valid response) is received from one resolver, none of
the others are tried. So, I'm surprised that your
mix-and-match-resolvers hack actually works. The only thing that comes
to mind is that the Windows DNS is so horked that it's returning
SERVFAIL for names outside of its authoritative domains. That would
trigger failover to another resolver, but that's an *ugly* way to
integrate BIND and Windows DNS.
Instead of guessing at such things, learn how to use tcpdump/Wireshark
and find out what's really happening under the covers. I haven't seen a
resolver implementation send queries *simultaneously* to all resolvers,
since circa Windows 95. And I've never seen it on Linux.
As for a long-term solution, either define an internal root zone (with
conditional forwarding exceptions for the external stuff you *need* to
resolve), or, if you must, forward by default to the Internet and then
define all of the "private" stuff as master/slave/stub on your internal
On 4/8/2014 6:08 AM, Bryan Harris wrote:
> Hello all,
> We have a sort of private DNS such that servers can lookup zones that don’t actually exist in the real, public DNS, they just exist within our private NOCs. In addition, we have always had both Windows AD handling the Windows side of things and we have had BIND handling Linux.
> When the BIND servers don’t know about a domain, they forward to a public server such as google’s 188.8.131.52 thing. For some reason the Windows guys aren’t allowed that option on their DNS (I believe it’s a security requirement), so any Windows server that DOES need public DNS resolution always has a BIND server listed in the TCP/IP properties of the network interface (from what I have seen, it’s usually not the first DNS server in the list).
> Anyway, up until now Windows servers primarily got DNS answers via AD (except as mentioned above), and Linux servers via the BIND servers. Recently, however, we have enabled AD authentication on Linux, meaning the Linux servers need to know about the AD domains (well, they need to know about the kerberos and ldap service records and whatnot).
> The current mechanism is to put the Windows AD server into the resolv.conf BEFORE the BIND servers, since, as has been explained to me a Linux server will perform a query against all three simultaneously (that doesn’t immediately ring true to me, it’s just what I was told). While this does seem to work, I’ve been wondering if it would be of any benefit to instead let the BIND servers know about the AD zones in some way, allowing us to continue with our “Linux sends all queries to BIND” methodology.
> As I understand BIND could be theoretically doing conditional forwarding, or it could use stub zones, or perhaps could be a slave with AD as the master. Is it just as well to leave things alone? Or would one of these be preferable to its current setup? Any advice or guidance would be greatly appreciated.
> Thanks in advance.
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> bind-users mailing list
> bind-users at lists.isc.org
More information about the bind-users