Maintained by: NLnet Labs

[Unbound-users] 1.3: stub zones broken

W.C.A. Wijngaards
Thu Jul 23 11:05:25 CEST 2009

Hash: SHA1

Hi Michael,

On 07/22/2009 11:47 PM, Michael Tokarev wrote:
> Sort of a followup to my previous email about this matter.
> Here's an example of debug output on one of my machines.
> Querying a 'stub zone' which gets forwarded to a nearby
> nsd, while "." is declared as a forward zone to another
> unbound server (in DMZ).
> # ./unbound-1.3.2 -dvv
> [1248298055] unbound[19620:0] info: priming . IN NS
> [1248298056] unbound[19620:0] info: sending query: <. NS IN>
> [1248298056] unbound[19620:0] debug: sending to target: <.>

What you see here is that unbound is trying to prime the root
servers before continuing.  Even though it has a more specific stub
anchor, it wants to prime the root first.  If that succeeds, it
will then send this query towards your configured stub anchor.

> This is an internal machine which does not have access to external network,
> so none of the queries will succeed.  Especially for names like this
> ( which does not exist externally.

So, it cannot access the root, but it still has root-hints there.
When it starts it will attempt to prime the root.
(Prime the root: contact the root servers to get the latest up
to date root-hints, using the root-hints from configuration).

But your machine is internal and cannot access it, so it fails.
Hm.  The easiest way would be to provide root-hints to
(or better, to  Here is how:

> Here's the config:

# Keep this one to do the work.
  name: "."

# Keep this one too.
  name: ""

# Avoid your root-priming but external
# network not accessible problem.
# i.e. this is similar to providing root-hints: "nowhere"
  name: "."
  stub-prime: no

> The same is hapenning with 1.3.1.  1.3.0 works, but not correctly:

Yes after your last report I fixed the bug in 1.3.1 :-)

> Changing "stub-zone" and "stub-addr" to "forward-zone" and "forward-addr"
> fixes both cases.

Yes this affects unbounds decision to prime the root server.

> In my previous emails I were referring to forward zones instead - and
> was wrong.  Only stub zones does not work, forward zones seems to be
> working correctly.

Above workaround should work, thanks for the report,

Best regards,
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora -