[dnsdir] Dnsdir early review of draft-ietf-dprive-unilateral-probing-07

[Florian Obser via Datatracker <[e-mail]>]

Reviewer: Florian Obser
Review result: On the Right Track

I have been selected as the DNS Directorate reviewer for this draft. The
DNS Directorate seeks to review all DNS or DNS-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the ADs.
For more information about the DNS Directorate, please see
https://wiki.ietf.org/en/group/dnsdir

This is an early review and I am aware of ongoing discussions in the
dprive working group about the intended status of the document, the
probing policy and what to do about recursive resolvers implementing
DoT collocated with authoritative servers implementing Do53. This
review mostly focuses on what is in revision 07 of the draft but it is
possible that information from the mailing list snuck in.

* Intended status: Standards Track

There is ongoing discussion in dprive about this, for now I think the
status should be "Experimental".


* 3.1.  Pooled Authoritative Servers Behind a Single IP Address
|   A recursive resolver following the guidance in Section 4 that
|   interacts with such a pool likely does not know that it is a pool.
|   If some members of the pool follow this guidance while others do not,
|   the recursive client might see the pool as a single authoritative
|   server that sometimes offers and sometimes refuses encrypted
|   transport.

The second occurrence of "guidance" refers to something else than the
first occurrence. Suggested fix for the second "guidance":

|   If some members of the pool follow the protocol specified in
|   this document while others do not,

* 3.3.  Server Name Indication
| MUST NOT serve resource records that differ based on SNI

The MUST NOT adds a strong restriction on future protocols that
eliminate opportunistic encryption and unilateral probing.  I can
envision a desire to at least respond REFUSED when using the wrong
name.

As B.3. puts it:
|   Any new stronger protocol should consider how it interacts with the
|   opportunistic protocol defined here, so that operators are not faced
|   with the choice between widespread opportunistic protection against
|   passive attackers (this document) and more narrowly-targeted
|   protection against active attackers.

I would say this protocol should also consider how it might interact with
a new stronger protocol. That is, how can it be forward compatible.

* 3.4.  Resource Exhaustion
Wrong section:
| Section 6.5 of [RFC9250] ("Connection Handling")

should be

| Section 5.5 of [RFC9250] ("Connection Handling")

* 4.1.  High-level Overview
"If the encrypted transport protocol fails"

We really need to spell out what "fails" means, somewhere.

I am under the impression that draft is only concerned with successful
/ unsuccessful probes on the transport layer. As long as something
answers it is a successful probe, it would not even need to be a valid
DNS answer.

* 4.2.  Maintaining Authoritative State by IP Address
|    By associating state with the IP address, the recursive client is
|    most able to avoid reaching a heterogeneous deployment.

I do not understand what this is trying to say. Well, I understood it
retroactively after reading the following example. I think this needs
better wording. How about dropping that paragraph and pulling the last
one up, thusly:

|   respond with an ICMP port closed message).
|
|   By associating the state with the authoritative IP address, the
|   client can minimize the number of accidental delays introduced (see
|   also Section 4.5.1 and Section 3.1).
|
|   For example, consider an authoritative server named ns0.example.com
|   that is served by two installations (with two A records), one at
|   192.0.2.7 that follows this guidance, and one at 192.0.2.8 that is a
|   legacy (cleartext port 53-only) deployment.  A recursive client who
|   associates state with the NS name and reaches .7 first will "learn"
|   that ns0.example.com supports encrypted transport.  A subsequent
|   query over encrypted transport dispatched to .8 would fail,
|   potentially delaying the response.

* 4.3.  Overall Recursive Resolver Settings
|   A recursive resolver implementing this document

maybe this is better:

|   A recursive resolver implementing this protocol

|   Implementers or deployers of DNS recursive resolvers that follow the
|   strategies in this document are encouraged to report their preferred
|   values of these parameters.

report where? should this be deleted before publishing?

* 4.5.  Authoritative Server Encrypted Transport Connection State
Table 2:
| Retain Across Reset

should be

| Retain Across Restart

because later on the text uses "restart" as well.

* 4.6.  Probing Policy
|   When a recursive resolver discovers the need for an authoritative
|   lookup to an authoritative DNS server using IP address X, it
|   retrieves the records associated with X from its cache.

Since recursive resolvers deal with DNS resource records and usually
implement a cache of DNS RRs it took me a moment to figure out that
"record" and "cache" refer to the things from table 2. Using different
terminology might improve this section.

Since the policy is currently under discussion in the dprive-wg I did
not fully check the correctness of the algorithm. I can do that once
the discussion settles down.

* 4.6.9.  Receiving a Response over Encrypted Transport
|    But if R is unsuccessful (e.g. timeout or connection closed):

If there is a timeout or the connection is closed there is no response
R at all. I think the draft needs to be more explicit in defining
successful and unsuccessful outcomes. Using "e.g." in brackets
suggests the list is not exhaustive for unsuccessful. What if an
answer is received but it is REFUSED (unsuccessful?), SERVFAIL
(unsuccessful?), NXDOMAIN (obviously successful, but from the point of
view of the person trying to reach a website they were unsuccessful).

|      -  Return SERVFAIL to the requesting client

This does not seem to be correct. Consider this:
example.com.		86400	IN	NS	a.iana-servers.net.
example.com.		86400	IN	NS	b.iana-servers.net.

If a.iana-servers.net is unreachable we will short-circuit to SERVFAIL
without trying b.iana-servers.net. That is not how recursive resolvers
work. 4.6.2 has the same issue.

* 4.6.6.  Encrypted Transport Failure

Should we first try another encrypted transport if available and not
fall back to Do53 immediately?

* 4.6.7.  Handling Clean Shutdown of an Encrypted Transport Connection
Should we immediately retry E for the outstanding queries?

* 4.6.10.  Resource Exhaustion
| Section 6.5 of [RFC9250] ("Connection Handling")

should be

| Section 5.5 of [RFC9250] ("Connection Handling")

* 4.6.11.  Maintaining Connections
|   Some recursive resolvers looking to amortize connection costs, and to
|   minimize latency MAY choose to synthesize queries to a particular
|   resolver to keep an encrypted transport session active.

s/particular resolver/particular authoritative server/

* 5.  IANA Considerations
odd boiler plate