[Unbound-users] Replacing /etc/hosts aliases with local-data: directive

[Steve Jenkins]

On Fri, Mar 25, 2011 at 12:51 AM, Carsten Strotmann
<unbound at strotmann.de> wrote:
> 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"

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:

*
# cat /etc/resolv.conf
search example1.com example2.com example3.com
nameserver 127.0.0.1
*

A "ping doug" doesn't hit the right server (example2.com), because
example1.com's wildcard DNS matches first.

> 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).

I can see the wisdom in that. However, since our unbound server is not
authoritative for our systems (all of which have FQDNS names managed
by a separate nameserver cluster) it's possible that the public IP
address for the might get changed in the authoritative nameserver, and
that one of us would forget to update it in unbound, and we'd be
broadcasting the incorrect IPs to our local network. Of course, we'd
probably notice that issue quickly, but I'm looking to avoid that
potential altogether.

All this said, while I agree with you that there is technically a risk
of typo traffic going to the root servers, the practical risk of that
happening in this situation is very minimal. These machines have only
two admins that access them, and no standard user accounts.  And the
two of us who access these boxes ar booth greet tiepers. :) These
"shortcuts" would only be used a few times per week at most by two
individuals.

SteveJ