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

From: Tommy Jensen <[email-masked]>
Date: Mon, 3 Jan 2022 18:07:29 +0000

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 <[email-masked]> On Behalf Of Paul Wouters
> Sent: Wednesday, December 22, 2021 9:06 AM
> To: Eric Orth <ericorth=[email-masked]>
> Cc: ADD Mailing list <[email-masked]>; Daniel Migault <[email-masked]>
> 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 <[email-masked]>
> 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
> > [email-masked]
> > 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
> [email-masked]
> 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

---

From: Paul Wouters <[email-masked]>
Date: Mon, 3 Jan 2022 13:19:33 -0500

> 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

---

From: Daniel Migault <[email-masked]>
Date: Wed, 5 Jan 2022 10:30:38 -0500

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 <[email-masked]> wrote:

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

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 5 Jan 2022 11:52:49 -0500

On Wed, Jan 5, 2022 at 10:31 AM Daniel Migault <[email-masked]> wrote:
...

> valid while the client remains attached to the same resolver.

I concur, but I don't see this as a problem.

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

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

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

---

From: Tommy Jensen <[email-masked]>
Date: Wed, 5 Jan 2022 18:31:10 +0000

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=[email-masked]>
Sent: Wednesday, January 5, 2022 8:53 AM
To: Daniel Migault <[email-masked]>
Cc: Paul Wouters <[email-masked]>; ADD Mailing list <[email-masked]>; Tommy Jensen <[email-masked]>; Eric Orth <[email-masked]>
Subject: Re: [Add] [EXTERNAL] Re: TTL of resolver.arpa

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

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.

---

From: Daniel Migault <[email-masked]>
Date: Wed, 5 Jan 2022 13:32:24 -0500

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

"""

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.

> discovered.  If you think it's unclear, we can add text reminding clients

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.

> resolver unexpectedly becomes unavailable and tolerate a brief outage

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.

> 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

---

From: Steffen Nurpmeso <[email-masked]>
Date: Wed, 05 Jan 2022 20:19:21 +0100

Tommy Jensen wrote in
 <[email-masked]\
 ook.com>:
 |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.

Yes.  Here are configurable conf_(min|max|neg)_ttl variables in
order to allow overwriting of what DNS gives.  The former defaults
to 60 (1<60<120), (min<U32_MAX-1) the last to 60 (30<60<300,
talking about RFCs 1034, 1536 and 2308), pretty straightforward.
Special treatment for resolver.arpa provided addresses has to
happen (no file-based monitoring applies for them), but the lesser
the impact the better i would cite.

Thanks and ciao,

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)