DNS Query Name Minimisation to Improve Privacy
draft-ietf-dnsop-rfc7816bis-11

[S2.1 comment]

* It seems to me that using A QTYPEs for Happy Eyeballs clients is
  only a "potential benefit" for an IPv4 connection setup, and does
  nothing to aid any possible IPv6 connection setup.

  There are networks with IPv6-only clients accessing mostly
  IPv6-reachable services for which this might actually slow down
  services (by delaying AAAA resolution resulting in an IPv4
  connection setup that uses something like NAT64 rather than
  native IPv6).

  Suggestion 1: Just trim these HE-related sentences.

  Suggestion 2: Make it clear that this might not always be a "benefit"
                in certain network deployments.

Thank you to Donald Eastlake for the SECDIR review.

The discussion about how many labels to add at each step is rather
spread out amongst Sections 2, 2.3, and 3, and my preference would be to
have a single more-clear specification of behavior for the Proposed
Standard level of publication (but this is just a non-blocking comment
and I recognize that addressing it would require somewhat invasive
changes to the text).

Looking over the diff from RFC 7816, I see that the discussion of empty
non-terminals has been removed.  Is that because the prevalence of
servers that fail to handle them properly in the wild has dropped to an
insignificant level?  (If so, hooray!)  If not, why was the text
removed?

We also removed the discussion of "some broken name servers [that] do
not react properly to QTYPE-NS requests", which is mostly understandable
since we no longer recommend that NS is used as the QTYPE for masking
minimized requests.  I don't know if it's worth retaining this warning
in some form as it might apply to legacy implementations that retain the
RFC 7816 behavior.

Thanks to Donald Eastlake for the secdir review.

I echo the intdir reviewer's question about where "strict mode" of QNAME
minimization is defined.

I also see the genart reviewer's question about whether the number of
labels per iteration can remain large after the division, and I think
that the maximum allowed length of a domain name helps some here, but
would appreciate if someone more familiar with the actual limits ran the
numbers and opined that the resulting number of labels is capped at some
reasonable bound.

Abstract

If the note about the WG and git source is expected to be removed before
publication as an RFC, it seems prudent to note that somewhere (whether
in the visible prose or as a comment in the XML).

Section 2.1

   The QTYPE to use while minimising queries can be any possible data
   type (as defined in [RFC6895] Section 3.1) for which the authority
   always lies below the zone cut (i.e. not DS, NSEC, NSEC3, OPT, TSIG,
   TKEY, ANY, MAILA, MAILB, AXFR, and IXFR), as long as there is no
   relation between the incoming QTYPE and the selection of the QTYPE to
   use while minimising.  [...]

At risk of being overly pedantic, the procedure will still get you the
right answer even if there is a relation between the incoming and
selected QTYPE, so the "can be ... as long as" isn't quite correct.  We
insist on the lack of relationship because that gives better privacy
properties, not because it is required for correct behavior, as I
understand it.

Section 3

   (3) If CHILD is the same as QNAME, or if CHILD is one label shorter
       than QNAME and the original QTYPE can only be at the parent side
       (like QTYPE=DS), resolve the original query as normal starting
       from ANCESTOR's name servers.  Start over from step 0 if new
       names need to be resolved as result of this answer, for example
       when the answer contains a CNAME or DNAME record.

We might want to reference RFC 6672 for DNAME (since we use it later in
step 6 as well).

Section 6

   the amount of data sent also, in part, addresses the case of a wire
   sniffer as well as the case of privacy invasion by the servers.

Who are "the servers"?

Section 7.1

It seems rather unconventional to make a normative reference to the
document being obsoleted (RFC 7816).  It seems like that document would
be more appropriately classified as an informative reference.

Section 7.2

Deferring to RFC 8499 for terminology definitions may well merit
classifying it as a normative reference.


NITS

Thanks for putting the git repo link in the Abstract.  Since I only have
a proposed wording for one of these I didn't go through the effort of
phrasing it in the form of a patch, but it's nice to have the option
available.

Section 3

   (4) Otherwise, add the next relevant label or labels from QNAME to
       the start of CHILD.  The number of labels to add is discussed in
       Section 2.3.

It might be worth being a little more explicit that this is updating the
current value of CHILD, as opposed to producing a new temporary value
consisting of (next relevant label or labels)+CHILD.  (E.g., "Update the
value of CHILD to consist of [...]".)

Section 4

   have been A.  Using the most used QTYPE to hide the original QTYPE
   therefore slightly reduces the number of outgoing queries.

I'd probably say "compared to using any other QTYPE to hide the original
QTYPE".

Section 6

   QNAME minimisation's benefits are clear in the case where you want to
   decrease exposure to the authoritative name server.  But minimising

I'd probably clarify "exposure of what?".