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

[Daniel Migault <[e-mail]>]

Hi,

Just to follow-up the discussion. 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.
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.
A connection to the resolver of the old network is by definition not what
the client expects and will result in no discovery or an unverified
discovery.
In both cases this is not what discovery was intended to be - facilitating
the use of a corresponding encrypted resolver.
More specifically, the resolver of the old network may be unreachable from
the new network in which case the client cannot connect the associated
encrypted resolver.
If the resolver of the old network is reachable, its certificate will not
have the IP of the resolver of the old network and the client MUST NOT
automatically use that resolver ( section 4.2 ).


The response provided by the resolver of the old network can be NXDOMAIN in
which case the response is subject to negative caching or there is a
response which is considered valid for TTL seconds.
Usually TTL is an indication or commitment (from the authoritative server)
the RRset will be valid during at least these TTL seconds.
Such commitment is possible as 1) there is no authority for such domain and
2) the validity of the RRSet depends on the client as well as the resolver
i.e min( connection time to the resolver, resolver commitment (TTL) ).
In our case, the resolver does not have any indication on how long the
client will be connected to that resolver, so the only plausible value here
seems to be 0 TTL.

Further investigations are probably needed for NXDOMAIN negative caching.

There are two ways the NOERROR response can be solved: 1) using a domain
name the resolver has some authority on - like a name based on the reverse
ip address. or 2) using a 0 TTL.

If I recall correctly, the choice or resolver.arpa was deliberately chosen
to prevent some interactions with the authoritative DNS. The consequence is
that there is no such authority.
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.
* 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. The connectivity
information of the resolver is retrieved using the target of the
resolver.arpa. I am also wondering how the polling issue could be an issue
when flushing the dns cache anytime we change network is not.

Yours,
Daniel

On Mon, Jan 3, 2022 at 1:19 PM Paul Wouters <[e-mail]> wrote:

> On Jan 3, 2022, at 13:07, Tommy Jensen <Jensen.Thomas=
> [e-mail]> wrote:
> >
> >
> >> I don't think the TTL means the resolver information is valid for
> >> that TTL time. TTLs refer to cachability of DNS records,
> >
> > I fail to see how these two statements agree. What does it mean for a
> record to be cacheable for a length of time, but not valid for the same
> length of time?
>
> Let me rephrase. The fact that www.nohats.ca A record has a TTL of 3600
> does not mean the DNS is somehow guaranteeing there is a webserver on that
> IP for the next 3600s.
>
> Phone books can have outdated phone numbers. Which is why you (used to)
> get a new one every year. There was no guarantee on each individual phone
> number being correct.
>
> The same is true for DNS. The TTL’s only meaning is “how long can I re-use
> this record for, without discarding it”.  Any other meaning you want to add
> is not backed up by DNS specifications, and you’d have to modify core DNS
> protocols if you wanted to do it here.
>
> > I think adding more explicit text to require clients to discard cached
> values for resolver.arpa on network change makes perfect sense.
>
> How can you tell the record you received is fresh or cached ? You can only
> tell by comparing the TTL to the authoritative server TTL, but in this case
> there isn’t even a real authoritative record since every network would be
> making up their own resolver.arpa records.
>
> Paul
>


-- 
Daniel Migault
Ericsson