[Unbound-users] Stub with NS to stub doesn't work?
lists at rrod.net
Thu Feb 20 17:00:13 CET 2014
I spoke too early! The problem still does exist.
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
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
On 20 February 2014 10:31, J L <lists at rrod.net> wrote:
> 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,
> On 19 February 2014 11:51, W.C.A. Wijngaards <wouter at nlnetlabs.nl> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> 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,
>> 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>" stub-addr: 192.0.2.1 stub-zone: name:
>> > "z2.example.com <http://z2.example.com>" stub-addr: 192.0.2.2
>> > If I do a lookup of "foo.z1.example.com
>> > <http://foo.z1.example.com>" against 192.0.2.1; I get an NS record
>> > of "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> 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 <http://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.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> as the nameserver; but when looking up
>> > that name itself, it ignores the "stub-zone" for 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>, and asks them. They, however,
>> > are _external_ nameservers, and know nothing about 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> 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> 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
>> > _______________________________________________ Unbound-users
>> > mailing list Unbound-users at unbound.net
>> > http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>> -----END PGP SIGNATURE-----
>> Unbound-users mailing list
>> Unbound-users at unbound.net
> Jarrod Lowe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Unbound-users