Paul Wise wrote: > 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.
Ah, OK. How do you bring up the wireless connection on your laptop? NetworkManager, etc.? Any difference if you try a wired connection instead? (If your laptop has a wired Ethernet port.) > > 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. That's odd, but I guess wget doesn't display an IP address at all when a DNS query SERVFAILs, and I could easily see how an AAAA could be cached while the A isn't. > > 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. Can you try downgrading to 1.4.22-3 and see if it reliably behaves as expected when you reboot your laptop and router? If you can make 1.4.22 fail, then I suspect #791659 and this bug are the same, but if not, it might be an upstream bug. > > 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. Yes, of course, but the parameter is specified in seconds, not minutes, so "infra-host-ttl: 5" should cause the entries in the infra cache to expire after 5 seconds :-) > 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. I'm not that familiar with dnssec-trigger, but it might be because dnssec-trigger feeds DNS nameserver information to unbound dynamically with "unbound-control forward ...", and if you restarted Unbound since the last time dnssec-trigger did that, Unbound would start up without a list of forwarders? -- Robert Edmonds edmo...@debian.org