DNS Privacy Considerations
RFC 9076

Received changes through RFC Editor sync (created alias RFC 9076, changed abstract to 'This document describes the privacy issues associated with the use of the DNS by Internet users.  It provides general observations about typical current privacy practices.  It is intended to be an analysis of the present situation and does not prescribe solutions.  This document obsoletes RFC 7626.', changed pages to 22, changed standardization level to Informational, changed state to RFC, added RFC published event at 2021-07-23, changed IESG state to RFC Published, created obsoletes relation between draft-ietf-dprive-rfc7626-bis and RFC 7626)

[Ballot comment]
[ Thank you for addressing my DISCUSS point. ]


[Edit: I accidentally hit "Send" too early; I have another few comments, also non-blocking:
1: "Also, sometimes, the QNAME embeds the software one uses, which could be a privacy issue. For instance, _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.example.org."... Unless you are a Microsoft or DNS weenie, this is likely not at clear -- what is being leaked here? The fact that the site uses TCP? LDAP? Windows? Goldbach's Conjecture? Example software? (I think adding a sentence here would be helpful...)
]

Thank you for this document - it's really useful, and readable as well.

I do have a few small comments to (possibly) make it even better - I will in no way be offended if you ignore these...

The background on how DNS works is nicely written, and I'm to point people at it when I need to explain how the DNS works -- but I think a better name example than:
"What are the SRV records of _xmpp-server._tcp.example.com?" would be good -- SRV is an unusual record type, and names with underscores surprise people. I'd instead suggest "What is the MX records for example.com" or "What is the A record for ftp.example.com?" -- I'm only mentioning this because the rest of the section is a very general introduction and this might confuse newcomers...

"At the time of writing, almost all this DNS traffic is currently sent in clear (i.e., unencrypted). However there is increasing deployment of DNS-over-TLS (DoT) [RFC7858] and DNS-over-HTTPS (DoH) [RFC8484], particularly in mobile devices, browsers, and by providers of anycast recursive DNS resolution services."
I think that you might want to remove the "particularly in ..." - I suspect that it will not age well; the document does say "At the time of writing" and "increasing", etc., but this document is likely foundational enough that it will still be referenced many many years from now, and this text may just cloud matters then.

Whatever the case, thanks again for this document!

[Ballot comment]
I'll add my thanks for this document.  I have tripped on some of the issues in my experience, but some of the others described here were eye-opening.  I'm also learning from the ensuing discussions.

Section 1:

A couple of nits:

* "DNS relies on caching heavily ..." -- suggest "DNS relies heavily on caching ..."

* "Both are a big privacy concern since ..." -- suggest "Both are big privacy concerns since ...", unless you mean the two of them collectively (in which case, please say so)

I agree with Warren in that it's not clear what's leaking in the example at the bottom of the second paragraph of Section 4.2.

In Section 5.1, please expand "CPE" on first use.

I'm having trouble parsing the third paragraph of Section 5.2.  The fourth paragraph in the same section needs some commas.

[Ballot comment]
I have comments on the DISCUSS positions of Alissa and Warren, both of which I support to some extent:

On Warren’s point, which I wouldn’t have made it a DISCUSS myself, I agree that editorial changes are warranted so as to make the point more clearly and with less baggage.  I think we all know what the document means here, but not all readers will, and there’s sufficient FUD in this area that it behooves us to be very careful about how we say things.  Avoiding things such as “alleged” and “it has long been claimed” is easy, would go a long way toward clarity and avoidance of feeding the FUD, and is worth a brief editing pass.  I leave it to Warren to work the details out with the working group.

On Alissa’s first point — why publish this update now, rather than waiting until more things shake out and settle down — I basically agree, though I’m torn between thinking that waiting is better... and, on the other hand, acknowledging that enough has already changed that it’s important to get the update out there, and that it can be updated again later.

On her second point, I’ll go in a different direction: it’s bordering on silly to think that any real end user can be said to “be aware of and have the ability to control” anything related to DNS settings and resolution options.  If “users” refers to those of us writing these specs, sure.  But when we’re talking about our siblings and cousins and parents, who are doctors and nurses, chefs and bakers, bank tellers and car mechanics, there is no hope of awareness and understanding of the choices and their consequences, nor that any form of “communicate clearly” will really accomplish anything.  I see little to recommend pretending that it will.

