Re: [dns-privacy] Restarting the discussion of draft-ietf-dprive-unilateral-probing

Hi Paul,

I reviewed the document before my vacation but did not get around to
sending them earlier. Sending comments now. Will send minor comments
separately.

Suggest DoET or DoQTH as abbreviations for encrypted transports. Using
DoET in my comments below for conciseness.

Comment on organization: The document goes into a lot of detail on the
per-nameserver state to track and the actions to take on various
events (sections 4.4, 4.6.1-4.6.5). While this is useful guidance for
an implementor, the details will vary across implementations and are
not of interest to readers interested in the protocol at a higher
level. Suggest moving these implementation dsections *after* the
higher level protocol details in section 4.

* Section 4.1 High-level overview (for recursive resolver)
The description here is in the context of a single NS IP. It needs to
be broadened to the available NS IP set for the query/zone. Generally
any NS IP with working encryption should be preferred over Do53.

In addition a conservative resolver may want to distribute queries
across both Do53 and DoET to avoid sending too many queries over DoET.

Also consider the possibility that the resolver is sending queries
from multiple source IPs (applies to large scale operators). This
affects the state tracking variables in section 4.4.

* Section 4.6.6 Encrypted Transport Failures

On failure should check other NS IPs for the same zone instead of
going to Do53 on same IP.

* Section 4.6.8.1.  Avoid EDNS Client Subnet
The recommendation to avoid ECS seems out of place in this document.
In practice GPDNS and possibly other DNS resolvers already send ECS
over plaintext. This decision would be orthogonal to unilateral
probing.

* Section 4.6.10 Resource Exhaustion
Suggestion: Only initiate encrypted probing/connections after a
minimum number of queries to a server. Not enough value to
probe/maintain DoET state for a server which gets a small number of
queries a day. Different operators could have different policies for
this.

-Puneet

On Tue, Jul 12, 2022 at 8:46 PM Paul Hoffman <paul.hoffman@icann.org> wrote:
>
> Greetings again, and thank you to everyone who contributed comments on the -00 draft. As you can see, we published the -01 draft yesterday, and would love to get some discussion happening on the list to help focus the discussion at IETF 114. (I say "we" because dkg and Joey were kind enough to add me as a co-author!)
>
> As you can see from the diffs, there are a lot of changes in -01. The most significant technical change is the addition of a new field, E-last-response, the timestamp of the most recent response received on an established connection. This makes the checks for persistence more accurate.
>
> There are still some issues to be resolved in the draft; they are marked with "FIXME". In specific:
>
> - Should Extended DNS Errors (EDEs) be passed on to clients that have requested them? Is this different between encrypted and unencrypted transport?
>
> - Should resumption tickets be used when encrypted transport fails?
>
> - Should we further refine (past what is already in the document) what to do when encrypted transport fails? A few examples are given.
>
> We also have a few open issues tracked in our GitLab repo at <https://gitlab.com/dkg/dprive-unilateral-probing/-/issues>.
>
> Please review any/all of the above, and if you have a comment, please open a new thread here on the mailing list. We can also take new issues here or in the tracker, and we know that all issues should be resolved here on the list.
>
> DPRIVE has a short meeting at IETF 114 (we're in a slot with the ADD WG, and they have three draft that about to go to IESG ballot), but it would be great if we can spend it working on issues instead of the typical slideware presentation just listing the issues.
>
> --Paul Hoffman
>
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy