DNS Privacy Considerations
RFC 7626

Note: This ballot was opened for revision 05 and is now closed.

(Ben Campbell) Yes

Comment (2015-06-09 for -05)
No email
send info
Thanks for this. It's well written and informative.

Alissa Cooper Yes

Comment (2015-06-09 for -05)
No email
send info
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.

(Stephen Farrell) Yes

Comment (2015-06-08 for -05)
No email
send info
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.)

(Brian Haberman) Yes

Barry Leiba Yes

Comment (2015-06-09 for -05)
No email
send info
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.

(Terry Manderson) Yes

(Kathleen Moriarty) Yes

(Jari Arkko) No Objection

Comment (2015-06-11 for -05)
No email
send info
Gen-ART review comments from Suresh Krishnan should be looked at. I agree with those suggestions.

(Alia Atlas) No Objection

Comment (2015-06-11 for -05)
No email
send info
This draft is truly a joy to read.  It is very well written and clear.
Thank you.

Deborah Brungard No Objection

(Joel Jaeggli) No Objection

Comment (2015-06-08 for -05)
No email
send info
As an editorial/organizational nit, I would probably consign the actual description of the dns protocol in the introduction ( paragraph 3/4) to a subsection so that it can be distinct from the other introductory text preceding it and the introductory analysis that follow.

Alvaro Retana No Objection

(Martin Stiemerling) No Objection