On Thu, Aug 24, 2017 at 8:00 PM, Darcy Kevin (FCA) <[email protected] > wrote:
> Honestly, I think the part of RFC 1034 (Section 4.3.2) that says "change > QNAME to the canonical name in the CNAME RR, and go back to step 1" is just > treating the string "QNAME" as a variable in a loop. One will note that the > analogous portion of the *resolver* algorithm (5.3.3) says "change the > SNAME to the canonical name in the CNAME RR and go to step 1." So "QNAME" > substitutes for a variable name in one version of the algorithm, and > "SNAME" substitutes in the other version. There's nothing "magical" about > the reference to "QNAME", therefore, and one shouldn't assume this was an > attempt to (re)define protocol terminology, _per_se_. > Yes, I agree with your characterization. > RFC 2308, on the other hand, defines "QNAME" as encompassing both the > "pure" and the CNAME-chain sense, in its "Terminology" section, and thus > broadens the scope of the term in ways that IMO can lead to ambiguity, if > read as applying beyond that particular RFC. > Yes. > The challenge, however, with saying, that "QNAME" can puristically *only* > refer to what was originally requested in the query packet, is that we need > to then come up with another term to describe the end of the CNAME-chain, > if any, which has been followed. One suggestion was "effective QNAME", but > I'd prefer to leave "QNAME" out of the term completely, to avoid confusion. > "Terminal name" or "terminating name", perhaps? "End name"? "Resultant > name"? > A while back I had suggested "Resolved qname" or "Canonicalized qname" .. Shumon.
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
