-----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-----