Unbound answering SERVFAIL

Unbound
1

Hello,

I’m currently doing some testing on DNS. Thus my configuration is perhaps singular.

I’ve an authoritative server set-up and working. This server zone is called “test.”.
I’ve tried to set up a caching server on another server with Unbound 1.2.1.
This two servers are connected each other through a crossover cable and not connected to the Internet.

When I try to do a dig from a client (directly connected to the caching server and not connected to the Internet) I get a SERVFAIL back. I must say that with BIND instead of Unbound and without any other changes to the configuration it was fully working.

To have a better understanding of following files:

  • 192.168.1.1 is the client
  • 192.168.1.2 is the caching server on the client side
  • 192.168.2.1 is the caching server on the authoritative server side
  • 192.168.2.2 is the authoritative server

Content of unbound.conf:

server:
root-hints: “/root/conf/cache/db.root”
do-ip6: no
username: “”
verbosity: 3
logfile: “”
chroot: “”
module-config: “iterator”
access-control: 0.0.0.0/0 allow
port: 53
interface: 192.168.1.2
interface: 192.168.3.2
outgoing-interface: 192.168.2.1

Content of db.root:

ns.test. 36000 A 192.168.2.2
. 36000 NS ns.test.

Log from Unbound (the request was “dig @192.168.1.2 test1.test. A”)

station24:~# unbound -c /etc/unbound.conf -d
[1237215220] unbound[2605:0] debug: chdir to /usr/local/etc/unbound
[1237215220] unbound[2605:0] debug: switching log to stderr
[1237215220] unbound[2605:0] debug: module config: “iterator”
[1237215220] unbound[2605:0] notice: init module 0: iterator
[1237215220] unbound[2605:0] debug: target fetch policy for level 0 is 3
[1237215220] unbound[2605:0] debug: target fetch policy for level 1 is 2
[1237215220] unbound[2605:0] debug: target fetch policy for level 2 is 1
[1237215220] unbound[2605:0] debug: target fetch policy for level 3 is 0
[1237215220] unbound[2605:0] debug: target fetch policy for level 4 is 0
[1237215220] unbound[2605:0] debug: Reading root hints from /root/conf/cache/db.root
[1237215220] unbound[2605:0] info: DelegationPoint<.>: 1 names (1 missing), 0 addrs (0 result, 0 avail)
[1237215220] unbound[2605:0] debug: cache memory msg=33040 rrset=33040 infra=1312 val=0
[1237215220] unbound[2605:0] info: start of service (unbound 1.2.1).
[1237215271] unbound[2605:0] debug: iterator[module 0] operate: extstate:module_state_initial event:module_event_new
[1237215271] unbound[2605:0] info: resolving <test1.test. A IN>
[1237215271] unbound[2605:0] info: priming . IN NS
[1237215271] unbound[2605:0] debug: iterator[module 0] operate: extstate:module_state_initial event:module_event_pass
[1237215271] unbound[2605:0] info: iterator operate: query <. NS IN>
[1237215271] unbound[2605:0] info: processQueryTargets: <. NS IN>
[1237215271] unbound[2605:0] info: new target <ns.test. A IN>
[1237215271] unbound[2605:0] debug: iterator[module 0] operate: extstate:module_state_initial event:module_event_pass
[1237215271] unbound[2605:0] info: iterator operate: query <ns.test. A IN>
[1237215271] unbound[2605:0] info: resolving <ns.test. A IN>
[1237215271] unbound[2605:0] info: priming . IN NS
[1237215271] unbound[2605:0] info: cycle detected <. NS IN>
[1237215271] unbound[2605:0] debug: return error response REFUSED
[1237215271] unbound[2605:0] debug: iterator[module 0] operate: extstate:module_wait_subquery event:module_event_pass
[1237215271] unbound[2605:0] info: iterator operate: query <. NS IN>
[1237215271] unbound[2605:0] info: processQueryTargets: <. NS IN>
[1237215271] unbound[2605:0] debug: out of query targets – returning SERVFAIL
[1237215271] unbound[2605:0] debug: return error response SERVFAIL
[1237215271] unbound[2605:0] debug: iterator[module 0] operate: extstate:module_wait_subquery event:module_event_pass
[1237215271] unbound[2605:0] info: iterator operate: query <test1.test. A IN>
[1237215271] unbound[2605:0] info: processQueryTargets: <test1.test. A IN>
[1237215271] unbound[2605:0] debug: Failed to get a delegation, giving up
[1237215271] unbound[2605:0] debug: return error response SERVFAIL
[1237215271] unbound[2605:0] debug: cache memory msg=33141 rrset=33040 infra=1312 val=0

2

Hi Cédric,

does 192.168.2.2 serve . zone?

Ondrej

3

2009/3/16 Ondřej Surý <ondrej@sury.org>

Hi Cédric,

Hi,

does 192.168.2.2 serve . zone?

No it does not. But (I’ll double check) I’m not sure Unbound try to contact the authoritative server.
Also it was working fine with BIND. Do they have a different behavior on that point ?

Thanks,

Cédric

4

Hi Cédric,

Hi,

does 192.168.2.2 serve . zone?

No it does not. But (I'll double check) I'm not sure Unbound try to contact
the authoritative server.

According to the logfile Unbound is trying to prime root servers. And you
specified servers for . in your db.root file and not servers for test, so you
need to have full delegation path from '.' to your test zone.

Also it was working fine with BIND. Do they have a different behavior on
that point ?

It's very much possible.

Ondrej

5

Hi,

Ondřej Surý wrote:

Hi Cédric,

Hi,

does 192.168.2.2 serve . zone?

No it does not. But (I'll double check) I'm not sure Unbound try to contact
the authoritative server.

According to the logfile Unbound is trying to prime root servers. And you
specified servers for . in your db.root file and not servers for test, so you
need to have full delegation path from '.' to your test zone.

Also it was working fine with BIND. Do they have a different behavior on
that point ?

It's very much possible.

Yes, that is correct. It seems like BIND is using the safety belt
(RFC1034) when priming fails, where unbound gives up when root priming
fails.

I think what you want is a stub-zone setup; here you can avoid your
priming trouble:

stub-zone:
  name: "."
  stub-addr: 192.168.2.2
  stub-prime: no

This is basically the same as the root-hints you have, but the
stub-prime: no setting makes it skip the priming step that is failing now.

Best regards,
   Wouter

6

Thanks to both of you. With a stub-zone instead of a root-hints AND my authoritative server serving the root, it’s working.

Thanks,

Cédric