[Unbound-users] Stub with NS to stub doesn't work?

[J L]

Hi,

I have an odd problem; that I can't figure out how to get around.

Short version: If unbound decides it needs to look up a name that it got as
an NS record, it ignores stub-zones when figuring out where to talk to.


Long version:
I have, in my unbound configuration on my core office resolver:
  stub-zone:
    name: "z1.example.com"
    stub-addr: 192.0.2.1
  stub-zone:
    name: "z2.example.com"
    stub-addr: 192.0.2.2


If I do a lookup of "foo.z1.example.com" against 192.0.2.1; I get an NS
record of "dns.z2.example.com". If I do an NS lookup against unbound, I get
the same thing.

If I lookup dns.z2.example.com against 192.0.2.2, I get an A record of
192.0.2.3. If I do this lookup against unbound, I get the same thing.

If I lookup host1.z1.example.com against 192.0.2.3; I get the correct A
record.

However, if I try to do all this in one go - lookup
host.z1.example.comagainst unbound - it doesn't work. What appears to
happen is that unbound
correctly determines that it should use dns.z2.example.com as the
nameserver; but when looking up that name itself, it ignores the
"stub-zone" for z2.example.com, and follows the normal DNS chain - which
means it goes out to the Internet, finds the nameservers for example.com,
and asks them. They, however, are _external_ nameservers, and know nothing
about z2.example.com - so they say "no", and unbound then caches that no.

This doesn't always happen - as best I can figure, if the name
dns.z2.example.com gets looked up by something outside the unbound box
first (i.e. manually) while there is no cached entry, then the stub-zone
will be taken into account, and the response cached. Then, when unbound
wants to look up dns.z2.example.com itself (because it just got that NS
record from 192.0.2.1) it uses the cached entry and all is fine - until, of
course, the record expires.



Does anyone have an idea of how I can convince unbound to use the stub-zone
even for its own lookups?

Unbound 1.4.19 on CentOS 6.4.


Thanks,
-- 
Jarrod Lowe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20140219/d8debd1c/attachment.htm>