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

[Tommy Jensen <[e-mail]>]

I’m in full agreement with Ben on all points.

Re-reading the draft, I see that the understanding that DDR designations are only valid for the network they were discovered on was left unspoken. I’ll open a new issue and prepare text to provide that guidance.

As for the TTL topic, using a TTL is necessary for network configuration changes. If any given resolver doesn’t want to be polled, they are free to set a very large TTL. If a resolver wants to frequently confirm designations, they can set a very short TTL. Taking away that flexibility doesn’t make sense to me. As far as the meaning of TTL: it is obviously treated as a term of validity in the wild and not assuming that is the case is not practical.

Thanks,
Tommy

From: Ben Schwartz <bemasc=[e-mail]>
Sent: Wednesday, January 5, 2022 8:53 AM
To: Daniel Migault <[e-mail]>
Cc: Paul Wouters <[e-mail]>; ADD Mailing list <[e-mail]>; Tommy Jensen <[e-mail]>; Eric Orth <[e-mail]>
Subject: Re: [Add] [EXTERNAL] Re: TTL of resolver.arpa

On Wed, Jan 5, 2022 at 10:31 AM Daniel Migault <[e-mail]<mailto:[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.