4

I have unbound running as an validating, caching, recursive dns server and nsd3 running as an authoritative nameserver. It seems like every aspect of both work correctly until I attempt to resolve an address that should be forwarded to nsd3. I've narrowed the problem down to the stub-zone that forwards from unbound to nsd3 and it looks like it isn't resolving the 'stub-host' name. According to the logs, unbound is attempting to resolve the 'stub-host' using an external dns instead of /etc/hosts (although this could be because it is failing during lookup somehow). I've tested hardcoding the ip of the nsd3 server which seems to work perfectly.

Here's the relevant part of my unbound config (full config is Here):

private-domain: "test.lan"
local-zone: "0.0.10.in-addr.arpa." nodefault
stub-zone:
     name: "test.lan"
     stub-host: unsd_nsd3

forward-zone:
     name: "."
     forward-addr: 8.8.8.8        # Google Public DNS
     forward-addr: 74.82.42.42    # Hurricane Electric
     forward-addr: 4.2.2.4        # Level3 Verizon

Here's the output from unbound with a log level of 3. I ran dig mithril.test.lan @localhost as a test (it resolves correctly when nsd3 is queried directly):

[1448909203] unbound[1:0] debug: validator[module 0] operate: extstate:module_state_initial event:module_event_moddone
[1448909203] unbound[1:0] info: validator operate: query unsd_nsd3. A IN
[1448909203] unbound[1:0] debug: iterator[module 1] operate: extstate:module_wait_subquery event:module_event_pass
[1448909203] unbound[1:0] info: iterator operate: query mithril.test.lan. A IN
[1448909203] unbound[1:0] info: processQueryTargets: mithril.test.lan. A IN
[1448909203] unbound[1:0] info: new pside target unsd_nsd3. A IN
[1448909203] unbound[1:0] debug: iterator[module 1] operate: extstate:module_state_initial event:module_event_pass
[1448909203] unbound[1:0] info: iterator operate: query unsd_nsd3. A IN
[1448909203] unbound[1:0] info: resolving unsd_nsd3. A IN
[1448909203] unbound[1:0] info: processQueryTargets: unsd_nsd3. A IN
[1448909203] unbound[1:0] info: sending query: unsd_nsd3. A IN
[1448909203] unbound[1:0] debug: sending to target: <.> 74.82.42.42#53
[1448909203] unbound[1:0] debug: cache memory msg=132347 rrset=132399 infra=5449 val=132392
[1448909203] unbound[1:0] debug: iterator[module 1] operate: extstate:module_wait_reply event:module_event_reply
[1448909203] unbound[1:0] info: iterator operate: query unsd_nsd3. A IN
[1448909203] unbound[1:0] info: response for unsd_nsd3. A IN
[1448909203] unbound[1:0] info: reply from <.> 74.82.42.42#53
[1448909203] unbound[1:0] info: query response was NXDOMAIN ANSWER
[1448909203] unbound[1:0] info: finishing processing for unsd_nsd3. A IN
[1448909203] unbound[1:0] debug: validator[module 0] operate: extstate:module_state_initial event:module_event_moddone
[1448909203] unbound[1:0] info: validator operate: query unsd_nsd3. A IN
[1448909203] unbound[1:0] debug: iterator[module 1] operate: extstate:module_wait_subquery event:module_event_pass
[1448909203] unbound[1:0] info: iterator operate: query mithril.test.lan. A IN
[1448909203] unbound[1:0] info: processQueryTargets: mithril.test.lan. A IN
[1448909203] unbound[1:0] debug: out of query targets -- returning SERVFAIL
[1448909203] unbound[1:0] debug: return error response SERVFAIL
[1448909203] unbound[1:0] debug: validator[module 0] operate: extstate:module_wait_module event:module_event_moddone
[1448909203] unbound[1:0] info: validator operate: query mithril.test.lan. A IN
[1448909203] unbound[1:0] debug: cache memory msg=132557 rrset=132624 infra=5449 val=132392

As a side note, I'm running both unbound and nsd3 in their own docker containers from a debian base image and linked them together. I can resolve unsd_nsd3 just fine within the unbound container. Here's the /etc/hosts in the unbound container:

172.17.0.6  a79a91df9ec5
127.0.0.1   localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
172.17.0.5  docker_nsd3 89a74b365c88 unsd_nsd3
172.17.0.5  unsd_nsd3 89a74b365c88

I've run out of ideas on how to move forward from here. Some help would be appreciated.

Lindenk
  • 143
  • 1
  • 4

1 Answers1

0

Unbound does not use /etc/hosts. Unbound can only resolve the stub-name unsd_nsd3 by forwarding upstream. You will need to setup local-zone and local-data to reflect the contents of your /hosts, or use an IP for the stub.

To ease migration, the source tarball has a perl script, contrib/build-unbound-localzone-from-hosts.pl that generates an include file. Local-zone name needs to be set inside the script prior to exec

pete
  • 693
  • 1
  • 7
  • 15
  • Ah, I see. I ended up writing a bash script to just insert the IP into `stub-addr` field at container start. I figured something similar would need to be done for the perl script anyway. Thanks. – Lindenk Dec 01 '15 at 17:47