Unbound and intermittent network connectivity?

[W.C.A. Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Robert,

On 18/12/15 20:05, Robert Edmonds via Unbound-users wrote:
> Hi,
> 
> I have a few recent bug reports from Debian users that Unbound
> stops resolving after brief interruptions in network connectivity.
> Especially from users on laptops, which are typically not as
> well-connected as servers or workstations with wired Ethernet
> connections.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791659
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808204
> 
> A few questions:
> 
> Is my guess that Unbound stores unreachability information for 
> particular nameservers in the "infra cache" correct?  Does this
> also apply to forwarders?  Does that mean if a user is running
> Unbound in forwarding mode and has a brief network outage, they
> have to wait until an "infra-host-ttl" expiration (default 15
> minutes) occurs before resolution service works again?

Yes it applies to forwarders.

> 
> Is the format of the "dump_infra" output documented anywhere?
> I've started reading source code to figure it out, but it would be
> nice to have some "this is good" and "this is bad" examples.  E.g.,
> at first glance I misread "lame dnssec 0" to mean "this server is
> lame, and does not support DNSSEC", which appears to be the
> opposite of what it means :-)

It is not documented.  It also changed between versions of unbound as
the internal cache contents contains different values.
daemon/remote.c:dump_infra_host() has the print statement.  The ping
value is the interesting "how may millisecond" value.  Values of
120000 indicate unbound thinks it is unreachable.

> 
> Should distros be doing something on network change events to get 
> Unbound to purge unreachability information?  I think "flush_infra
> all" would do it, but isn't this quite disruptive?  (Maybe
> unreachability information could be cached with a different TTL
> than the other attributes for entries in the infra cache?)

Yes that is a good idea.  It is not disruptive.  (it could be
disruptive for a high-load server, that is now going to probe distant
servers that are experiencing a high packet rate).

> 
> Should distros lower "infra-host-ttl" in general, or for laptop
> users in particular?

I would distinguish between end-hosts and recursive-servers.

> 
> How should we deal with brief interruptions in network connectivity
> past the first hop (say, outage inside the ISP backbone) that don't
> trigger events?

That is what the TTL is for.

Best regards, Wouter

> 
> Thanks!
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWijtmAAoJEJ9vHC1+BF+NwJEP/ihvkpRHU6Rhe87XVXx0uIW4
x3glcNEuL/rp9+3kI+Z1UERDuiKnLoTdf3dYpHcGPdJQFHJEbrsqwdMMT4822T5L
1ghOcH797oGJjzEuF7NdnilIXHxT/DQL6kx42lC8Ogdhi1bB9FUmgIDOqEE9qmVf
022mbaXcPxtNQJZFFVz4vjpW1KMeTZo4fchTewe5G9BprxynwRK1ZZ5gBcK1P+re
UT/f+FtOiu8bpmVBzX+glyK/tee65WhQZFytuzaTneEINn0ZwvQJLpxaatRDI5s6
W+w/YVpEKh+ukUO/SpWQZHtVSrhl0gWcBE1g+ST4B25BHuwmrVnDlyyuRViWPZyw
++WxVTrTX3Omm3U6VAm++/X5Pt/0xcFamNh0WJDegrROJTQzTNIKPoAvrqZFHAbp
4wmzQKAiBmafdWxLl6ePVphu31LJnXBxidZCgEsATAGmZamOs4q0m6EzVFYFVQYd
uMYJFTYwtjiZ3xAHQFbxgncEBV5nfkEEAD4pdAlEVWTi2tNRAF+vptkc/qfP2yjN
L9NBoMcb966otzSmsDu/RYt8VytJ4kDvYx9s+yP5EW7CsNCXNJKT3UZVrq1DAGzS
QCHDpp6qN/f1quQh5ywuYUS5u3I35lIznC1hbASyX4/qSAe/YiOl99cRh61nHaU9
0j/f/XDPZCGZjMQMxCpd
=roDn
-----END PGP SIGNATURE-----