[Unbound-users] 1.3: stub zones broken

[W.C.A. Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
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: <.> 193.0.14.129#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.
forward-zone:
  name: "."
  forward-addr: 192.168.2.18
  forward-addr: 192.168.2.17

# Keep this one too.
stub-zone:
  name: "tls.msk.ru"
  stub-addr: 192.168.1.2

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


> 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,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkpoJ9UACgkQkDLqNwOhpPj/TACdG6IK/0rwXzffb8P9IiR0N2Tm
I70An1KBHzzDuUzUUN9OIMR4VuOB9C/u
=jXUc
-----END PGP SIGNATURE-----