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

[Daniel Migault <[e-mail]>]

On Wed, Jan 5, 2022 at 11:53 AM Ben Schwartz <[e-mail]> wrote:

> 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.
>

The text says:
"""
I think the protocol as currently defined results in connectivity issues
when network provided resolvers are used. This seems to me an important
issue that needs to be addressed by the discovery protocol itself - as
opposed to relying on applications.

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.
"""

It seems pretty clear that the issue was mentioned in the paragraph above.
The "problem" in the second paragraph should be read as "the reason for the
problem".  Please let me know if that is confusing in English.


>
> 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.
>

I do not see any such text in the draft, can you point me to the text you
are referring to so that I can check whether that is clear or not.

I find it very complex to require a DNS client to have a DNS cache that is
independent from the network address and another cache specific for a given
interface. I am not convinced at this time it is reasonable to assume such
a mechanism will be implemented  by any DNS client.

For my information I am wondering if you have any reference on how I can
configure in chrome names that are bound to an interface as opposed to
names that are not bound to an interface.


>
> 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.
>

Again, this seems way more complex to assume every DNS client will
implement it correctly. Setting a TTL to 0 works for sure with any DNS
client.

>
> * 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.
>

It is unclear how a TTL set to 0 prevents the network from being configured
- It actually removes any commitments. The resolvers information is updated
every TTL where TTL designates the TTL of the domainname of the resolvers (
doh.resolver.example.com).  If the provided parameters do not match the
client policies a new discovery is performed. Are you suggesting that DDR
is performed every TTL where TTL is the TTL of _dns.resolver.arpa.

Yours,
Daniel

-- 
Daniel Migault
Ericsson