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.