Unbound fails to stub-zone to localhost

Unbound
1

Hi,

I am trying to get unbound, bound to eth0, to forward queries for
local zones to nsd running on 127.0.0.1.

nsd works authoritatively, I have verified this with dig.

Also, when I use pdns-recursor to forward to nsd, it all works.

However, with unbound, I get SERVFAIL from unbound, which reports:

  unbound: [1269:0] info: processQueryTargets: <local.zone. NS IN>
  unbound: [1269:0] debug: out of query targets -- returning SERVFAIL

in the logs. My configuration is as follows. What could be the
problem?

  server:
    verbosity: 1
    interface: 192.168.14.1
    cache-max-ttl: 1800
    access-control: 0.0.0.0/0 refuse
    access-control: 127.0.0.0/8 allow
    access-control: 192.168.14.0/24 allow
    chroot: ""
    do-not-query-localhost: no
  stub-zone:
    name: "local.zone"
    stub-addr: 127.0.0.1

I have tried

(a) forward-zone for local.zone and .
(b) stub-zone for local.zone and forward-zone for .
(c) only stub-zone for local.zone and root-hints for .
(d) only forward-zone for local.zone and root-hints for .
(e)/(f) like (c)/(d) without explicit root-hints

but in none of these cases could I make it work.

Any clues?

2

I ran into this before and found out that using 127.0.0.0/8 will not
work. I assigned 10.0.0.1 as a virtual address on eth0 and that did the
trick. I then set my rbldnsd daemon to listen on 10.0.0.1

In unbound.conf I have

forward-zone:
        name: "blacklist.rbl"
        forward-addr: 10.0.0.1

Obviously, your context is different but the general rule applies.
Unbound will not query forward zones on 127.0.0.0. Use another IP
address. Either the public IP of the host NSD is running on, or a
RFC1918 address.

Hope this helps,

Patrick Vande Walle

martin f krafft wrote:

3

Hi Martin,

What is the NS RRset of local.zone ?
dig @127.0.0.1 local.zone NS
Unbound will send to the servers named in the NS set in preference to
the configured 127.0.0.1. From the below, it could be that the NS set
is either empty or 192.168.14.1 for example.

This may help you. In svn trunk I recently fixed unbound so that you can
run with stub-addr: 127.0.0.1@10053 with NSD running on port 10053 on
localhost. When you use the '@' for port notation (in the svn trunk
version) the NS record set is not used in preference.

option (d) should have worked, I think. Maybe there is something else
amiss. If this doesn't work, tell me what unbound says when verbosity:
4 is set.

Best regards,
   Wouter

martin f krafft wrote:

4

also sprach Patrick Vande Walle <patrick@vande-walle.eu> [2008.10.01.1519 +0200]:

Unbound will not query forward zones on 127.0.0.0. Use another IP
address. Either the public IP of the host NSD is running on, or a
RFC1918 address.

Even with do-not-query-localhost and do-not-query and
do-not-query-address set properly? Why not?

5

also sprach W.C.A. Wijngaards <wouter@NLnetLabs.nl> [2008.10.01.1528 +0200]:

Unbound will send to the servers named in the NS set in preference to
the configured 127.0.0.1. From the below, it could be that the NS set
is either empty or 192.168.14.1 for example.

It was empty. Good spot. Setting it properly made the whole thing
work.

This is a bit unfortunate, since now my clients are told that
ns.local.zone is 127.0.0.1, which is just wrong.

This may help you. In svn trunk I recently fixed unbound so that
you can run with stub-addr: 127.0.0.1@10053 with NSD running on
port 10053 on localhost. When you use the '@' for port notation
(in the svn trunk version) the NS record set is not used in
preference.

I am looking forward to this appearing in a stable release.

Thanks!

6

also sprach W.C.A. Wijngaards <wouter@NLnetLabs.nl> [2008.10.01.1528 +0200]:

Unbound will send to the servers named in the NS set in preference to
the configured 127.0.0.1.

