unbound stops responding when connection to upstream breaks

Unbound
1

Hi,

I’m experiencing issues with unbound’s connection to my upstream recursive resolver. Both my local caching forwarder and the upstream recursive resolver are running unbound. The problem happens every time the connection between the local server and upstream fails and when this happens, the local’s connection to upstream will not reconnect. The connection might break due to a variety of things:

  • wifi on the laptop changing APs

  • connecting to a VPN

  • rebooting the upstream recursive server

Whenever one of these conditions happen, queries to the local forwarder will fail and continue to do so until the local forwarder is restarted. Once it’s restarted, everything works fine again. This feels like some kind of issue with TLS or a persistent connection.

Is there any way to force unbound to be a little more aggressive in reconnecting when something fails with networking?

Here’s my local forwarder’s unbound.conf:

server:

do-daemonize: no

use-syslog: yes

log-queries: yes

log-replies: yes

username: “unbound”

directory: “/etc/unbound”

trust-anchor-file: trusted-key.key

interface: 127.0.0.1

do-ip6: no

prefer-ip6: no

do-tcp: yes

do-udp: yes

ssl-upstream: yes

num-threads: 4

msg-cache-slabs: 8

rrset-cache-slabs: 8

infra-cache-slabs: 8

key-cache-slabs: 8

rrset-cache-size: 256m

msg-cache-size: 128m

so-rcvbuf: 1m

private-address: 192.168.0.0/16

private-address: 172.16.0.0/12

private-address: 10.0.0.0/8

forward-zone:

name: “.”

forward-addr: @443

And here is my upstream recursive resolver’s:

server:

use-syslog: yes

verbosity: 1

access-control: 0.0.0.0/0 allow

log-queries: no

log-replies: no

username: “unbound”

directory: “/etc/unbound”

auto-trust-anchor-file: “/etc/unbound/etc/trusted-key.key”

val-permissive-mode: yes

root-hints: root.hints

interface: 0.0.0.0@443

do-ip6: no

prefer-ip6: no

do-udp: yes

do-tcp: yes

ssl-service-key: “/etc/letsencrypt/live//privkey.pem”

ssl-service-pem: “/etc/letsencrypt/live//fullchain.pem”

ssl-port: 443

do-daemonize: no

chroot: “/etc/unbound”

hide-version: yes

hide-identity: yes

harden-glue: no

harden-dnssec-stripped: no

use-caps-for-id: yes

so-rcvbuf: 1m

prefetch: yes

minimal-responses: yes

ratelimit: 1000

ip-ratelimit: 500

cache-max-negative-ttl: 10

unwanted-reply-threshold: 10000

private-address: 192.168.0.0/16

private-address: 172.16.0.0/12

private-address: 10.0.0.0/8

Any ideas? Thanks.

Chris

2

Hi,
if I recall correctly

       infra-host-ttl: 15
        infra-keep-probing: yes

fixed it for me.

Ciao,
Tito

3

Thanks. I will give this a shot!

4

This seems to have fixed my problem. I want to understand the infra-host-ttl better. The docs say “Time to live for entries in the host cache”. What is this cache, exactly? Is this the cache of upstream servers that are the target of the forward-addr directives? Or is this DNS host records that have been queried by clients? I’d like to set this TTL as low as possible without impacting DNS server performance or record-caching.

Chris

5

Hi Chris,

It is the cache that holds information for all encountered upstream servers (also forward-addr).

You can find more information at https://unbound.docs.nlnetlabs.nl/en/latest/reference/history/info-timeout-server-selection.html

Best regards,
-- George

6

Thanks George, that helps a lot. It would be really helpful if the Unbound docs included a “road warrior” example for running Unbound on a laptop that forwards all its queries elsewhere. Having infra-host-ttl set low is a big improvement for this use case, but it’s not very obvious when reading the documentation as a new user (who probably aren’t reading the long doc linked below).

It would be helpful to have sane configuration examples in the docs for the following use cases:

  • Home desktops (the default config as presented by the current docs?)

  • Road warrior laptops that frequently change IP addresses, use VPNs, etc., and forward all queries over TLS to an off-site recursive resolver

  • An offsite recursive resolver to use over TLS by home desktops and road warrior setups who want to avoid sniffing by consumer ISPs.

  • A recursive resolver for use in high-traffic settings

Thanks again!

Chris