Re: [DNSOP] draft-ietf-dnsop-rfc7816bis: hopefully ready for WG Last Call

Dave Lawrence <tale@dd.org> Thu, 05 November 2020 00:51 UTC

Return-Path: <tale@dd.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA013A11EB for <dnsop@ietfa.amsl.com>; Wed, 4 Nov 2020 16:51:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M71m5ETn9azD for <dnsop@ietfa.amsl.com>; Wed, 4 Nov 2020 16:51:17 -0800 (PST)
Received: from gro.dd.org (host2.dlawren-3-gw.cust.sover.net [207.136.201.30]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D2F83A11EA for <dnsop@ietf.org>; Wed, 4 Nov 2020 16:51:15 -0800 (PST)
Received: by gro.dd.org (Postfix, from userid 102) id 14E978F0E0; Wed, 4 Nov 2020 19:51:14 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <24483.19586.61363.930584@gro.dd.org>
Date: Wed, 4 Nov 2020 19:51:14 -0500
From: Dave Lawrence <tale@dd.org>
To: dnsop <dnsop@ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ddqrZSj1K7F1Peb9LFbwi6fB8p8>
Subject: Re: [DNSOP] draft-ietf-dnsop-rfc7816bis: hopefully ready for WG Last Call
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Nov 2020 00:51:20 -0000

Thanks for the work on this, Stephane, Ralph, and Paul.

Could you please clarify explicitly what should happen in the case of
encountering CNAMEs?  Or DNAMEs?

The way I read it, at least for CNAMEs, is that you just keep
prepending labels to the ANCESTOR name so encountering the CNAME is in
practice no different from encountering any rrtype other than NS.
This would also be consistent with the existing DNS not having any
prohibition of data beneath a CNAME, such that we can fetch data for
foo.bar.example.com even in the presence of a bar.example.com CNAME.

Ralph's original presentation for OARC 24 though had a different
implication on slide 11 that, in the absence of speaker explaining it
to me, implies that encountering a CNAME ... well, I'm not sure.

https://www.nlnetlabs.nl/downloads/presentations/unbound_qnamemin_oarc24.pdf#page=11

With the word "change" there and the arrows it says to me that it's
doing a query restart on the CNAME and continuing onward with the
minimisation algorithm from there.  And it's mentioned right there
with referrals as something parenthetically noteworthy.

How do BIND andc Unbo,und currently handle this?  I'm guessing both like
the way described by the algorithm.

It'd help future implementers to have explicit guidance.  Perhaps
something like:

       (6b)  All other NOERROR answers (either positive or negative).
       Cache this answer.  Regardless of the answered RRset type,
       including CNAMEs, continue with the algorithm from step 3
       by building on the original QNAME.

I changed it to "All other" because 6a is also a NOERROR answer.  I
orthogonally think you should make that change, even if my other text
is rejected.

I'm not feeling great about my wordsmithing, but I made an effort
under the "please send text" maxim.

Or maybe this should just be an unnumbered note at the end of the section,
saying something like:

    Note that in this algorithm, encountering a CNAME is no different
    from encountering other non-referral positive answers.  They are
    not followed when discovered for intermediate labels.  Always use
    the labels of the original QNAME.

Then have an example cover this case in section 4, maybe just by using
NOTE to observe it could be "any positive answer, even CNAME".
Doesn't fit on the line well though.

Oh and for DNAME ... maybe in 6a describe that it's also a referral,
one that should set CHILD to the target and resume the algorithm at
step 5?  That seems maybe insufficient, but it's a starting point for
thinking about.