[Unbound-users] 1.3: stub zones broken

[Michael Tokarev]

[Resending to list]

Paul Wouters wrote:
> On Thu, 23 Jul 2009, Michael Tokarev wrote:
> 
>> Here's the config:
>>
>> forward-zone:
>> name: "."
>> forward-addr: 192.168.2.18
>> forward-addr: 192.168.2.17
>>
>> stub-zone:
>> name: "tls.msk.ru"
>> stub-addr: 192.168.1.2
> 
> What happens if you add stub-prime: "no" to the last stub-zone entry?
> (I know it is the default, this is how I have mine zones configured)

Nothing changes.  I posted debug output since startup up to a first
query to this zone -- and the first thing it does after receiving
first query is to prime root (".") zone.  After doing this (on another
machine which do have access to outside 'net), it queries the correct
stub nameserver:

[1248334453] unbound[14868:0] info: priming successful for <. NS IN>
[1248334453] unbound[14868:0] debug: iterator[module 1] operate: extstate:module_wait_subquery event:module_event_pass
[1248334453] unbound[14868:0] info: iterator operate: query <paltus.tls.msk.ru. A IN>
[1248334453] unbound[14868:0] info: resolving (init part 2):  <paltus.tls.msk.ru. A IN>
...

So it looks like the problem is that it still tries to prime root
zone when (first) resolving a name in stub zone, even if that is
not necessary.  And this becomes a problem when unbound (1.3+, 1.2
did not have this issue) does not have access to outside world so
that it can't contact to any of the root nameservers.

2 questions:

1) why it tries to do root zone priming to start with, only with
  stub-zone (as stub-addr, not stub-name) names?

2) why it ignores forward root zone declaration when performing
  such priming?

I just tried to put (fake) root.hints pointing to another unbound
located on DMZ (192.168.2.17 in my original post), after which
priming goes ok and everything works.

Thanks!

/mjt