On Thu, 2015-12-17 at 16:18 -0500, Robert Edmonds wrote: > "After booting my system and after my wireless router is rebooted"
There are two scenarios when this happens: When I reboot my laptop, the issue happens after it has started up and connected to the wireless connection. When I reboot my router, the issue happens after my laptop has reconnected to the wireless connection. > What actions if any do you take to fix the problem (restarting the > daemon?), or does it clear up by itself after, say, 15 minutes? Restarting the daemon works, haven't tried waiting that long. > "unbound starts returning failures and IPv6 addresses." > > What do you mean by returning IPv6 addresses? Unbound is a DNS server, > so it will return AAAA records, if asked. It's up to the DNS client to > not ask AAAA records if they're not needed. For example, wget normally prints both IPv4 and IPv6 addresses for domains with both A and AAAA, but after the reconnection, it only prints IPv6 addresses or can't resolve at all, depending on the domain. > Is this reliably reproducible? E.g., can you cause it to happen at will > by just restarting your router? Yes. > This sounds very similar to #791659, but that was reported against > 1.4.22-3. I didn't have the issues with that version, which is why I didn't reply to that one. I think that flushing all failures from the cache after a reconnection should do it. I'll try a `flush_infra all` next time. > The default "infra-host-ttl" setting is 900 seconds (15 minutes). I > wonder if you lower this aggressively (e.g. "infra-host-ttl: 5"), if > Unbound would recover more quickly. Even 5 minutes would be too long to wait TBH. > Try "unbound-control forward" too. "journalctl -u unbound" might be > helpful too, but if the problem is related to Unbound's infra cache, I > wouldn't expect to see anything logged by Unbound, at the default log > level. pabs@chianamo ~ $ sudo /usr/sbin/unbound-control forward off (using root hints) It is strange I'm not using forwarding, because the router definitely returns DNS info in DHCP replies. Maybe dnssec-trigger is breaking it. > It also might be helpful to run "dig " e.g. "dig > www.google.com" or "dig www.debian.org", etc. when the problem occurs, > to confirm that Unbound is sending "SERVFAIL" responses. (dig is in the > dnsutils package.) Yeah, I confirmed this several times. -- bye, pabs https://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part