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

[Tommy Jensen <[e-mail]>]

I agree with Eric that recommending a TTL of zero seems awfully heavy and likely to lead to flooding resolvers with unnecessary traffic (or worse, hard coded TTLs in effect on clients which means sticky settings which the resolver has no visibility into).

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

I think adding more explicit text to require clients to discard cached values for resolver.arpa on network change makes perfect sense. I think the existing text for the use of the SVCB record's TTL is sufficient to prevent DoS by DDR, but suggestions are welcome.

Thanks,
Tommy

> -----Original Message-----
> From: Add <[e-mail]> On Behalf Of Paul Wouters
> Sent: Wednesday, December 22, 2021 9:06 AM
> To: Eric Orth <ericorth=[e-mail]>
> Cc: ADD Mailing list <[e-mail]>; Daniel Migault <[e-mail]>
> Subject: [EXTERNAL] Re: [Add] TTL of resolver.arpa
> 
> 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
> 
> > On Wed, Dec 22, 2021 at 9:45 AM Daniel Migault <[e-mail]>
> wrote:
> >       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
> > --
> > Add mailing list
> > [e-mail]
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> >
> ietf.org%2Fmailman%2Flistinfo%2Fadd&amp;data=04%7C01%7CJensen.Thoma
> s%4
> >
> 0microsoft.com%7Cbc990e72debb401e9bf408d9c56d6a73%7C72f988bf86f14
> 1af91
> >
> ab2d7cd011db47%7C1%7C0%7C637757896178734219%7CUnknown%7CTWF
> pbGZsb3d8ey
> >
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> C300
> >
> 0&amp;sdata=l3q6Hk5smPvGBbgnkOcsiyzrlqG10k%2BOV4curdr3Mxo%3D&am
> p;reser
> > ved=0
> >
> >
> >
> 
> --
> Add mailing list
> [e-mail]
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ie
> tf.org%2Fmailman%2Flistinfo%2Fadd&amp;data=04%7C01%7CJensen.Thomas
> %40microsoft.com%7Cbc990e72debb401e9bf408d9c56d6a73%7C72f988bf86f
> 141af91ab2d7cd011db47%7C1%7C0%7C637757896178734219%7CUnknown
> %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw
> iLCJXVCI6Mn0%3D%7C3000&amp;sdata=l3q6Hk5smPvGBbgnkOcsiyzrlqG10k%
> 2BOV4curdr3Mxo%3D&amp;reserved=0