From: Florian Obser Subject: Re: Prevent Unbound from penalty upstream server To: tech@openbsd.org Date: Fri, 10 May 2024 20:58:56 +0200 On 2024-05-10 18:50 +01, Kirill A. Korinsky wrote: > On Fri, 10 May 2024 15:26:00 +0100, > Florian Obser wrote: >> >> On 2024-05-10 14:53 +01, Stuart Henderson wrote: >> > I'd like to wait until the discussion with upstream goes further before >> > making any changes to the default config. >> > >> > >> >> agreed. I think it makes sense to set infra-keep-probing in unwind >> though since it plays a completely different role than unbound. >> > > What do you think about just infra-keep-probing: yes for both case? Without > increase ttl and other option, just never gave up on upstream host. I don't have a lot of experience running recursive resolvers, my experience is with authoritative servers. From that point of view I'd say if one server can't be reached it's a good idea to not bother with it and don't waste any more resources on it but move on and ask a different server that is likely reachable. I might be completely off here though. > > diff --git etc/unbound.conf etc/unbound.conf > index b33c099d70f..32e35e2bc02 100644 > --- etc/unbound.conf > +++ etc/unbound.conf > @@ -29,6 +29,10 @@ server: > # > aggressive-nsec: yes > > + # Keep probing an upstream server > + # > + infra-keep-probing: yes > + > # Serve zones authoritatively from Unbound to resolver clients. > # Not for external service. > # > diff --git sbin/unwind/resolver.c sbin/unwind/resolver.c > index e9d877b0135..ab9c06b87fd 100644 > --- sbin/unwind/resolver.c > +++ sbin/unwind/resolver.c > @@ -1211,6 +1211,7 @@ static const struct { > { "target-fetch-policy:", "0 0 0 0 0" }, > { "outgoing-range:", "64" }, > { "val-max-restart:", "0" }, > + { "infra-keep-probing", "yes" }, > }; > > struct uw_resolver * > > > -- > > wbr, Kirill > -- In my defence, I have been left unsupervised.