[Unbound-users] Unbound flails without a network connection

[Taylor R Campbell]

I run Unbound 1.4.6 under NetBSD 5.1 on a laptop which does not always
have a network connection.  If no interface has an address configured
while Unbound is running, then Unbound flails and fills the syslog
with messages of the form

[304:0] notice: sendto failed: Can't assign requested address
[304:0] notice: remote address is x.y.z.w

thousands of messages per second.  Here x.y.z.w are the addresses of
root nameservers, gTLD nameservers, and authoritative nameservers for
common domains such as google.com.

I didn't see anything related to this situation in the unbound(8) or
unbound.conf(5) man pages, or the Unbound documentation, and a quick
googling turned up nothing relevant.  Can I persuade Unbound not to
flail like this, short of simply waiting to start Unbound until the
network interfaces are configured, and stopping it upon unconfiguring
them?



Some further information; let me know if you want more.  Here's my
Unbound configuration, stripped of comments:

   server:
           verbosity: 1
           chroot: "/var/chroot/unbound"
           directory: ""
           pidfile: /var/run/unbound.pid
           root-hints: "named.cache"
           auto-trust-anchor-file: "root.key"
   python:
   remote-control:

Here's what's in /var/chroot/unbound:

   anchors.mf           (for the old IANA ITAR, dated 2010-06-01)
   named.cache          (fetched from ftp.internic.net on 2010-06-20)
   root.key             (updated by Unbound)
   root.key-20100827    (an old copy of root.key from 2010-08-27)

P.S.  I saw that comm_point_send_udp_msg considers ENETUNREACH,
EHOSTDOWN, and EHOSTUNREACH to be transient errors, and handles them
less noisily than others.  It seems to me that this is the same sort
of transient error; however, it's not immediately clear to me what the
consequences of treating EADDRNOTAVAIL as a similar transient error
would be, beyond omitting messages from the syslog -- a cursory
examination of the source suggests that Unbound would still spin with
repeated failing queries, albeit silently.