unbound fetches DNS record from nsd but does not return it to client

Unbound
1

Hi,
First posted this to ServerFault without luck. Looks like it might be an unbound bug, or am I doing something wrong?

2

First I'm not an expert but, I think you need to change access-control "allow" to "allow_snoop". However, if its just your local network why not let unbound handle it.

(something similar to below)
local-zone: "home." static
         local-data: "datanet.home. IN A 192.168.1.61"
         local-zone: "1.168.192.in-addr.arpa." static
         local-data-ptr: "192.168.1.61 datanet.home"

3

I doubt that
       local-zone: "1.168.192.in-addr.arpa" nodefault
is necessary since you're defining it as a stub-zone.

Possibly you're missing a
      domain-insecure: "datanet.home"
or a
      private-domain: "datanet.home"
statement that may resolve your problem.

Chris

4

This is actually necessary. I just tested on my firewall at home, and if
I remove "local-zone: "168.192.in-addr.arpa." nodefault" I will get the unbound
default NXDOMAIN even if I still have my stub-zone declaration:

5

While I am not sure off the top of my head what is going wrong since you
already have the "do-not-query-localhost: no" setting, I personally like
to use unbound-host when debugging unbound behaviour. Using -C you can
point out the unbound.conf file and possibly have an easier time
reproducing the problem.

It might be interesting to see the complete output of:
unbound-host -C /path/to/unbound.conf -d -d -v data1.datanet.home

6

thanks all! Got it, I think!

Needed the “domain-insecure” bits, then reverse DNS was failing so I also needed to change the local-zone as Patrik mentioned.

Complete unbound.conf now:

server:
interface: 127.0.0.1
interface: 192.168.1.50
use-syslog: yes
username: “unbound”
directory: “/etc/unbound”
trust-anchor-file: trusted-key.key
access-control: 192.168.1.0/24 allow_snoop
local-zone: “1.168.192.in-addr.arpa.” transparent
do-not-query-localhost: no
domain-insecure: “datanet.home”
domain-insecure: “1.168.192.in-addr.arpa”
remote-control:
control-enable: yes
control-interface: 127.0.0.1
control-port: 8953
server-key-file: “/etc/unbound/unbound_server.key”
server-cert-file: “/etc/unbound/unbound_server.pem”
control-key-file: “/etc/unbound/unbound_control.key”
control-cert-file: “/etc/unbound/unbound_control.pem”

stub-zone:
name: “datanet.home”
stub-addr: 192.168.1.50@53530
stub-zone:
name: “1.168.192.in-addr.arpa”
stub-addr: 192.168.1.50@53530

7

Ah yes, and that's what I use... should have looked it up before
sending from memory :slight_smile:

8

Hi Patrik,

I doubt that local-zone: "1.168.192.in-addr.arpa" nodefault is
necessary since you're defining it as a stub-zone.

This is actually necessary. I just tested on my firewall at home,
and if I remove "local-zone: "168.192.in-addr.arpa." nodefault" I
will get the unbound default NXDOMAIN even if I still have my
stub-zone declaration: === stub-zone: name:
"1.168.192.in-addr.arpa" stub-addr: 127.0.0.1 ===

However, the configuration is still wrong since "nodefault" only
works on the specific RFC1918 boundaries, and not anything below.
If I change this: --- local-zone: "168.192.in-addr.arpa."
nodefault --- ... to this: --- local-zone:
"1.168.192.in-addr.arpa." nodefault ---

I again get the unbound default NXDOMAIN even if it looks like it
matches what I want better. As you have pointed out to me on
openbsd-misc in the past, the correct configuration to use in the
latter case is this: --- local-zone: "1.168.192.in-addr.arpa."
transparent ---

This is only mentioned in passing in the man page for unbound.conf
and I had missed it completely before you pointed it out to me
here: http://marc.info/?l=openbsd-misc&m=140647222022445&w=2 This
is probably my biggest pet peeve in the unbound configuration :).

This of course does not relate to the main question in the thread,
but I am pretty sure reverse lookups does not currently work either
for the above reasons.

I've fixed up the manual page and the example config file, and they
now discuss configuring domain-insecure or local-zone nodefault for
locally served zones.

The configuration is like this because the access-control filter
happens first (it is by IP address netblock). Then the local-zone
filter is applied (it is by domain name). Then the DNS cache is used,
the items are fed in there with the stub-zone clause. The cache
entries are also 'filtered' by DNSSEC validation and private-address
removal. And all of these components are separately configurable...

Best regards,
   Wouter

9

Thank you for making the configuration information more explicit. I
believe what I have been missing is a hint at the "nodefault" description that
it only works for the exact zone names:

10

Note that 1.168.192.in-addr.arpa is not an AS112 zone.

11

Hi Patrik,

I've fixed up the manual page and the example config file, and
they now discuss configuring domain-insecure or local-zone
nodefault for locally served zones.

Thank you for making the configuration information more explicit.
I believe what I have been missing is a hint at the "nodefault"
description that it only works for the exact zone names:

=== nodefault Used to turn off default contents for AS112 zones.
The other types also turn off default contents for the zone. The
'nodefault' option has no other effect than turning off default
contents for the given zone. ===

Reading this it is not clear to me that "nodefault" only works for
the exact zones, and that I am supposed to use "transparent" if I
configure 1.168.192.in-addr.arpa for example.

Added text to address that. Thanks for pointing that out and the
'transparent' workaround for it.

Maby this is just me :).

Out of curiosity: what is the reason unbound does not work for the
original poster if domain-insecure is missing? The domain was
"data1.datanet.home", and since there is no DS record for "home" at
".", it seems to me this would mean no further DNSSEC processing is
necessary. What am I missing?

There is an NXDOMAIN at "home." at ".". DNSSEC does not allow data
under an NXDOMAIN. If there would have been an insecure delegation
(NS records and no DS record), then it would have worked as you said.

Best regards,
   Wouter

12

Added text to address that. Thanks for pointing that out and the
'transparent' workaround for it.

Looks good, thanks :).

There is an NXDOMAIN at "home." at ".". DNSSEC does not allow data
under an NXDOMAIN. If there would have been an insecure delegation
(NS records and no DS record), then it would have worked as you said.

Ah, of course! Thank you for clearing that up.