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

W.C.A. Wijngaards wouter at nlnetlabs.nl
Fri Feb 21 10:17:27 UTC 2014

Hash: SHA1

Hi Jarrod,

On 02/20/2014 05:00 PM, J L wrote:
> I spoke too early! The problem still does exist.

You give a very detailed description, but according to the changes I
made it should not really go wrong ...  Can you provide logfiles when
it goes wrong?

Do you have forwards configured for that name and also stubs?
stub-prime is set to no, right?

What server it is using and the response to a query of type NS can be
different.  I would like to have a logfile (verbosity 4 or so).
Unbound-control lookup <zonename> should also print interesting
information what unbound thinks about the NSes for that zone.

Best regards,

> It is when unbound: * is asked for something in a domain it has a
> stub-zone for, and * the response it gets back is a set of NS's,
> and * the NS hostnames are in a stub-zone, and * the resolution of
> all the NS hostnames via the stub-addr's returns NX
> Then unbound will ask the root, and follow that chain. As the
> sub-domain I using is private, when it gets to the "true"
> authoratative nameserver on the Internet, it returns NX.
> This is a problem for me, because the "inside" NX has a nice low
> TTL; but the "outside" NX has a very high TTL. This means that if
> all the NS hostnames don't exist at that point in time (pretty
> common in my case; it is banks of test systems) then it takes a
> long time to recover once the NS hostnames appear.
> If you ask unbound directly for an NS hostname (while it does not
> have a cached NX) then it behaves correctly (it believes the
> stub-addrs).
> I'm not sure where to go from here. Does anyone have any idea what
> is going wrong, or any suggestions of a workaround?
> Unbound 1.4.21 on CentOS 6.4
> Thanks, -- Jarrod
> On 20 February 2014 10:31, J L <lists at rrod.net
> <mailto:lists at rrod.net>> wrote:
> Thanks!
> Upgrading to that version got me past that problem - and straight 
> into the next one. However, the next problem was to do with the 
> config of one of the other DNS servers.
> I appreciate your help, -- Jarrod
> On 19 February 2014 11:51, W.C.A. Wijngaards <wouter at nlnetlabs.nl 
> <mailto:wouter at nlnetlabs.nl>> wrote:
> Hi J L,
> 1.4.21 has a fix for stubs and NS records from the internet (Fix 
> queries leaking up for stubs and forwards, if the configured 
> nameservers all fail to answer.)  Can you see if that fixes your 
> problems, they look sort-of similar.
> Best regards, Wouter
> On 02/19/2014 11:31 AM, J L wrote:
>> 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
>> <http://z1.example.com> <http://z1.example.com>" stub-addr:
>> stub-zone: name: "z2.example.com
>> <http://z2.example.com>
> <http://z2.example.com>" stub-addr:
>> If I do a lookup of "foo.z1.example.com
> <http://foo.z1.example.com>
>> <http://foo.z1.example.com>" against; I get an NS
>> record of "dns.z2.example.com <http://dns.z2.example.com>
> <http://dns.z2.example.com>". If I do an NS
>> lookup against unbound, I get the same thing.
>> If I lookup dns.z2.example.com <http://dns.z2.example.com>
> <http://dns.z2.example.com> against
>>, I get an A record of If I do this lookup 
>> against unbound, I get the same thing.
>> If I lookup host1.z1.example.com <http://host1.z1.example.com>
> <http://host1.z1.example.com>
>> against; I get the correct A record.
>> However, if I try to do all this in one go - lookup 
>> host.z1.example.com <http://host.z1.example.com>
> <http://host.z1.example.com> against unbound -
>> it doesn't work. What appears to happen is that unbound
>> correctly determines that it should use dns.z2.example.com
> <http://dns.z2.example.com>
>> <http://dns.z2.example.com> as the nameserver; but when looking
>> up that name itself, it ignores the "stub-zone" for
> z2.example.com <http://z2.example.com>
>> <http://z2.example.com>, and follows the normal DNS chain -
>> which means it goes out to the Internet, finds the nameservers
>> for example.com <http://example.com> <http://example.com>, and
> asks them. They, however,
>> are _external_ nameservers, and know nothing about
> z2.example.com <http://z2.example.com>
>> <http://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 <http://dns.z2.example.com>
> <http://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 <http://dns.z2.example.com>
> <http://dns.z2.example.com> itself (because it
>> just got that NS record from 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
>> _______________________________________________ Unbound-users 
>> mailing list Unbound-users at unbound.net
> <mailto:Unbound-users at unbound.net>
>> http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
> _______________________________________________ Unbound-users
> mailing list Unbound-users at unbound.net
> <mailto:Unbound-users at unbound.net> 
> http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
> -- Jarrod Lowe
> -- Jarrod Lowe

Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/


More information about the Unbound-users mailing list