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

Fri Feb 21 10:17:27 UTC 2014

-----BEGIN PGP SIGNED MESSAGE-----
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,
   Wouter

> 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:
>> 192.0.2.1 stub-zone: name: "z2.example.com
>> <http://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>
>> <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>
> <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
>> 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>
> <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>
> <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 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
> <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

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

iQIcBAEBAgAGBQJTBye3AAoJEJ9vHC1+BF+NVo4P+gPbLQBAwNUnzi4fGWYvHnQx
AZt4F0Q0Iuauk17bnZHkTJ3unyr1vOg0PJmI274xIyOlj81QMSzdGu9YwZQsJzuZ
NPeT64YLIuuHPBWcym10RydJtlkjOeJjaWevMh6eIpj7T5bU+y6xHwz6MSEvN875
SRXx+Tlolapc12zS7dfJsNIqC6LO6CO2gv/1U5I07S3WQKqR+UwW6BzAH2fNqFTq
sbz4tRUMBB484ZKfyGrrc/LhSZBhdNHONuBuXxqwKe7SZ5t0+gVFaXASyNWvMEaj
hhnAq+WFydCgxqK3HlpR/vDOZQEe5EdYAKnymfoPpjx8uIlcEEmG6XAqNbK3TAiw
vF1cHlJZRCHjAcqrXin6Gk25p27QY/QtQkezsZl89wf0/2UnkV9EME7M3IgfSw1d
D68U1ZymlRwGxcc+2Iwu6DiA+ai80N7H3z+KJS/ghb+VjYHvxYcSg8BcPITDeAOV
LA+GuaXGrdr1AMvuATMa1R/XB0pczeO6BMYej6YC6YMDAvjScu1AKtKa5Z1ubElM
PMibofjZ/9DygQkpn2FKSx2STgpyC0tqe8Uv9aTqo2Ka96W/GiO9rfTAsDPkBSCX
gnlq6NoqAe/V4x3KnLpXPFo8FLKtbnu5TWeJa6hPpfbXavN7g2yKiiQK7bay3gl1
FUObe713m+oHu1BrsZNo
=wpKp
-----END PGP SIGNATURE-----