On Sun, Jul 27, 2014 at 12:27:54PM +0200, Sebastian Reitenbach wrote: > > > > My understanding is that "transparent" is used when you want to override > > certain records in a zone with local-data configured in unbound.conf. > > Given that you have no such things in the pasted configuration > > "nodefault" is probably a better choice. > >
Disregard the above, using "transparent" as Chris suggested is the way to go when only unlocking part of a RFC1918 reverse zone. > > In unbound, I only had the 10.in-addr.arpa and in nsd I have > 0.0.10.in-addr.arpa. > I only had to change unbound configuration as suggested, which up to now > seems to work reliable. > Yeah, when the zone names match in both unbound and nsd i have seen no problems either. > And when you restart unbound, then dig for 10.0.0.2 might start working, > and digging others may fail. IIRC, after a restart, the first one or two > reverse > records I looked up, then worked as expected, others then started to fail, > that worked before. Only very seldomly, all reverse lookups worked > after a restart of unbound. > To be clear, the order of the records did not matter, but the pattern was always the same: the first lookup after unbound started would work, the second would end up at IANA and and following lookups would work again. My current theory is that it is caching related, so im guessing if you had this running for a while the issue could "walk around" as the cache expired etc. But I am still unsure if this is actually a bug or if it is just "undefined behaviour from doing silly things with stub-zones". The silly thing being telling unbound the server was authorative for a zone that was actually outside the zone apex of the authorative data. Regards, Patrik Lundin
