Internal clients' queries for "myhostname." get sent to forwarders. Why?
davew at hireahit.com
Tue Mar 11 00:10:37 UTC 2014
On 2014-03-10 15:05, Andreas Ntaflos wrote:
> On 2014-03-10 22:23, Kevin Darcy wrote:
> First, thanks a lot for the reply! So it seems what I described is
> indeed the expected behaviour for the type of DNS we operate?
To put it another way, why wouldn't it? How would your local BIND know
whether or not a query for "myhostname." or "museum." is valid or not?
One of those has records (although just NS records, no A records)
>> 1) Change nameservice-switch order (e.g. /etc/nsswitch.conf) on your
>> hosts to prefer another source of name resolution (e.g. /etc/hosts)
>> which can resolve the shortname. Thus DNS is never used for these
> This might be a solution but I find that our DNS setup is just complex
> enough that relying on /etc/hosts would probably introduce more
> problems. Then there's managing /etc/hosts on hundreds of machines,
> which we could of course do with Puppet, but I find that highly
> unappealing. Currently we use Puppet to ensure /etc/hosts contains
> just "127.0.0.1 localhost" and nothing else.
Can you configure your environment to also write the machine's own
hostname into the hosts file? We're generally not talking about storing
every single host into every single HOSTS file, just having each machine
know it's own hostname matches 127.0.0.1.
This should happen automatically and transparently in the Windows world
(without appearing in the HOSTS file explicitly), but not in the *nix world.
Beyond that, in the Windows world, a machine will append the local
domain's search suffix before doing a bare "hostname" lookup, so these
queries typically won't leak as long as your local search suffix points
to a zone that resolves local hosts and gives a valid answer. I suspect
the same is true in *nix environments, but it's been a while since I
mucked around, so I don't know what modern *nix does.
>> 2) Simply :-) change your DNS architecture fundamentally, from one which
>> forwards requests to the Internet by default (aka "the Microsoft way"),
>> to one with an internal root zone and conditionally forwarding only
>> those parts of the namespace that your internal clients actually need to
> I confess that I didn't think there was any feasible way other than
> what you call "the Microsoft way" to operate this kind of internal
> DNS. I also don't think I've ever consciously heard of the setup you
> describe. Can you point me to some reading material on what this
> entails and how to get there?
In general there isn't much to it, if you don't set up a forwarded then
BIND will use it's .hints file to locate the root servers, and from
there, it will resolve whatever it needs to resolve recursively, taking
over the roll of your upstream forwarder.
I'm sure someone can post a link to proper documentation, if you need it.
Incidentally, in the Windows world, you do the same, just leave the
forwarders list blank and Microsoft DNS does full recursion. The old DNS
setup wizards encouraged forwarders since they made a lot more sense in
the high-latency, well maintained DNS server worlds of yester-year, but
today, you'll probably do a better job of doing your own recursion if
only because most ISPs do a terrible job of their own DNS servers.
More information about the bind-users