So I, too, am not sure what this text is really meant to convey.

[Ballot discuss]
== Section 1 ==

"At the time of writing, almost all this DNS traffic is currently sent
  in clear (i.e., unencrypted).  However there is increasing deployment
  of DNS-over-TLS (DoT) [RFC7858] and DNS-over-HTTPS (DoH) [RFC8484],
  particularly in mobile devices, browsers, and by providers of anycast
  recursive DNS resolution services.  There are a few cases where there
  is some alternative channel encryption, for instance, in an IPsec VPN
  tunnel, at least between the stub resolver and the resolver.

  Today, almost all DNS queries are sent over UDP [thomas-ditl-tcp].
  This has practical consequences when considering encryption of the
  traffic as a possible privacy technique.  Some encryption solutions
  are only designed for TCP, not UDP and new solutions are still
  emerging [I-D.ietf-quic-transport] [I-D.huitema-quic-dnsoquic]."

This text made me wonder about the value of publishing this bis document at this point in time. Things are evolving so rapidly that, with respect to several of the new parts of this document (e.g., the last few paragraphs of Sec. 6.1.1, Sec. 6.1.1.1, Sec. 6.1.1.2), an immutable summary designed to represent reality over the long term doesn't really seem feasible right now. Why not wait to see how QUIC, DOH, ADD, ODNS, etc. shake out in the next few years and take this up then?

== Section 6.1.1.2 ==

"Users will only be aware of and have the ability to control such
  settings if applications provide the following functions:

  o communicate clearly the change in default to users

  o provide configuration options to change the default

  o provide configuration options to always use the system resolver"

This doesn't seem true. If the third bullet isn't provided, users still have awareness and control. Also, the bullets seem redundant with the text above, as if this is saying "users only have awareness and control if they have awareness and control." As a result I'm not sure what this text is really meant to convey.

[Ballot comment]
Please remove uses of "us" and "we," given that this is a consensus document.

"Privacy policies for these servers may or may not be available and users need to be aware that privacy guarantees will vary with network." --> This is unrealistic as almost no users understand any of this. I'd recommend removing this.

Section 6.1.3: The title says "Blocking of User Selected DNS Resolution Services" but the text is actually broader than that and applies to blocking of resolution services whether or not they are user-selected. I would suggest changing the title.

Section 6.1.4.2:
"Privacy focused users should be aware of the potential for additional client identifiers in DoH compared to DoT and may want to only use DoH client implementations that provide clear guidance on what identifiers they add." Again this seems really unrealistic for the majority of users who have no idea what any of this means.

[Ballot comment]
Thank you for responding to the SECDIR review (and thank you to Stephen Farrell for performing the SECDIR review).

** Section 3.5.1.1.  Per “These resolvers may have strong, medium, or weak privacy policies …”, what are the dimensions of this Likert-style scale?  I recommend a simpler sentence -- “… may have varied privacy policies”.

** Section 6.1.1.  Per “All major OS's expose the system DNS settings and allow users to manually override them if desired”, agreed.  However, in managed environments, users may not be able to manually override these settings.

** Section 6.1.3.  Per “User privacy can also be at risk if there is blocking (by local network operators or more general mechanisms) …”, what is a “more general mechanism”?  Also, "local network operator" describes who is doing the blocking and "general mechanisms" seems to be describing a technique.

** Section 8.  Editorial.  Per “They are used for many reasons – some good, some bad.”, I’d recommend against making judgements and stick to a rubric of operational practices and attacker behavior (say RFC7258).  I’m not sure this sentence is needed.

Editorial nits

-- ** Section 6.1.1.  Editorial.  s/additionally highly dependent/highly dependent/

-- Section 12.  Typo. s/apprecriated/appreciated/

[Ballot comment]
Section 1

  At the time of writing, almost all this DNS traffic is currently sent
  in clear (i.e., unencrypted).  However there is increasing deployment

nit: I think that "in the clear" is the term of art (add "the").

  Today, almost all DNS queries are sent over UDP [thomas-ditl-tcp].

