Skip to main content

Telechat Review of draft-ietf-dnsop-rfc7816bis-10
review-ietf-dnsop-rfc7816bis-10-intdir-telechat-combes-2021-08-20-00

Request Review of draft-ietf-dnsop-rfc7816bis
Requested revision No specific revision (document currently at 11)
Type Telechat Review
Team Internet Area Directorate (intdir)
Deadline 2021-08-20
Requested 2021-07-29
Requested by Éric Vyncke
Authors Stéphane Bortzmeyer , Ralph Dolmans , Paul E. Hoffman
I-D last updated 2021-08-20
Completed reviews Genart Last Call review of -09 by Suhas Nandakumar (diff)
Opsdir Last Call review of -09 by Qin Wu (diff)
Secdir Last Call review of -09 by Donald E. Eastlake 3rd (diff)
Artart Telechat review of -10 by Valery Smyslov (diff)
Intdir Telechat review of -10 by Jean-Michel Combes (diff)
Comments
While this I-D is about DNS, I would prefer to have a non-DNS expert to review this document. Thank you. Eric
Assignment Reviewer Jean-Michel Combes
State Completed
Request Telechat review on draft-ietf-dnsop-rfc7816bis by Internet Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/int-dir/zaJO0vt9ix9vZ3o54Nfug26lk6U
Reviewed revision 10 (document currently at 11)
Result Ready w/nits
Completed 2021-08-20
review-ietf-dnsop-rfc7816bis-10-intdir-telechat-combes-2021-08-20-00
Hi,

Please find my review, as member of the INT Area Directorate, of the following
document:

<review>

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

<snip>

1.  Introduction and Background

   The problem statement for this document is described in [RFC7626].

<JMC>
s/[RFC7626]/[RFC9076]
</JMC>

<snip>

1.1.  Experience From RFC 7816

   This document obsoletes [RFC7816].  RFC 7816 was labelled
   "experimental", but ideas from it were widely deployed since its
   publication.  Many resolver implementations now support QNAME
   minimisation.  The lessons learned from implementing QNAME
   minimisation were used to create this new revision.

<JMC>
Maybe, another argument to move to “Standards Track”:
For the moment, Root Server Operators do not feel comfortable with
authoritative DNS encryption. They encourage the increased deployment of QNAME
minimisation [REF_informative].

[REF_informative]
https://root-servers.org/media/news/Statement_on_DNS_Encryption.pdf </JMC>

<snip>

5.  Performance Considerations

<snip>

   QNAME minimisation can increase the number of queries based on the
   incoming QNAME.  This is described in Section 2.3.  As described in
   [devries-qnamemin], QNAME minimisation in strict mode both increases
   the number of DNS lookups by up to 26% and leads to up to 5% more
   failed lookups.  The full cache in a production resolver will soften
   that overhead.

<JMC>
I didn’t find any definition/explanation about “strict mode” of QNAME
minimization inside this document. There is no definition/explanation about
strict (and relaxed) mode(s) inside [devries-qnamemin] too. So, I don’t
understand how is useful this paragraph for the document. May you clarify this
point, please? </JMC>

6.  Security Considerations

   QNAME minimisation's benefits are clear in the case where you want to
   decrease exposure to the authoritative name server.  But minimising
   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.
   (Encryption is of course a better defense against wire sniffers, but,
   unlike QNAME minimisation, it changes the protocol and cannot be
   deployed unilaterally.  Also, the effect of QNAME minimisation on
   wire sniffers depends on whether the sniffer is on the DNS path.)

<JMC>
Maybe, my comment about Root Servers Operators (cf. Section 1.1) may be used to
illustrate the difficulty to deploy encryption everywhere. </JMC>

<snip>
</review>

Thanks in advance for your replies.

Best regards,

JMC.