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

From: Dave Lawrence <[email-masked]>
Date: Wed, 4 Nov 2020 19:51:14 -0500

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.

---

From: Tony Finch <[email-masked]>
Date: Fri, 6 Nov 2020 00:43:33 +0000

> encountering CNAMEs?  Or DNAMEs?

I guess when I originally sketched a qname minimization algorithm
https://mailarchive.ietf.org/arch/msg/dns-privacy/gAgGx9Zz6W0OfyRdJ0Rx7xxmHDg/
I intended that it would slot into the RFC 1034 resolver algorithm
https://tools.ietf.org/html/rfc1034#section-4.3.2
which treats QNAME as a variable name rather than a protocol field, so
the QNAME changes when the resolver chases a CNAME.

That was probably a bad idea: on balance I think it's better to make a
clear distinction between protocol fields and variables in algorithms.
Elsewhere RFC 1034 uses SNAME for the variable containing the name we are
searching for https://tools.ietf.org/html/rfc1034#section-5.3.3
which would be better if it hadn't used QNAME for the same thing elsewhere
:-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fitzroy: Easterly 6 to gale 8, becoming cyclonic 5 to 7. Rough or very rough,
becoming moderate or rough later. Thundery showers. Good, occasionally poor.