unbound stops responding when connection to upstream breaks

[George Thessalonikefs]

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

On 10/02/2022 19:19, Chris Snell via Unbound-users wrote:
> 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
> 
> On Wed, Feb 9, 2022, at 10:36 AM, Chris Snell via Unbound-users wrote:
>> Thanks.  I will give this a shot!
>>
>> On Wed, Feb 9, 2022, at 10:06 AM, tito via Unbound-users wrote:
>>> On Wed, 09 Feb 2022 09:04:59 -0500
>>> Chris Snell via Unbound-users <unbound-users at lists.nlnetlabs.nl 
>>> <mailto:unbound-users at lists.nlnetlabs.nl>> wrote:
>>>
>>> > 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: <REDACTED>@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 at 443
>>> >   do-ip6: no
>>> >   prefer-ip6: no
>>> >   do-udp: yes
>>> >   do-tcp: yes
>>> >   ssl-service-key: "/etc/letsencrypt/live/<REDACTED>/privkey.pem 
>>> <http://silcox.island.nu/privkey.pem 
>>> <http://silcox.island.nu/privkey.pem>>"
>>> >   ssl-service-pem: "/etc/letsencrypt/live/<REDACTED>/fullchain.pem 
>>> <http://silcox.island.nu/fullchain.pem 
>>> <http://silcox.island.nu/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
>>>
>>> Hi,
>>> if I recall correctly
>>>
>>>        infra-host-ttl: 15
>>>         infra-keep-probing: yes
>>>
>>> fixed it for me.
>>>
>>> Ciao,
>>> Tito
>>>
>>>
>>
>