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

Thu Feb 20 16:00:13 UTC 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
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> 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> 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 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/
>>
>> 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
>> Unbound-users at unbound.net
>> http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
>>
>
>
>
> --
> Jarrod Lowe
>

-- 
Jarrod Lowe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20140220/c26914b4/attachment.htm>