Subject: [Int-dir] Intdir telechat review of draft-ietf-dnsop-rfc7816bis-10

From: Jean-Michel Combes via Datatracker <[email-masked]>
Date: Fri, 20 Aug 2021 13:12:04 -0700

Reviewer: Jean-Michel Combes
Review result: Ready with Nits

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.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 25 Aug 2021 06:22:22 +0000

Merci Jean-Michel

Your detailed review helped me to focus on other aspects of the I-D (raising a DISCUSS for an IPv6 issue BTW).

The authors should also address your comments.

Regards

-éric

-----Original Message-----
From: Int-dir <[email-masked]> on behalf of Jean-Michel Combes via Datatracker <[email-masked]>
Reply-To: Jean-Michel Combes <[email-masked]>
Date: Friday, 20 August 2021 at 22:12
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [Int-dir] Intdir telechat review of draft-ietf-dnsop-rfc7816bis-10

    Hi,

    <review>

    <snip>

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

    <snip>

    <JMC>

    [REF_informative]

    <snip>

    <snip>

    <JMC>

    <JMC>

    <snip>
    </review>

    Best regards,

    JMC.

    _______________________________________________
    Int-dir mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/int-dir