Following up on this thread given the mention it got in the recent unbound question:
On Sat, May 17, 2014 at 08:04:32PM +0200, Sebastian Reitenbach wrote: > > # the stub zones I want to resolve via nsd on localhost > stub-zone: > name: "ds9" > stub-addr: 127.0.0.1@5353 > > stub-zone: > name: "10.in-addr.arpa." > stub-addr: 127.0.0.1@5353 > My first reaction was that the first zone had no terminating "." while the in-addr.arpa one had it. Not sure this makes a difference, just thought i should point it out. > > However, after a reboot of the box, reverse lookup > of any of the configured 10.0.0.X addresses fails. When I > restart unbound, then it just works as expected. > This indeed looks strange, could you retry this using dig(1) instead of nslookup? I am not comfortable with that tool and it's use is discouraged because it can end up doing funky things (see http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/nslookup-flaws.html). > > I have about 30 hosts in that reverse zone configured. The more > often I restart unbound, the better it gets with returning results. > > However, when I reboot the machine, then other lookups that > worked before might fail, and vice versa, others may work, I cannot > see a pattern. > I agree this sounds very strange. > Looking at the unbound logs, I see a large amounts of trying > to connect to NSD, and it also gets answers of type THROWAWAY, > until unbound then decides to ask the root servers. > Could you share some of those logs? Using ktrace(1) might also be useful for investigating what is going on (difference in working and not working lookup for example). > Is maybe my box (soekris net5501) too slow, so that NSD doesn't answer fast > enough? Then, after some restarts of unbound, and queries to NSD, then > NSD has all in memory and then it just works? But then I don't understand > why it works without flaws for the forward zone, and also the IPv6 zone? > Seems far fetched to me. Regards, Patrik Lundin