It looks like
(https://mailarchive.ietf.org/arch/msg/dns-privacy/1pZL1FA57hzE1e09mQ2HMg2aWYY/)
Sara was going to follow up with the DITL authors to try and ascertain
whether "almost all queries" is still accurate for the "UDP" aspect,
though the IETF mailarchive search doesn't seem to find any more recent
traffic on that topic.  Do we know if anyone actually heard back about
this (or the "sent in [the] clear" a few lines previously)?
I do not pretend to have the expertise needed to judge how the changes
deployed by major browser affect the statistics for "all DNS traffic"
(which presumably includes both stub-to-resolver and
resolver-to-authoritative).

  This has practical consequences when considering encryption of the
  traffic as a possible privacy technique.  Some encryption solutions
  are only designed for TCP, not UDP and new solutions are still
  emerging [I-D.ietf-quic-transport] [I-D.huitema-quic-dnsoquic].

[It looks like dnsoquic became draft-huitema-dprive-dnsoquic.]

Section 3

  multiple dynamic contexts of each device.  This document does not
  attempt such a complex analysis, instead it presents an overview of
  the various considerations that could form the basis of such an
  analysis.

nit: looks like a comma splice.

Section 4.1

  authentication or authorization of the client (resolver).  Due to the
  lack of search capabilities, only a given QNAME will reveal the
  resource records associated with that name (or that name's non-
  existence).  In other words: one needs to know what to ask for, in

I agree with Warren that this statement ("only [...] will reveal [...]
or that name's non-existence") is overly strong.

Section 4.2

  The DNS request includes many fields, but two of them seem
  particularly relevant for the privacy issues: the QNAME and the
  source IP address. "source IP address" is used in a loose sense of
  "source IP address + maybe source port number", because the port

In other contexts I've seen this combination referred to as the
"transport address".

  The QNAME is the full name sent by the user.  It gives information
  about what the user does ("What are the MX records of example.net?"
  means he probably wants to send email to someone at example.net,
  which may be a domain used by only a few persons and is therefore
  very revealing about communication relationships).  [...]

(editorial) something like not-a-secret-cabal.example might make the
example more visceral than example.net does.

  create more problems for the user.  Also, sometimes, the QNAME embeds
  the software one uses, which could be a privacy issue.  For instance,
  _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.example.org.

(nit) I trust that this can be made into a complete sentence while
addressing Warren's more-substantive comment.

  There are also some BitTorrent clients that query an SRV record for
  _bittorrent-tracker._tcp.domain.example.

In a similar vein, I'm not sure what domain.example is supposed to
represent here -- the domain of the author of the BitTorrent client?

  Therefore, all the issues and warnings about collection of IP
  addresses apply here.  For the communication between the recursive

I mostly assume that this is intended to be a reference to the generic
concerns about "IP addresses are PII", etc., that one is ambiently
exposed to by reading enough about the Internet.  (There does not seem
to be previous discussion of "collection of IP addresses" in this
document, which would seem to indicate that it is not trying to refer
back to previous text.)  If so, perhaps an extra word or two would help
("all the standard issues and warnings", "all the generic issues and
warnings", etc.) clarify the intent of the reference.

  However, hiding does not always work.  Sometimes EDNS(0) Client
  subnet [RFC7871] is used (see its privacy analysis in
  [denis-edns-client-subnet]).  [...]

(nit) The wording here ("its privacy analysis") suggests that the
referenced document is an authoritative/official IETF position, but it
seems to be a blog post by a single individual.  Using "one" or "a"
rather than "its" would convey a less-authoritative connotation.

                                      In both cases, the IP address
  originating queries to the authoritative server is as sensitive as it
  is for HTTP [sidn-entrada].

I don't see how [sidn-entrada] supports the claim that end-user-adjacent
DNS client IP addresses are equally sensitive as HTTP client IP
Addresses; it mentions "sensitive" only twice (as "privacy-sensitive",
admittedly, applying to such IP addresses, but as an assertion without
justification) and "http" only in URLs (mostly in the references) and as
an example request.  It would feel more natural to use an IETF reference
here, as well -- e.g., RFC 7624 discusses correlating client IP
addresses with end users, RFC 7239 clearly covers privacy considerations
for sending client IP addresses in the "forwarded" header field, and
there are no doubt others -- though I do note the contents of the
paragraph after this one.

                    However, for both IPv4 and IPv6 addresses, it is
  important to note that source addresses are propagated with queries
  and comprise metadata about the host, user, or application that
  originated them.

(This "propagated with queries" is still contingent on EDNS(0) Client
Subnet from the previous paragraph, right?)

Section 4.2.1

  cache poisoning attacks by off-path attackers.  It is noted, however,
  that they are designed to just verify IP addresses (and should change
  once a client's IP address changes), they are not designed to
  actively track users (like HTTP cookies).

nit: comma splice.

Section 5.1

  not be.  When other protocols will become more and more privacy-aware
  and secured against surveillance (e.g., [RFC8446],
  [I-D.ietf-quic-transport]), the use of unencrypted transports for DNS
  may become "the weakest link" in privacy.  It is noted that at the
  time of writing there is on-going work attempting to encrypt the SNI
  in the TLS handshake [I-D.ietf-tls-sni-encryption].

This mention of encrypted "SNI" (now encrypted ClientHello) comes as a
bit of a non sequitur.  I suggest a bit of transition such as an
additional clause at the end of the sentences ", which is one of the
last remaning non-DNS cleartext identifiers of a connection target".
(While the actual work itself has progressed to encrypting the entire
ClientHello, I think it's okay to focus the exposition here on the SNI,
as the relevant attribute.)

                                                        It can be noted
      that if the user selects a single resolver with a small client
      population (even when using an encrypted transport) it can
      actually serve to aid tracking of that user as they move across
      network environment.

I wonder if it is worth adding another clause at the end: ", and that an
attacker in a position to observe the moving user is likely also able to
observe the likely-unencrypted DNS queries from the resolver to the
authoritative servers"
Also, nit: "environments" plural.

Section 5.2

  Traffic analysis of unpadded encrypted traffic is also possible
  [pitfalls-of-dns-encryption] because the sizes and timing of
  encrypted DNS requests and responses can be correlated to unencrypted
  DNS requests upstream of a recursive resolver.

We could (but don't have to) note that effective padding policies remain
an open area of research.

Section 6.1.1.2

  o communicate clearly the change in default to users

I think this is intending to say "when the default application resolver
changes away from the system resolver", but the present text is perhaps
a little unclear about what "the change" is referring to.

Section 6.1.2

                                                                Even if
  encrypted DNS such as DoH or DoT is used, unless the client has been
  configured in a secure way with the server identity, an active
  attacker can impersonate the server.  [...]

More than the server identity is needed -- the credentials or trust
anchor needed to authenticate a peer as that identity are also needed.

Section 6.1.3

  User privacy can also be at risk if there is blocking (by local
  network operators or more general mechanisms) of access to remote
  recursive servers that offer encrypted transports when the local
  resolver does not offer encryption and/or has very poor privacy
  policies.  [...]

I suggest adding "e.g." before "when the local resolver" to avoid giving
the impression that this is an exhaustive list.

  This is a form of Rendezvous-Based Blocking as described in
  Section 4.3 of [RFC7754].  Such blocklists often include servers know
  to be used for malware, bots or other security risks.  In order to
  prevent circumvention of their blocking policies, some networks also
  block access to resolvers with incompatible policies.

Perhaps this is touching too much on the controversial topic, but it
seems to me that the networks in question "attempt to block access";
whether or not they fully and reliably succeed at doing so is not clear.
(See also the near-impossibility of closing covert channels in
protocols.)

  It is also noted that attacks on remote resolver services, e.g., DDoS
  could force users to switch to other services that do not offer
  encrypted transports for DNS.

nit: comma after DDoS.

Section 6.1.4.2

  Some implementations have, in fact, chosen to restrict the use of the
  'User-Agent' header so that resolver operators cannot identify the
  specific application that is originating the DNS queries.

With similar disclaimer as previously, perhaps "trivially identify"?
There are other fingerprinting techniques possible even at, e.g., the TLS
layer (that we discussed previously in this document!), which still
apply to DoH.

Section 6.2

  This "protection", when using a large resolver with many clients, is
  no longer present if ECS [RFC7871] is used because, in this case, the
  authoritative name server sees the original IP address (or prefix,
  depending on the setup).

(side note) this has always been a bit confusing to me -- ECS is "client
subnet", not "client address", and I don't really understand why someone
would set the prefix length to the full 128 (or 32) bits of the address.
Is there really a lot of non-truncated client addresses being sent
around like this?  How did that happen?

                                                                    So,
  requests to a given ccTLD may go to servers managed by organizations
  outside of the ccTLD's country.  End users may not anticipate that,
  when doing a security analysis.

(Is this a "for example"?  It seems plausibly relevant for non-cc TLDs
as well.)

Section 7.1

  The IAB privacy and security program also have a work in progress
  [RFC7624] that considers such inference-based attacks in a more
  general framework.

I do not really think the final RFC constitutes a "work in progress"
anymore.

Section 8

  Passive DNS systems [passive-dns] allow reconstruction of the data of
  sometimes an entire zone.  They are used for many reasons -- some
  good, some bad.  Well-known passive DNS systems keep only the DNS
  responses, and not the source IP address of the client, precisely for
  privacy reasons.  Other passive DNS systems may not be so careful.

Perhaps not so well-intentioned, either...

  The revelations from the Edward Snowden documents, which were leaked
  from the National Security Agency (NSA) provide evidence of the use

nit: comma after "(NSA)".

Section 9

  To our knowledge, there are no specific privacy laws for DNS data, in
  any country.  Interpreting general privacy laws like
  [data-protection-directive] or GDPR [10] applicable in the European
  Union in the context of DNS traffic data is not an easy task, and we
  do not know a court precedent here.  See an interesting analysis in
  [sidn-entrada].

This text is essentially unchanged since RFC 7626; did we do much of a
search for whether the past five years have brought about changes in the
legal landscape?

[Ballot comment]
[[ questions ]]

[ section 6.1.1.1 ]

* Does "Strict DoT" have a definition somewhere?  I couldn't find one
  in 8499 nor in 7858.


[[ nits ]]

[ section 1 ]

* "sent in clear", consider perhaps: "sent in the clear"

[ section 4.1 ]

* "those transaction" -> "those transactions"

[ section 6.1.1 ]

* "to limited subset" -> "to a limited subset"

[ section 6.1.3 ]

* "know to be used" -> "known to be used"

[Ballot discuss]
Apologies for changing my YES to a DISCUSS -- I found a later version of my notes on this draft.

My DISCUS is specifically around the"The Alleged Public Nature of DNS Data" / "It has long been claimed that "the data in the DNS is public" section -- it seems to be unnecessarily creating and then shooting down a strawman. The "the data in the DNS is public" aphorism talks is more about the confidentiality one can expect **publishing** data in the DNS, not the privacy of the lookups.  This whole section (to my mind) undersells the threat that publishing something in the DNS and expecting it to remain private creates -- for example, I'd be extremely foolish to insert:
my-password-fd345432233e.example.com 600 IN TXT "Hunter2"

Services like Farsight Securities (excellent!) DNSDB will likely capture this almost as soon as I use it somewhere.
In addition, the "Due to the lack of search capabilities, only a given QNAME will reveal the resource records associated with that name" sentence is either false, or at the very least, misleading.

$ dig +dnssec foo.ietf.org | grep NSEC
clearly tells me that the names etherpad.ietf.org and ftp.ietf.org both exist, and
$ dig +dnssec ftpa.ietf.org | grep NSEC
tells me that the next name is guides.ietf.org....

I think that the last 4 or 5 sentences of the section are useful, but that the rest of the section is actively dangerous as it is likely to be misunderstood.

Please don't misunderstand - I still believe that the document itself is really important and useful, but the section seems dangerous (and yes, I realize that it is in RFC7626)

[Ballot discuss]
Apologies for changing my YES to a DISCUSS -- I found a later version of my notes on this draft.

My DISCUS is specifically around the"The Alleged Public Nature of DNS Data" / "It has long been claimed that "the data in the DNS is public" section -- it seems to be unnecessarily creating and then shooting down a strawman. The "the data in the DNS is public" aphorism talks is more about the confidentiality one can expect **publishing** data in the DNS, not the privacy of the lookups.  This whole section (to my mind) undersells the threat that publishing something in the DNS and expecting it to remain private creates -- for example, I'd be extremely foolish to insert:
my-password-fd345432233e.example.com 600 IN TXT "Hunter2"

Services like Farsight Securities (excellent!) DNSDB will likely capture this almost as soon as I use it somewhere.
In addition, the "Due to the lack of search capabilities, only a given QNAME will reveal the resource records associated with that name" sentence is either false, or at the very least, misleading.

$ dig +dnssec foo.ietf.org | grep NSEC
clearly tells me that the names etherpad.ietf.org and ftp.ietf.org both exist, and
$ dig +dnssec ftpa.ietf.org | grep NSEC
tells me that the next name is guides.ietf.org....

I think that the last 4 or 5 sentences of the section are useful, but that the rest of the section is actively dangerous as it is likely to be misunderstood...

Please don't misunderstand - I still believe that the document itself is really important and useful, but the section seems dangerous.

[Ballot comment]
[Edit: I accidentally hit "Send" too early; I have another few comments, also non-blocking:
1: "Also, sometimes, the QNAME embeds the software one uses, which could be a privacy issue. For instance, _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.example.org."... Unless you are a Microsoft or DNS weenie, this is likely not at clear -- what is being leaked here? The fact that the site uses TCP? LDAP? Windows? Goldbach's Conjecture? Example software? (I think adding a sentence here would be helpful...)
]

Thank you for this document - it's really useful, and readable as well.

I do have a few small comments to (possibly) make it even better - I will in no way be offended if you ignore these...

The background on how DNS works is nicely written, and I'm to point people at it when I need to explain how the DNS works -- but I think a better name example than:
"What are the SRV records of _xmpp-server._tcp.example.com?" would be good -- SRV is an unusual record type, and names with underscores surprise people. I'd instead suggest "What is the MX records for example.com" or "What is the A record for ftp.example.com?" -- I'm only mentioning this because the rest of the section is a very general introduction and this might confuse newcomers...

"At the time of writing, almost all this DNS traffic is currently sent in clear (i.e., unencrypted). However there is increasing deployment of DNS-over-TLS (DoT) [RFC7858] and DNS-over-HTTPS (DoH) [RFC8484], particularly in mobile devices, browsers, and by providers of anycast recursive DNS resolution services."
I think that you might want to remove the "particularly in ..." - I suspect that it will not age well; the document does say "At the time of writing" and "increasing", etc., but this document is likely foundational enough that it will still be referenced many many years from now, and this text may just cloud matters then.

Whatever the case, thanks again for this document!

[Ballot comment]
Thank you for this document - it's really useful, and readable as well.

I do have a few small comments to (possibly) make it even better - I will in no way be offended if you ignore these...

The background on how DNS works is nicely written, and I'm to point people at it when I need to explain how the DNS works -- but I think a better name example than:
"What are the SRV records of _xmpp-server._tcp.example.com?" would be good -- SRV is an unusual record type, and names with underscores surprise people. I'd instead suggest "What is the MX records for example.com" or "What is the A record for ftp.example.com?" -- I'm only mentioning this because the rest of the section is a very general introduction and this might confuse newcomers...

"At the time of writing, almost all this DNS traffic is currently sent in clear (i.e., unencrypted). However there is increasing deployment of DNS-over-TLS (DoT) [RFC7858] and DNS-over-HTTPS (DoH) [RFC8484], particularly in mobile devices, browsers, and by providers of anycast recursive DNS resolution services."
I think that you might want to remove the "particularly in ..." - I suspect that it will not age well; the document does say "At the time of writing" and "increasing", etc., but this document is likely foundational enough that it will still be referenced many many years from now, and this text may just cloud matters then.

Whatever the case, thanks again for this document!

[Ballot comment]
It would have been nice to include a narrative section indicating the differences with respect to rfc7626.  Maybe turn the bullets in §14 into a short explanation of the major changes.

[Ballot comment]
Hi,

Thank you for this document.  I found it interesting and easy to read.

A few minor comments/nits that I spotted whilst reading this document:

"in clear (i.e., unencrypted)." => "unencrypted."
"However there is" => "However, there is"
"designed for TCP, not UDP and new" => "designed for TCP, not UDP, and new"
"It can be noted also that" => "It can also be noted that"
"Both are a big privacy concern" => "Both are significant privacy concerns"
"de-NAT DNS queries dns-de-nat [3]" => "de-NAT DNS queries [3]"?

Regards,
Rob

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This document is intended as an Informational RFC. Informational is indicated in the title page header. The document describes a series of potential privacy issues that should be considered by operators, developers, and users of the DNS. The document does not describe protocol operations or recommendations for operating or using the DNS. As such, Informational is the proper type.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  This document describes the privacy issues associated with the use of
  the DNS by Internet users.  It is intended to be an analysis of the
  present situation and does not prescribe solutions.  This document
  obsoletes RFC 7626.

Working Group Summary:

As privacy aspects differ between readers, there was significant discussions over what issues warranted mention in the document, especially as a -bis document. The resulting content represents the key aspects that the WG felt was important to document on privacy matters related to DNS.

Document Quality:

This document received a number of reviews from a variety of stakeholder communities. The shepherd considers the document solid and worthy of publication.

Personnel:

Who is the Document Shepherd? Brian Haberman
Who is the Responsible Area Director? Éric Vyncke

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd performed two types of reviews of the document. The first review focused on the process-related aspects of publishing
an RFC, including the existence of any nits. The document is structured accordingly for an Informational document. The document does contain
references to two drafts that have been revised since the publication of this version of the draft. Those references will be rectified
when an updated version of this draft is published.

The second review performed on the document focused on assessing that all comments and issues raised during the WG process were addressed.
The shepherd reviewed all comments made during the WGLC as well as comments raised on the mailing list during development of the draft.
The shepherd is comfortable that the authors addressed all issues raised within the WG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

As this is a revision of an existing RFC focused on privacy issues, it would be beneficial to have someone with an in-depth knowledge
of privacy issues to review the document before/during IETF Last Call.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is strong consensus within the WG for the contents of this document. A vocal minority have voiced issues with parts of the document that potentially relate to possible work
within the proposed ADD/ABCD working group. The shepherd believes that this document captures the current privacy issues related to DNS.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

As noted in (3), this document references two drafts that have newer versions published since the publication of this draft.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This document obsoletes RFC 7626. The header correctly identifies that action as does the Abstract. That information is not in the Introduction.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

N/A.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

N/A.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A.

(BEGIN IANA COMMENTS)

IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-dprive-rfc7626-bis-04, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

(END IANA COMMENTS)

The following Last Call announcement was sent out (ends 2020-02-03):

From: The IESG
To: IETF-Announce
CC: brian@innovationslab.net, draft-ietf-dprive-rfc7626-bis@ietf.org, Brian Haberman , dprive-chairs@ietf.org, dns-privacy@ietf.org, evyncke@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (DNS Privacy Considerations) to Informational RFC


The IESG has received a request from the DNS PRIVate Exchange WG (dprive) to
consider the following document: - 'DNS Privacy Considerations'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-02-03. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes the privacy issues associated with the use of
  the DNS by Internet users.  It is intended to be an analysis of the
  present situation and does not prescribe solutions.  This document
  obsoletes RFC 7626.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/ballot/


No IPR declarations have been submitted directly on this I-D.

The previous last call raised several points. The authors have worked on those points and this new informational IETF draft has substantive changes; enough to go trigger a new IETF Last Call.

-éric

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-dprive-rfc7626-bis-03, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Amanda Baber
IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-12-02):

From: The IESG
To: IETF-Announce
CC: brian@innovationslab.net, draft-ietf-dprive-rfc7626-bis@ietf.org, Brian Haberman , dprive-chairs@ietf.org, dns-privacy@ietf.org, evyncke@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (DNS Privacy Considerations) to Informational RFC


The IESG has received a request from the DNS PRIVate Exchange WG (dprive) to
consider the following document: - 'DNS Privacy Considerations'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2019-12-02. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes the privacy issues associated with the use of
  the DNS by Internet users.  It is intended to be an analysis of the
  present situation and does not prescribe solutions.  This document
  obsoletes RFC 7626.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This document is intended as an Informational RFC. Informational is indicated in the title page header. The document describes a series of potential privacy issues that should be considered by operators, developers, and users of the DNS. The document does not describe protocol operations or recommendations for operating or using the DNS. As such, Informational is the proper type.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  This document describes the privacy issues associated with the use of
  the DNS by Internet users.  It is intended to be an analysis of the
  present situation and does not prescribe solutions.  This document
  obsoletes RFC 7626.

Working Group Summary:

As privacy aspects differ between readers, there was significant discussions over what issues warranted mention in the document, especially as a -bis document. The resulting content represents the key aspects that the WG felt was important to document on privacy matters related to DNS.

Document Quality:

This document received a number of reviews from a variety of stakeholder communities. The shepherd considers the document solid and worthy of publication.

Personnel:

Who is the Document Shepherd? Brian Haberman
Who is the Responsible Area Director? Éric Vyncke

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd performed two types of reviews of the document. The first review focused on the process-related aspects of publishing
an RFC, including the existence of any nits. The document is structured accordingly for an Informational document. There are two issues
related to the -02 version of the draft that can be fixed when necessary. The draft does not currently contain an IANA Considerations
section. However, the document makes no requests of IANA and the section would be removed prior to final publication as an RFC. The document
also contains references to three drafts that have been revised since the publication of this version of the draft. Those will be rectified
when an updated version of this draft is published.

The second review performed on the document focused on assessing that all comments and issues raised during the WG process were addressed.
The shepherd reviewed all comments made during the WGLC as well as comments raised on the mailing list during development of the draft.
The shepherd is comfortable that the authors addressed all issues raised within the WG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

As this is a revision of an existing RFC focused on privacy issues, it would be beneficial to have someone with an in-depth knowledge
of privacy issues to review the document before/during IETF Last Call.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There strong consensus within the WG for the contents of this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

As noted in (3), this document does not currently contain an IANA Considerations section, but none is needed. The document also
references three drafts that have newer versions published since the publication of this draft.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This document obsoletes RFC 7626. The header correctly identifies that action as does the Abstract. That information is not in the Introduction.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

N/A.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

N/A.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This document is intended as an Informational RFC. Informational is indicated in the title page header. The document describes a series of potential privacy issues that should be considered by operators, developers, and users of the DNS. The document does not describe protocol operations or recommendations for operating or using the DNS. As such, Informational is the proper type.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  This document describes the privacy issues associated with the use of
  the DNS by Internet users.  It is intended to be an analysis of the
  present situation and does not prescribe solutions.  This document
  obsoletes RFC 7626.

Working Group Summary:

As privacy aspects differ between readers, there was significant discussions over what issues warranted mention in the document, especially as a -bis document. The resulting content represents the key aspects that the WG felt was important to document on privacy matters related to DNS.

Document Quality:

This document received a number of reviews from a variety of stakeholder communities. The shepherd considers the document solid and worthy of publication.

Personnel:

Who is the Document Shepherd? Brian Haberman
Who is the Responsible Area Director? Éric Vyncke

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd performed two types of reviews of the document. The first review focused on the process-related aspects of publishing
an RFC, including the existence of any nits. The document is structured accordingly for an Informational document. There are two issues
related to the -02 version of the draft that can be fixed when necessary. The draft does not currently contain an IANA Considerations
section. However, the document makes no requests of IANA and the section would be removed prior to final publication as an RFC. The document
also contains references to three drafts that have been revised since the publication of this version of the draft. Those will be rectified
when an updated version of this draft is published.

The second review performed on the document focused on assessing that all comments and issues raised during the WG process were addressed.
The shepherd reviewed all comments made during the WGLC as well as comments raised on the mailing list during development of the draft.
The shepherd is comfortable that the authors addressed all issues raised within the WG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

As this is a revision of an existing RFC focused on privacy issues, it would be beneficial to have someone with an in-depth knowledge
of privacy issues to review the document before/during IETF Last Call.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There strong consensus within the WG for the contents of this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

As noted in (3), this document does not currently contain an IANA Considerations section, but none is needed. The document also
references three drafts that have newer versions published since the publication of this draft.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This document obsoletes RFC 7626. The header correctly identifies that action as does the Abstract. That information is not in the Introduction.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

N/A.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

N/A.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A.