Maintained by: NLnet Labs

[Unbound-users] Servers for local zones that are not signed

Eugene Crosser
Fri Jul 6 13:08:16 CEST 2012


Hello all,

sorry if this was discussed already, I could not find the answer.

I am trying to configure unbound (1.4.5, running on openwrt) to resolve local
zones ("lan." and "168.192.in-addr.arpa.") from another DNS server that has them
(in my case, dnsmasq: I want DHCP names resolved in the .lan zone).

I configured "the other DNS server" to bind to non-standard port (5553) and put
this into unbound.conf:

forward-zone:
        name: "lan."
        forward-addr: 127.0.0.1 at 5553

(I also tried "stub-zone:" with "stub-addr:"). Now I am trying to resolve
"myhost.lan" which is registered in dnsmasq (I can get the address if I ask "dig
-p 5553 myhost.lan @<openwrt-ip-addr>"). But resolving through unbound does not
work because unbound tries to obtain the DS for "lan." from the root
nameservers. _If_ it got NODATA, everything would have been OK, I would get an
"insecure" (without 'ad') answer as from normal non-dnssec zones. But obviously
the root servers answer with NXDOMAIN. So unbound asks dnsmasq for the address
of "myhost.lan" as it is instructed by forward-zone, gets correct result (!),
but then marks it bogus because it cannot establish trust chain.

As I understand, unbound should not try to get DS from the parent of a zone that
is configured as "forward" or "stub": if it is by definition "local" then there
is no point in asking the "global authorities" to certify for it. If your local
zones _are_ signed, you should be able to add 'local-data "lan. DS ....."' but
if they are _not_ signed, the resolver should behave as if the DS query returned
NODATA.

Am I missing something?
Is unbound missing something?
Is there a workaround?

Thanks,

Eugene

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
URL: <http://unbound.nlnetlabs.nl/pipermail/unbound-users/attachments/20120706/3f2e9bb3/attachment.pgp>