Subject: [Add] TTL of resolver.arpa

From: Daniel Migault <[email-masked]>
Date: Wed, 22 Dec 2021 09:45:11 -0500

Hi,

I am wondering if some additional text is not needed regarding the TTL of
the _dns.resolver.arpa RRset. As resolver.arpa is not owned by anyone, this
information should not be cached. If one device is changing network for
example, we should make sure the mobile will not consider the resolver.arpa
response performed on a previous network. Similarly, when a dns client
performs simultaneous discovery on different resolvers. Should we
recommend/mandate the DNS client to set this TTL to 0 and not cache the
response ?

_dns.resolver.arpa  7200  IN SVCB 1 doh.example.net (
        alpn=h2 dohpath=/dns-query{?dns} )

Yours,
Daniel
-- 
Daniel Migault
Ericsson

---

From: Eric Orth <[email-masked]>
Date: Wed, 22 Dec 2021 11:54:45 -0500

I think there are some valid concerns here around clients mistakenly
applying resolver.arpa info when changing to different networks/resolvers.

But I think mandating some never-cache policy is way too strong and not the
right solution.  Many clients already do stuff like clear the cache on
network change or DNS config change, so such a policy is unnecessary for
them.  And when the network and resolver haven't changed, it is still
undesirable for the client to poll that resolver more frequently than the
TTL, so using their cache implementations is the obvious way for clients to
implement this desired behavior.

On Wed, Dec 22, 2021 at 9:45 AM Daniel Migault <[email-masked]> wrote:

> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: Paul Wouters <[email-masked]>
Date: Wed, 22 Dec 2021 12:06:15 -0500 (EST)

On Wed, 22 Dec 2021, Eric Orth wrote:

> Many clients already do stuff like clear the cache on network change

which is wrong of course, because a roaming phone or laptop would leave
a very district dns lookup trail based on joining a network with an
empty cache and many browser tabs open.

> or DNS config change, so such a policy is unnecessary for them.

but for them, harmless.

>   And when the network and resolver haven't changed, it is still undesirable for the
> client to poll that resolver more frequently than the TTL, so using their cache implementations is the obvious way for clients to implement this desired
> behavior.

I agree that "network change" could be used to trigger the cache removal
of resolver.arpa specifically. Athough, I don't really see why using TTL
0 is a problem. I don't think the TTL means the resolver information is
valid for that TTL time. TTLs refer to cachability of DNS records, and
must not be used as time validity tool for third party information or
services, such as an encrypted DNS resolver service. Or rephrased, if
you would use it like that, and your DHCP server hands out resolver.arpa
with TTL 7200, the DHCP server would be commiting the DNS resolver to
be operational on the IP for 2hours and it may not be shut down. That
seems wrong to me as the DNS resolver and DHCP server have no direct
communication link (or protocol) to exchange that information.

Paul

> I am wondering if some additional text is not needed regarding the TTL of the _dns.resolver.arpa RRset. As resolver.arpa is not owned by anyone,
> this information should not be cached. If one device is changing network for example, we should make sure the mobile will not consider the
> resolver.arpa response performed on a previous network. Similarly, when a dns client performs simultaneous discovery on different resolvers. Should
> we recommend/mandate the DNS client to set this TTL to 0 and not cache the response ? 
>