Replacing /etc/hosts aliases with local-data: directive

Unbound
1

We've recently set up Unbound as a local recursive resolver, which is
working great. We've got a dozen or so servers on our rack across
three different domains, so we've been using our /etc/hosts file to
set up aliases for them. For example:

123.456.78.910 jim.domain1.com jim
234.567.89.012 doug.domain2.com doug
345.678.90.123 sally.domain3.com sally

This way, we can easily connect to local systems by simply doing "ssh
jim" or 'ftp sally."

The problem is that when we change a host's IP address, or add a new
host to the rack, we have to manually update the hosts file on EVERY
box, so I've been fiddling with unbound to try and make it so we only
have to update it in one place, and then it will act as the local
resolver for those IPs.

I can make it function with the following:

local-zone: "local." static
local-data: "jim.local. IN A 123.456.78.910"
local-data: "doug.local. IN A 234.567.89.012"
local-data: "sally.local. IN A 345.678.90.123"

But it's not exactly what we want... we have to do "ping jim.local" or
"ssh doug.local" to connect.

Is there a way to configure unbound.conf so that it will work without
the ".local" ?

Thanks,

SteveJ

2

You could simply edit your /etc/resolv.conf, and add a domain or search directive, on each of your servers

cat /etc/resolv.conf

search local

nameserver 127.0.0.1

 # cat /etc/unbound.conf | grep "\.local"

local-data: “testing.local IN A 127.0.0.5”

ping testing

PING testing.local (127.0.0.5) 56(84) bytes of data.

64 bytes from 127.0.0.5: icmp_seq=1 ttl=64 time=0.055 ms

– Arni

3

Thanks, Arni. Worked like a charm!

SteveJ

4

Hello Steve,

please be aware that the use of a non-registered top level domain, esp.
the top level domain ".local', can be problematic.

The problem here is that if your network is attached to the Internet,
any typo will leak out to the Internet root DNS Server system and will
cause little traffic there. Having only one system doing this is not a
big problem, but in total most of the traffic going to the root DNS
Server system is such bogus traffic that should be avoided (there is
also a security aspect in having private data leaking to the public
Internet).

This graph at
http://dns.icann.org/cgi-bin/dsc-grapher.pl?window=86400&plot=qtype_vs_invalid_tld&server=L-root
shows all the invalid TLD queries going to one of the root name servers
(l.root-server.net).

