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