On 2024-05-10 18:50 +01, Kirill A. Korinsky <kirill@korins.ky> wrote:
> On Fri, 10 May 2024 15:26:00 +0100,
> Florian Obser <florian@openbsd.org> wrote:
>> 
>> On 2024-05-10 14:53 +01, Stuart Henderson <stu@spacehopper.org> 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.