[Pkg-dns-devel] Bug#808204: Bug#808204: [regression] unbound returns failures and IPv6 addresses on initial boot and after network outages

[Robert Edmonds]

Paul Wise wrote:
> After booting my system and after my wireless router is rebooted,
> unbound starts returning failures and IPv6 addresses. Neither are
> useful since I like to resolve addresses and don't have an IPv6 default
> route. I get the impression that it started from the upgrade from
> 1.4.22-3+b1 to 1.5.6-1. I'm using NetworkManager with dns=unbound and
> dnssec-trigger installed. Tollef mentioned seeing similar things.
> 
> Any thoughts about how to debug this?

Hi, Paul:

Can you clarify a bit?

"After booting my system and after my wireless router is rebooted"

Does this mean your system is booted and running, and resolving
normally, and then you reboot your router, which causes you to lose
Internet connectivity while the router is starting?

It sounds like you also see this problem after booting your system?

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?

"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.

Is this reliably reproducible?  E.g., can you cause it to happen at will
by just restarting your router?

This sounds very similar to #791659, but that was reported against
1.4.22-3.

I suspect you're running afoul of Unbound's aggressive server timeout
caching, which is described in some detail here:

    https://www.unbound.net/documentation/info_timeout.html

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.

> pabs at chianamo ~ $ sudo /usr/sbin/unbound-control list_forwards

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.

It also might be helpful to run "dig <well known domain name>" 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.)

> pabs at chianamo ~ $ sudo dnssec-trigger-control status
> at 2015-12-17 17:24:06
> authority 192.58.128.30: OK 
> no cache: no DNS servers have been supplied via DHCP
> state: auth secure
> pabs at chianamo ~ $ ip -6 r
> fe80::/64 dev wlan0  proto kernel  metric 256  pref medium
> pabs at chianamo ~ $ ip -6 a
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN 
>     inet6 ::1/128 scope host 
>        valid_lft forever preferred_lft forever
> 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
>     inet6 fe80::224:d7ff:fe80:a068/64 scope link 
>        valid_lft forever preferred_lft forever

-- 
Robert Edmonds
edmonds at debian.org