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. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop