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 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]> 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]> 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, >> 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>" 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 [email protected] >> > http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users >> > >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1 >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iQIcBAEBAgAGBQJTBJraAAoJEJ9vHC1+BF+NxycP/3LfomX5jxGnS/aQHb3WmAoy >> sMXGwUwmacGkwlaPYywnq5T7SVTToD3RFha2pO35ojjjlpvwMyDSKKkf1mecypIX >> 45Bj0r+LHZykogwiIVs9eTJ+EZiwufF407wJLAWeYwCvNfoEpIls8h3tW2L/4YRC >> zxsA8mk6YSg3r0ESntIBkVSYhO2iel9PYDMTdAog7eFMX+oXzUJ0xpCMCv7FSoc/ >> +oTWP8Hn0JOELSmvplYQtz6h2e0yDV+L3Mp6C+isCR4Ssr+c/RNm9lcNi2EuU03l >> bDYo2Unrb8dCd2kTBchmj4qSjbqZWwLkx5IvwGSqdIHeHp1gigUlxlBtcyuJUDoW >> tuX/FOEnQEaw2oLmf7M72KVNFcffi2N58Fytit6tfj7lkUZ3UWcAtg2rGGpRBmo4 >> j8IagpQsWnS9MISuPiawOtQHKMa8IjVMa17I3tBDyR/UclY1LLo2vcCGKIdrJrf+ >> eUVnD4/9qFMoXFZmERuHxUdq5pBMl9ngUfL/vyc4DDnz7qPFLWYxO5oI/PAg0zW2 >> KiXqbPCakfzgHqQyJUFaYjbcqLnS3BlJf3ax2ev0krZD0RijFxtu1qE3vTL1OLtD >> Bpdk/9m9WaDNpNdNlyRl8qHmFMlfxqdkq4QslzMPCXb+pbnqLvZGIPrWobjqRI01 >> zRD99NLASNxKhurA4yrg >> =RbxU >> -----END PGP SIGNATURE----- >> _______________________________________________ >> Unbound-users mailing list >> [email protected] >> http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users >> > > > > -- > Jarrod Lowe > -- Jarrod Lowe
_______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
