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

[Dave Lawrence <[e-mail]>]

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.