Why does it do this? What's the design decision? It seems wrong to
have unbound redirect queries for a zone to e.g. localhost, then ask
localhost for the zone's NS record, resolve that, and then direct
all other queries there instead, effectively ignoring the explicit
redirect/stub/forward instruction.

This may help you. In svn trunk I recently fixed unbound so that
you can run with stub-addr: 127.0.0.1@10053 with NSD running on
port 10053 on localhost. When you use the '@' for port notation
(in the svn trunk version) the NS record set is not used in
preference.

This feels like a hack to me. Shouldn't it possibly be the other way
around? By default, ignore the NS set (or at least don't require
it), unless a special flag is set to make it recurse NS records and
forward queries to the NS configured in the zone?

Cheers,

7

also sprach W.C.A. Wijngaards <wouter@NLnetLabs.nl> [2008.10.01.1528 +0200]:

Unbound will send to the servers named in the NS set in preference to
the configured 127.0.0.1.

Why does it do this? What's the design decision? It seems wrong to
have unbound redirect queries for a zone to e.g. localhost, then ask
localhost for the zone's NS record, resolve that, and then direct
all other queries there instead, effectively ignoring the explicit
redirect/stub/forward instruction.

I assume this conversation was about stub zones, as forward zones would redirect queries to the address you configured.

I expect that the behavior of the stub zone feature is my fault. I made stub zones work, basically, like they worked in BIND. That is, the stub zone would use the values of the NS rrset on the configured server (for the zone in question) to resolve queries. I recall several reasons for implementing it this way:

1) for better or worse, it was how stub zones worked in the only implementation that I had access to, BIND, and I figured that this is how anyone who had used stub zones before would expect them to work,

2) I thought that there might be some operational reason why stub zones should work this way, even though I didn't know what it was, and

3) the design fit fairly well in to the algorithm. That is, it didn't create a special, TTL-less, artifical NS rrset in the cache.

This may help you. In svn trunk I recently fixed unbound so that
you can run with stub-addr: 127.0.0.1@10053 with NSD running on
port 10053 on localhost. When you use the '@' for port notation
(in the svn trunk version) the NS record set is not used in
preference.

This feels like a hack to me. Shouldn't it possibly be the other way
around? By default, ignore the NS set (or at least don't require
it), unless a special flag is set to make it recurse NS records and
forward queries to the NS configured in the zone?

In retrospect, I agree with this. It is more natural for stub zones to always resolve via the configured addresses. I think changing the default behavior will make stub zones easier to understand and easier to use.

8

also sprach David Blacka <davidb@verisign.com> [2008.10.21.1540 +0200]:

I assume this conversation was about stub zones, as forward zones
would redirect queries to the address you configured.

Yes, stub-zones.

In retrospect, I agree with this. It is more natural for stub
zones to always resolve via the configured addresses. I think
changing the default behavior will make stub zones easier to
understand and easier to use.

Awesome! I am looking forward to that! Can we track this somehow, or
could you simply Cc 502973@bugs.debian.org with any updates, if
that's not asking too much?

9

martin f krafft wrote:

also sprach David Blacka <davidb@verisign.com> [2008.10.21.1540 +0200]:

I assume this conversation was about stub zones, as forward zones
would redirect queries to the address you configured.

Yes, stub-zones.

In retrospect, I agree with this. It is more natural for stub
zones to always resolve via the configured addresses. I think
changing the default behavior will make stub zones easier to
understand and easier to use.

Awesome! I am looking forward to that! Can we track this somehow, or
could you simply Cc 502973@bugs.debian.org with any updates, if

cc-ed.

So, fixed that, there is now (yet another) option to control this.
By default it is turned off for stub-zone and turned on for root-hints.
You can set stub-prime: yes if you want the prime the stub just like
the root is primed with hints.

Svn r1319 contains the fix.

Best regards,
   Wouter

10

also sprach W.C.A. Wijngaards <wouter@NLnetLabs.nl> [2008.10.22.1407 +0200]:

So, fixed that, there is now (yet another) option to control this.

Awesome, and thanks a lot also for notifying the Debian bug report.
I hope I (or Debian) will be able to give back this level of support
to you and the community!