[Unbound-users] SERVFAIL for an abbreviated TLD local zone

[martin f krafft]

Hey folks,

I am a bit baffled by the following problem and seek your advice.

I am on a LAN and 192.168.14.1/24 is running unbound
1.4.17-3+deb7u1. It is a recursive resolver, except that the zone
"gern" is forwarded to ::1 on the host, where nsd3 runs and resolves
them ("gern" is actually a 1:1 copy of gern.madduck.net, but I am
using the abbreviated zone internally).

This works just fine and all hosts on the LAN are happy.

I also have a laptop running unbound 1.4.22-2 (because I often need
to add local-zones and I have a few kvm instances on the host).
resolvconf configures unbound to use 192.168.14.1 as a forwarder,
and this also works just fine for all global domains, e.g.

% grep nameserver /etc/resolv.conf
nameserver 127.0.0.1

% host debian.org | wc -l
11

% ping -nc1 debian.org
PING debian.org (128.31.0.62) 56(84) bytes of data.
64 bytes from 128.31.0.62: icmp_seq=1 ttl=53 time=265 ms
[…]

For the purpose of solving the problem at hand, I have reduced the
config to only have one directive:

auto-trust-anchor-file: "/var/lib/unbound/root.key"

The problem is that any requests for the abbreviated "gern" zone
yield SERVFAIL.

% host julia.gern
Host julia.gern not found: 2(SERVFAIL)

but they work fine when addressed directly at the LAN DNS server:

% host julia.gern 192.168.14.1
julia.gern has address 192.168.14.2
julia.gern has IPv6 address 2001:a60:f0fb:0:9eb6:54ff:fe0b:e5e4

Do you have any idea why unbound is failing on the abbreviated zone
requests?

I fI remove the auto-trust-anchor-file config directive, it works,
so it seems this is DNSSEC-related (none of my zones are signed
yet). Can someone enlighten me and help em understand what's going
on?

What's the best way to solve this?

Thanks!

[Robert Edmonds]

Post by martin f krafft
Do you have any idea why unbound is failing on the abbreviated zone
requests?

Your second Unbound instance is receiving answers that do not validate
from the first Unbound instance. (The root zone is signed and
authentically denies the existence of "gern".)

Post by martin f krafft
I fI remove the auto-trust-anchor-file config directive, it works,
so it seems this is DNSSEC-related (none of my zones are signed
yet). Can someone enlighten me and help em understand what's going
on?

DNSSEC protects against the kind of interloping you described.
Removing the auto-trust-anchor-file line disables validation.

Post by martin f krafft
What's the best way to solve this?

You could sign your "gern" zone and configure a trust anchor for that
zone, or you could use the "domain-insecure" option in unbound.conf to
configure a "negative trust anchor".

[Jeroen Massar]

On 2014-12-07 20:52, martin f krafft wrote:
[..]

Post by martin f krafft
I fI remove the auto-trust-anchor-file config directive, it works,
so it seems this is DNSSEC-related (none of my zones are signed
yet). Can someone enlighten me and help em understand what's going
on?

As the root does not know your custom zone, that custom zone is not
properly signed and voila ;)

Maybe what you want to do is use the 'search domain' option to point it
to the non-local edition; or .... disable dnssec (possibly selectively)

Greets,
Jeroen

[Jeroen Massar]

Post by Jeroen Massar
[..]

Post by martin f krafft
I fI remove the auto-trust-anchor-file config directive, it works,
so it seems this is DNSSEC-related (none of my zones are signed
yet). Can someone enlighten me and help em understand what's going
on?

As the root does not know your custom zone, that custom zone is not
properly signed and voila ;)
Maybe what you want to do is use the 'search domain' option to point it
to the non-local edition; or .... disable dnssec (possibly selectively)

As per:

http://utcc.utoronto.ca/~cks/space/blog/linux/UnboundDNSforVPN

8<---------
# Don't try to do DNSSEC for these
domain-insecure: gern
---------->8

Should do the trick for you :)

Greets,
Jeroen

[martin f krafft]

Post by Jeroen Massar
As the root does not know your custom zone, that custom zone is
not properly signed and voila ;)

Ah, of course (Thanks also to Robert!)

I think the real solution is to sign the zone. DNSSEC is on my to-do
list anyway — for years ;)

[Jeroen Massar]

Post by martin f krafft

Post by Jeroen Massar
As the root does not know your custom zone, that custom zone is
not properly signed and voila ;)

Ah, of course (Thanks also to Robert!)
I think the real solution is to sign the zone. DNSSEC is on my to-do
list anyway — for years ;)

You are missing one item: even if you sign the zone, the root does not
delegate-signed towards your zone.

Hence, even if your zone is signed, those signature won't be trusted and
thus the zone won't work anyway.

The reason why your zone currently does not work is because there is no
signed delegation towards that zone; hence the zone, in signed fashion,
does not exist.

As per other mail:
8<-----------------------
domain-insecure: gern
----------------------->8

Should solve that.

Greets,
Jeroen