Good behavior when NS are down and default value of infra-cache-max-rtt

[François Lafont]

Hi,

I have a DNS unbound resolver in a local site A with
lot of trafic, especially to the nameservers ns1 and
ns2 of the internal zone "in.domain.tld". The servers
ns1 and ns2 are in another site, the site B (ns1 and
ns2 are in the same site B, and I know it's bad but
it can't be changed quickly). When the site B is
unreachable (it's very rare but it can happen), the
unbound server can't reach ns1 and ns2 and problems
arise very quickly.

Indeed, because there are many requests on the
"in.domain.tld" zone, many unbound threads time out
and pending requests are piling up. Unbound takes too
long to consider servers ns1 and ns2 as down and to
immediately respond with SERVFAIL for requests
concerning the "in.domain.tld" zone.

In short, there are no more threads available.
Ultimately, the server can no longer resolve anything,
not even names belonging to domains whose nameservers
are perfectly reachable (in summary, unbound can no
longer even resolve www.google.com).

Here is my questions.

1. I have searched in the documentation and I came to
    the conclusion that the default value of the parameter
    `infra-cache-max-rtt`, ie 2 minutes, is too big for
     an unbound server in production. To me, a value of
     3000, ie 3 seconds, is better for production. What
     do you think about that?

2. To me, a better configuration could be:

```conf
server:

   # NS seen as DOWN when rto reaches 3 seconds (not 2
   # minutes which is too long).
   infra-cache-max-rtt: 3000

   # When the NS is UP, the blocking mode is finished
   # after 60 seconds.
   infra-host-ttl: 60

   # Not sure and not clear for me concerning this
   # parameter. It seems that this parameter can slightly
   # speed up the time it takes for an NS in blocking mode
   # to come back to life.
   infra-keep-probing: yes
```

Does this configuration seem correct to you regarding the management of NS that
go down?

Bye.

-- 
François Lafont