Re: [Add] [EXTERNAL] Re: TTL of resolver.arpa

[Ben Schwartz <[e-mail]>]

On Wed, Jan 5, 2022 at 10:31 AM Daniel Migault <[e-mail]> wrote:
...

> The problem is that the response of the _dns.resolver.arpa is used to
> indicate the available encrypted resolver but that information remains only
> valid while the client remains attached to the same resolver.
>

I concur, but I don't see this as a problem.

Typically, a mobile node re-using the response from one network - like a
> wifi network - to another network - ran network - will not be able to
> discover the resolvers in the new network as it will attempt to connect to
> the resolvers of the old network.
>

Yes.  This is an error on the client's part.  The DDR response is only
valid and applicable for the interface configuration on which it was
discovered.  If you think it's unclear, we can add text reminding clients
of this restriction.

Regarding the arguments for not having a 0 TTL, that have been mentioned so
> far:
> * clients could flush their cash when changing the network. I agree with
> Paul W. this does not seem to be the case with many applications and cannot
> be a reliable hypothesis.
>

Clients either have to (a) restrict DDR records to the network on which
they were resolved, or (b) implement a fast fallback mechanism if the
resolver unexpectedly becomes unavailable and tolerate a brief outage
during reinitialization.

* polling issue does not seem to me an issue either. The resolver.arpa
> query is only expected to be performed when the discovery occurs and I do
> not see the need to perform a discovery every TTL.
>

I do see this need.  Networks are permitted to change their configuration.
Long-lived clients need to know how to stay up to date, ideally updating
before the old configuration becomes invalid.