Subject: Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc7816bis

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 5 Nov 2020 16:27:46 +0000

I support publication of this document. I do have some "last call" feedback to share:

Section 2, paragraph 4 states that "A resolver that implements QNAME minimisation changes the QNAME and QTYPE in queries directed to an authoritative nameserver that is not known to be responsible for the original QNAME". This is true, except when the QNAME and/or QTYPE are already in the preferred form. For instance, if the resolver prefers to send QTYPE=A, and the client has requested QTYPE=A, then no change is needed.  For similar reasons, the change does not necessarily "hide" the QTYPE, but rather prevents an observer from distinguishing queries of one type from another.  Suggested changes:

"changes the QNAME and QTYPE" -> "obscures the QNAME and QTYPE"
"to hide the original QTYPE" -> "to obscure the original QTYPE"

Section 2.3, last paragraph: I believe the intent of this paragraph is to show how many labels to add during each iteration, but it would benefit from further precision.  These questions stand out:

"The number of QNAME minimization iterations is the difference between this closest nameserver and the incoming QNAME". This should read "… the delegation point for this closest nameserver", correct?  But this isn’t the number of iterations in any case, it’s the number of labels that are still not exposed. It’s only the number of iterations if it's less than or equal to MAX_MINIMIZE_COUNT.

"The number of labels that are not exposed yet now need to be divided over the iterations that are left (MAX_MINIMISE_COUNT – MINIMISE_ONE_LAB). The remainder of the division should be added to the last iteration". True, but this overlooks all the iterations in between.   Based on the example, I’m assuming the idea is to allocate the labels that are left proportionally to the remaining iterations, rounding down.

The text should also state whether the algorithm is mandatory or optional. 2119 key words would be helpful.

Minor edits:

Section 1.1, paragraph 1:  "publicaiton" -> "publication"
Section 2.3, last paragraph:  "handles" -> "handled"

Scott

---

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 5 Nov 2020 18:50:47 +0000

All,

I have a few comments, focusing on the algorithm in section 3.

> 3.  Algorithm to Perform QNAME Minimisation
> 
>   This algorithm performs name resolution with QNAME minimisation in
>   the presence of zone cuts that are not yet known.
> 
>   Although a validating resolver already has the logic to find the
>   zone cuts, implementers of resolvers may want to use this algorithm
>   to locate the zone cuts.
> 
>   (0)  If the query can be answered from the cache, do so; otherwise,
>       iterate as follows:
> 
>   (1)  Get the closest delegation point that can be used for the
>       original QNAME/QTYPE combination from the cache.

Shouldn't that be just "original QNAME" since the QTYPE should be irrelevant
in locating zone cuts and delegation points?

> 
>       (1a)  For queries with QTYPE=DS this is the NS RRset with the
>            owner matching the most labels with the QNAME stripped by
>            one label.  The QNAME will be a subdomain of (but not equal
>            to) this NS RRset.  Call this ANCESTOR.

How confident are we that DS will remain the only RR with parent-side
authoritative data?  There was recently a proposal
(draft-peetterr-dnsop-parent-side-auth-types) to reserve a range for types
with this property, but I guess it was pretty quickly shot down.  If a new
authoritative-in-parent RR type is defined in the future, then would it
need to update this specification?

> 
>       (1b)  For queries with other original QTYPEs this is the NS RRset
>            with the owner matching the most labels with the QNAME.  The
>            QNAME will be equal to or a subdomain of this NS RRset.
>            Call this ANCESTOR.
> 
>   (2)  Initialise CHILD to the same as ANCESTOR.
> 
>   (3)  If CHILD is the same as the QNAME, or if the CHILD is one label
>       shorter than the QNAME and the original QTYPE is DS, resolve the
>       original query using ANCESTOR's name servers, and finish.

Throughout this section (and maybe elsewhere) the document should be
consistent with "the CHILD" and "the QNAME" or just "CHILD" and "QNAME".
My suggestion is to drop "the".

> 
>   (4)  Otherwise, add a label from the QNAME to the start of CHILD.

I'd like to see a lot more specificity here.  e.g., not just "a label" but
the next relevant label.

Also Section 2.3 talks about appending more than one label per iteration
in some cases, which isn't mentioned here.

> 
>   (5)  Look for a cache entry for the RRset at CHILD with the original
>       QTYPE.  If this entry is for an NXDOMAIN and the resolver has
>       support for [RFC8020], the NXDOMAIN can be used in response to
>       the original query, and stop.  If the entry is for a NOERROR
>       answer (either positive or negative), go back to step 3.  If the
>       entry is for an NXDOMAIN answer and the resolver does not support
>       RFC 8020, go back to step 3.

I find this step somewhat confusing as written.  My interpretation of it
goes something like this:

    if A and B then X;
    if C then Y;
    if A and not B then Y;

I would like to see it (if not the whole algorithm!) as a flow chart, or
maybe pseudo-code?

Wording like "an NXDOMAIN" and "the NXDOMAIN" is imprecise.  It really
means a cached response whose RCODE is NXDOMAIN.

This talks about RCODES NXDOMAIN and NOERROR.  What about others, SERVFAIL,
REFUSED?  Assumes they are never cached?

Since NXDOMAIN means there are no RRsets of any type for the name, I would
expect the (original) QTYPE to be irrelevant when looking for a cached
NXDOMAIN response, especially in the RFC 8020 case.

Instead of "If the entry is for a NOERROR answer (either positive or
negative).." consider "If the cached response code is NOERROR (including
NODATA)..."

> 
>   (6)  Query for CHILD with the selected QTYPE using ANCESTOR's
>       name servers.  The response can be:

Using one of ANCESTOR's name servers?

> 
>       (6a)  A referral.  Cache the NS RRset from the authority section,
>            and go back to step 1.
> 
>       (6b)  A NOERROR answer (either positive or negative).  Cache this
>            answer, and go back to step 3.

again consider "(including NODATA)" instead of "(either positive or
negative)".

> 
>       (6c)  If the resolver is doing RFC 8020 with strict NXDOMAIN, an
>            NXDOMAIN answer.  Return an NXDOMAIN answer in response to
>            the original query, and stop.  If the resolver does not
>            support RFC 8020, go back to step 3.

This would be better as:

(6c) An NXDOMAIN response.  If the resolver supports RFC8020, return an
NXDOMAIN response to the original query and stop.  If the resolver does
not support RFC8020, go to step 3.

> 
>       (6d)  An answer with another RCODE, or no answer.  Try another
>            name server at the same delegation point.  Stop if none of
>            them are able to return a valid answer.

This seems to be specifying (requiring?) some retry behavior.  I don't
know if or where resolver retry behavior is specified in other RFCs but
it seems like this document should not introduce new retry behavior, and
just leave it up to the implementation or other specifications.

Proposed text:

(6d) A timeout or response with another RCODE.  The implementation may
choose to retry step (6) with a different ANCESTOR name server.

Is it obvious what the resolver should do if retries are exhausted or the
algorithm doesn't produce useful results?  Fall back to non-minimized
resolution?  SERVFAIL?

DW