Internal clients' queries for "myhostname." get sent to forwarders. Why?

[Kevin Darcy]

Options:

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 lookups
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 
see.

                                 - Kevin

On 3/10/2014 3:58 PM, Andreas Ntaflos wrote:
> Hi list,
>
> I hope I succeeded in articulating the problem we are facing and I
> apologize for the length of this post.
>
> Short version:
>
> Using Bind 9 on Ubuntu 12.04 for internal DNS (master for zones
> "dc01.example.at.", "7.1.10.in-addr.arpa.", ...) with forwarders (ISP's
> nameservers) for everything outside of internal zones.
>
> The Problem: Clients, when running "hostname -f" or "hostname -i",
> create queries for "myhostname." which are sent to the forwarders which
> respond with NXDomain. This generates load on the forwarders and exposes
> our internally used hostnames, both of which seems unnecessary and
> possible dangerous.
>
> This doesn't seem like normal or healthy behaviour. What can we do to
> stop it?
>
> Long version:
>
> In our internal networks we are running Bind 9 on Ubuntu 12.04
> (9.8.1.dfsg.P1-4ubuntu0.8). The nameserver is configured to be master
> for the zone "dc01.example.at" (obviously we don't use "example", but
> the other domain components are real). It also serves in-addr.arpa zones
> for the internal IP addresses (7.1.10.in-addr.arpa., and so on).
> Recursion is enabled for internal clients.
>
> The internal nameserver uses our ISP's nameservers as forwarders for
> everything outside of the zones for which it is master.
>
> All clients in our internal networks have names like
> "auth01.mgmt.dc01.example.at" or "puppet02.dev.dc01.example.at". All
> clients' resolvers are configured with one nameserver and multiple
> search domains, like this:
>
> # /etc/hosts:
> 127.0.0.1 localhost
>
> # /etc/resolv.conf:
> nameserver 10.1.7.42
> search mgmt.dc01.example.at dc01.example.at
>
> Clients are Ubuntu and Debian machines (10.04, 12.04, Lenny, Wheezy).
>
> This all works fine (and has for years now), but recently we became
> aware of the fact that whenever a client system runs "hostname -f" or
> "hostname -i" it will ask the internal nameserver for hostname plus each
> search domain (which is fine), AND for the plain hostname with a
> trailing dot (which is not fine). I can see this from the nameserver's
> query logs and from tcpdump.
>
> For example, on "auth01.mgmt.dc01.example.at" the nameserver gets asked for:
>
> auth01.mgmt.dc01.example.at.
> auth01.dc.example.at.
> auth01.
>
> The nameserver replies correctly with the client's FQDN or IP address
> for the first query, as well as with NXDomain for the second query (also
> correct) but then forwards the third query ("auth01.") to the configured
> forwarders (our ISPs nameservers). This naturally returns NXDomain.
>
> I am confused and worried by this behaviour. Since we have quite a few
> hosts in our internal networks (all running Puppet agents) the
> forwarders get hit with requests for "hostname." like above multiple
> times per second. It also exposes to the forwarders the hostnames of our
> internal machines, which isn't great.
>
> Is this the expected behaviour? What can we do to stop our internal
> nameserver from forwarding queries for "hostname." to our ISPs nameservers?
>
> I have not included any Bind configuration or zone files here, but I can
> provide anything needed to facilitate debugging this issue. Please let
> me know!
>
> Thanks in advance for any help and pointers, particularly RTFM. I have
> had a really hard time googling this :(
>
> Andreas
>
>
>
> _______________________________________________
> 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
> https://lists.isc.org/mailman/listinfo/bind-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20140310/b0a45bc9/attachment.html>