Subject: [DNSOP] New version of draft-ietf-dnsop-rfc7816bis after WG last call

From: Paul Hoffman <[email-masked]>
Date: Thu, 15 Apr 2021 23:15:15 +0000

Greetings again. We have posted a very delayed version draft-ietf-dnsop-rfc7816bis that we believe answers all of the issues brought up during WG last call. There are a lot of significant changes from the previous version.

Everyone (but particularly resolver developers): please review the document carefully, particularly the algorithm in Section 3, to see if it matches what you expect.

Chairs: please consider either having another WG last call, or at least waiting for a bit before moving this to IETF last call so that we can get careful reviews. 

--Paul Hoffman, for the authors team

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 19 Apr 2021 12:19:13 +0000

> -----Original Message-----
> From: DNSOP <[email-masked]> On Behalf Of Paul Hoffman
> Sent: Thursday, April 15, 2021 7:15 PM
> To: DNSOP Working Group <[email-masked]>
> Subject: [EXTERNAL] [DNSOP] New version of draft-ietf-dnsop-rfc7816bis
> after WG last call
>
> Greetings again. We have posted a very delayed version draft-ietf-dnsop-
> rfc7816bis that we believe answers all of the issues brought up during WG
> last call. There are a lot of significant changes from the previous version.
>
> Everyone (but particularly resolver developers): please review the document
> carefully, particularly the algorithm in Section 3, to see if it matches what you
> expect.

Thanks for the update! I have a few minor suggestions after re-reading the draft.

Section 1.1: "Academic research has been performed on QNAME minimisation [devries-qnamemin].  This work shows that QNAME minimisation in relaxed mode causes almost no problems." It would be helpful to note the issues that the paper described, perhaps as follows:

"This work shows that QNAME minimisation in relaxed made causes almost no problems; some of the issues that have been observed are described in Section 5."

Section 5: It's worth noting the performance issues reported in [devries-qnamemin]. Suggestion:

OLD:
QNAME minimisation can increase the number of queries based on the incoming QNAME.  This is described in Section 2.3.

NEW:
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.

Scott

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 20 Apr 2021 18:45:15 +0000

> 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 incr…

This seems fine; thanks! We'll add it to the next draft.

--Paul Hoffman

---

From: Tim Wicinski <[email-masked]>
Date: Tue, 20 Apr 2021 16:20:56 -0400

Paul

Thanks for the updated version.    For those at home, the diffs are
https://www.ietf.org/rfcdiff?url1=draft-ietf-dnsop-rfc7816bis-07&url2=draft-ietf-dnsop-rfc7816bis-08

The Chairs would like the working group to review these changes.  We're
looking for comments
before Monday April 26th.

thanks
tim

On Thu, Apr 15, 2021 at 7:15 PM Paul Hoffman <[email-masked]> wrote:

> Greetings again. We have posted a very delayed version
> draft-ietf-dnsop-rfc7816bis that we believe answers all of the issues
> brought up during WG last call. There are a lot of significant changes from
> the previous version.
>
> Everyone (but particularly resolver developers): please review the
> document carefully, particularly the algorithm in Section 3, to see if it
> matches what you expect.
>
> Chairs: please consider either having another WG last call, or at least
> waiting for a bit before moving this to IETF last call so that we can get
> careful reviews.
>
> --Paul Hoffman, for the authors
> team_______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Peter van Dijk <[email-masked]>
Date: Wed, 21 Apr 2021 10:20:33 +0200

Hello Paul,

> Everyone (but particularly resolver developers): please review the document carefully, particularly the algorithm in Section 3, to see if it matches what you expect.

PowerDNS implementation notes: 
* we combined step 5 and step 6d (and call it step 5); we fall back to 'no minimisation' on anything that's not a NoError response (but the fallback might be handled by the RFC8020 code, especially if that non-NoError response was NXDOMAIN) (the default for RFC8020 is 'on signed domains only')
* we use 1-1-1-3-3-.. label steps, which is not exactly what section 2.3 describes

(you can find some more details at https://doc.powerdns.com/recursor/appendices/internals.html#qname-minimization )

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: Vladimír Čunát <[email-masked]>
Date: Mon, 26 Apr 2021 19:28:26 +0200

> We're looking for comments before Monday April 26th. 

I'm sorry.  Better slightly late than never, I suppose.  The whole text 
seems good to me, except for a small issue:

In step (6) of the algorithm it might better be noted that in case xNAME 
is in ANSWER, the RCODE is irrelevant.  Now the reading doesn't seem 
right e.g. if it returns a CNAME to an NXDOMAIN.

> * we use 1-1-1-3-3-.. label steps, which is not exactly what section 2.3 describes

I consider that part of the draft as just an example how the number of 
queries could be reduced, so I can't see any problem.

In the stub&forwarding section it might be worth noting the case of 
validating stub or forwarder.  There the final query does not suffice 
regardless of (non-)minimization, so the QNAME minimization approach can 
be "coupled" with a root-to-leaf direction of discovering the trust 
chain.  We've been using one simple approach from this class for years 
(as the only option for forwarding with validation).

--Vladimir | knot-resolver.cz

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 30 Apr 2021 15:33:53 -0400

All

The 26th has come and gone, and we've seen some cleanup in the updated
text, and the authors have uploaded a new version.
The chairs are calling the WGLC done, and I will start the shepherd process
later today.

Authors, thanks for your patience.

tim