-----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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> 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 [email protected] > <mailto:[email protected]> >> http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users > > > _______________________________________________ Unbound-users > mailing list [email protected] > <mailto:[email protected]> > 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----- _______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
