Stub with NS to stub doesn't work?

Unbound
1

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”
stub-addr: 192.0.2.1
stub-zone:
name: “z2.example.com”
stub-addr: 192.0.2.2

If I do a lookup of “foo.z1.example.com” against 192.0.2.1; I get an NS record of “dns.z2.example.com”. If I do an NS lookup against unbound, I get the same thing.

If I lookup 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 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 against unbound - it doesn’t work. What appears to happen is that unbound correctly determines that it should use dns.z2.example.com as the nameserver; but when looking up that name itself, it ignores the “stub-zone” for z2.example.com, and follows the normal DNS chain - which means it goes out to the Internet, finds the nameservers for example.com, and asks them. They, however, are external nameservers, and know nothing about 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 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 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,

2

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

3

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,

4

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,

5

Hi Jarrod,

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