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
servers.
- Kevin
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 8.8.8.8 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.
V/r,
Bryan
_______________________________________________
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
_______________________________________________
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
