DNS Privacy Considerations
draft-ietf-dprive-problem-statement-06

Thanks for doing this work.

You might want to include a reference to ENUM in Section 2.2.

I wonder if it's worth mentioning traffic analysis somewhere in the document (or if it's mentioned in one of the references I didn't have time to scan?). Even for an observer who does not have access to the content of DNS requests/responses, I would imagine it's possible to glean some information about what the user is doing based solely on the metadata associated with the DNS traffic (e.g., identifying when a host is likely making a particular type of request or a specific sequence of requests).

In Section 4, I would caution against saying there is no court precedent unless you know for sure that there is not. My guess would be that DNS traffic logs have probably been entered into evidence in some court somewhere in the world for some purpose, so there may well be some precedent about something even if we don't know what it is or how broadly it applies.

Only positive comments here, because they're important too:

As the document shepherd says: "While problem statement documents are often viewed as a waste of time, this particular one has been very useful, to help get everyone on the same page."  Indeed, and thanks for doing this.

This document probably has the highest reference count per document page that I've seen.  That said, I find the reference list to be well chosen and helpful, and the separation of the few normative references to be just right.  Thanks for that, as well.

Thanks for this. It's well written and informative.

Very good stuff, thanks for the work and I can't wait to
see our eventual mitigation solutions get tested and
deployed.

- p4, primary request: "of interest to the eavesdropper" isn't
quite right - the eavesdropper is probably more interested in
the URL and not just the DNS name from the URL.

- p4, "glue records" - you didn't say what those are

- p4, "it is a big privacy concern" is unclear - do you mean
autocomplete? Or (as implied by the next sentence) do you mean
pre-fetching the names in href's? Better to be clearer.

- 2.1 - the "alleged" in the title isn't really needed but may
be ok to leave in for emphasis. Maybe a better section title
would be "DNS data is public, DNS transactions ought not be
public" or similar

- 2.2: the [denis-edns-client-subnet] reference doesn't point
at a great URL for an RFC, be great if there were a better
reference. The same issue may come up wrt some of the other
references. I think in this case, it should be fine to leave
those as-is if there aren't easily found better sources as this
is not a protocol specification and so the RFC editor will not
(I hope) be as worried about the stability of these.

- 2.4: Be better to expand IAP on 1st use

- 2.5.2 (or elsewhere): a lot of the traffic that arrives at
TLD authoritative servers is due to errors, as noted. However,
those errors (when due to typing) are also possibly privacy
sensitive, e.g. perhaps one for alcolicsanonymous.com. I don't
think that issue is noted, and it probably ought be somewhere.
(Maybe not here, as it is relevant to all DNS servers.)