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.hoff...@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 _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy