[Unbound-users] 1.3: stub zones broken
wouter at NLnetLabs.nl
Thu Jul 23 09:05:25 UTC 2009
-----BEGIN PGP SIGNED MESSAGE-----
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
>  unbound[19620:0] info: priming . IN NS
>  unbound[19620:0] info: sending query: <. NS IN>
>  unbound[19620:0] debug: sending to target: <.> 184.108.40.206#53
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
> (paltus.tls.msk.ru) 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 127.0.0.1
(or better, to 192.168.2.18). Here is how:
> Here's the config:
# Keep this one to do the work.
# Keep this one too.
# Avoid your root-priming but external
# network not accessible problem.
# i.e. this is similar to providing root-hints: "nowhere"
> 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,
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
More information about the Unbound-users