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

["Wessels, Duane" <[e-mail]>]

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