You see '.local' is very high in that list. The reason for this is that
the '.local' TLD is used for a service called 'MulticastDNS'
(http://www.multicastdns.org/). Multicast DNS is know as
'Bonjour/Rendezvous' on Apple MacOS X systems, and Avahi on
Linux/Solaris and the BSD Unixes. It is also build into some hardware,
such as Axis network cameras, Roku SoundBridges, TiVo PVR. It can also
be installed on Windows systems.

On these machines, any name lookup for a domain name will not send to
the DNS system (the Unbound resolver) but will be resolved by the
operating system using multicast DNS.

So your use of '.local' will not work on these system.

A much 'standard compliant' way would be to use a full DNS name in
Unbound. If your official DNS domain is 'example.com', your can use in
the Unbound configuration:

local-zone: "example.com." static
local-data: "jim.example.com. IN A 123.456.78.910"
local-data: "doug.example.com. IN A 234.567.89.012"
local-data: "sally.example.com. IN A 345.678.90.123"

and then use the same trick Arni has suggested in the 'resolv.conf':

5

Steve,

I agree with Carsten.
It's cleaner to setup dnsnames in your domain for every ip-addresse you configure on your systems.
(I assum you are using public adresses...)

Then you can setup searchdomain in /etc/resolv.conf.

Andreas

6

Hi, Carsten. Thanks for the well-thought out and detailed reply. I
agree this would be ideal, however, the systems in question don't all
share the same domain name, and can't share the same local-zone. So I
was looking to avoid having to list all the domains as search targets
in /etc/resolve.conf and manage a dozen+ /etc/hosts.

Also, using multiple domains in the resolve.conf search line and
multiple local-zones entries won't work in our case, either, because
we use wildcard DNS on the authoritative nameservers to direct typo
traffic on our domains to our websites (we run a number of very
popular network of video game websites and visitors often mis-type our
subdomains). So even if we set it up as:

local-zone: "example1.com." static
local-data: "jim.example1.com. IN A 123.456.78.910"

local-zone: "example2.com." static
local-data: "doug.example2.com. IN A 234.567.89.012"

local-zone: "example3.com." static
local-data: "sally.example.com. IN A 345.678.90.123"

and:

7

I'm not following everything here.

I remember when my distro started incorporating mDNS and my ".local"
internal TLD, which had worked fine for years, stopped functioning
properly. I either had to change my internal TLD or disable mDNS on
the systems. The better fix was to stop using ".local" so I elected
that route.

However, the mDNS issue aside, I was under the impression that Unbound
does not recursively resolve local-data, that it is in effect
authoritative for it, much like using a stub-zone pointing to an
authoritative server such as NSD serving a private internal domain
(such as .soho, .office, .home, etc.). Therefore queries for such
domain names would not get leaked to the root servers. Or would they?
What am I missing?

Thanks,

Chris

8

however, the systems in question don't all
share the same domain name, and can't share the same local-zone. So I
was looking to avoid having to list all the domains as search targets
in /etc/resolve.conf and manage a dozen+ /etc/hosts.

Hello Steve,

you are right, multiple entries in the search list are not optimal and
can result in a bad user experience.

However my recommendation was not to replace the '.local' top level
domain (TLD) with the original domain names of the machines. Instead I'm
recommending to replace the not delegated '.local' domain with an
delegated 2nd level or 3rd level domain owned by you.

It would still be just _one_ domain, only used for the purpose of having
short names for the machines. The 'resolv.conf' searchlist would just
have this one domain entry.

This domain can either be a new 2nd level domain
('mylocaldomainforshortnames.us' <- silly example, you might want to
have a shorter one :slight_smile: ) or, if you are able to create DNS delegated
subdomains for a 2nd level domain you already own, a 3rd level domain
(if you already own 'example.com', you can delegate 'local.example.com'
to your authoritative DNS servers and use that single domain name for
the purpose of having short names and a searchlist).

From the user perspective (being able to use single label names for

commands shuch as 'ping', 'ftp' etc), this is the same as using
'.local'. For the Internet infrastructure, it makes a difference. If you
use '.local', any leaking data will hit the root server system.

With a 2nd or 3rd level domain, any leaking names will just hit the
authoritative DNS Servers for _that_ domain and will not have a negative
impact on the Internet infrastructure.

In my 15 year experience of DNS I found that it is almost impossible to
prevent private names to leak to the Internet (except for networks that
have no direct IP connection to the Internet). While it is possible to
prevent most leaking with a careful configuration of the resolving DNS
Servers, I have often seen that the names will also appear inside the
payload (badly written network protocols, headers of mail messages,
logfiles ...) and being looked up from DNS at a place where you do not
have control over the DNS. I have so far not seen anyone succeeding in
completely preventing leakage of internal names. That is very very hard
to do.

If you look at the graph from the root server I've send in my previous
mail, that chart is full of names (.belkin, .lan, .corp, .home, .domain,
.prv, .localdomain ...) that the companies and persons that 'invented'
them for 'local only use' thought they have the problem of leakage under
control. The real world data from the root server shows that it is not
under control.

However, take this with a grain of salt. I'm not the DNS police :slight_smile:

This is just a recommendation.

Have a good weekend

Carsten

9

Hello Chris,

you are right, if these queries would only go towards a carefully
configured resolving DNS Server that terminates this local domain, the
names will no leak.

However experience shows that the names will show up inside the payload
of network data (badly designed protocols that embed names in the
payload) and as an result of this will be looked up in different
networks where you do not have the control over the DNS and the local
names are not terminated on the resolving DNS Server.

It is very hard to prevent leakage of private names.

An official DNS domain that is registered in the Internet, but only used
in the internal network is the best choice. It prevents any name
clashes, because you 'own' that name.

Starting later this year it will be possible to 'buy' your own top level
domain (not cheap though). So you cannot be sure that any 'private' top
level domain will not appear in the Internet at some point of time.

Other than spending a little money for a domain (you can get domains for
less than US$ 20 a year), there is no technical difference for the
operator using a registered domain you own internally vs. an
unregistered TLD. But there is a difference for the Internet infrastructure.

-- Carsten

10

in this case you may want to look into the "hostaliases" feature of
your (stub) resolver.

-Peter

11

Hello Carsten,

please be aware that the use of a non-registered top level domain, esp.
the top level domain ".local', can be problematic.

True,

If you down own your own domain, it is better to get one (domains are
not expensive) and not to 'hijack' one (as you do not own '.local',
using that TLD withour permission is kind of hijacking it).

Alternatively, use something in the .EXAMPLE or .TEST domains (RFC 2606)
or one of the explicitly reserved country codes, such as .AA [1].

Regards,

        -JP

[1] http://www.iso.org/iso/customizing_iso_3166-1.htm

12

In my cases, and possibly for others, the DNS is under control but not
all of the client systems (independent agents working in the office
with their own computers). When using a sub-domain of the registered
SLD failed host queries are then retried by the clients with the
parent domain (SLD) creating extra traffic/noise/work. Whereas using a
private TLD like ".office", ".soho", etc. eliminates that issue. Of
course, using the registered SLD directly would also eliminate the
parent lookup but (again in my cases) these are small businesses where
the registered domains public DNS info are served externally (by the
hosting site or registrar) and not used for internal systems on
private addresses.

And as the SLD (ex: "businessname.office") is a (as Windows calls it)
connection specific DNS suffix, and temporary - DHCP assigned when in
the building, it should not be problematic.

Chris