On Thu, Sep 21, 2017 at 02:20:15PM +0200, Peter van Dijk wrote:
> thank you for this, I like it a lot. One nit below.
Me too, with another nit...
> > This creates a kind of confusion, however, because the answer to a
> > query that results in CNAME processing contains in the echoed
> > Question Section one QNAME (the name in the original query), and a
> > second QNAME that is in the data field of the last CNAME. The
Why only the "last CNAME?" If a chain contains more than one CNAME, the
answer includes intermediate names as well:
;; ANSWER SECTION:
www.paypal.com. 5 IN CNAME geo.paypal.com.akadns.net.
geo.paypal.com.akadns.net. 5 IN CNAME wlb.paypal.com.akadns.net.
wlb.paypal.com.akadns.net. 5 IN CNAME www.paypal.com.edgekey.net.
www.paypal.com.edgekey.NET. 5 IN CNAME e3694.a.akamaiedge.net.
e3694.a.akamaiedge.net. 5 IN A 104.91.181.63
> > QNAME (effective) The name actually resolved, which is either the
> > name actually queried or else the last name in a CNAME chain as
> > defined in [RFC2308].
This does match the use of the term in RFC 2308, but in other contexts,
I think it would be better to expand it to include intermediate names:
"A name actually resolved, which is either the name originally queried,
or a name received in a CNAME chain response."
RFC 2308 is interested in caching of answers after recursion is done,
but if one were discussing the recursion process itself, this would be a
natural term to use for itermediate names. ("If the response is a CNAME,
update the effective QNAME to the CNAME target and go back to step 2...")
If it's necessary to have a specific term that only refers to the *last*
name, perhaps "QNAME (final)" would be a better choice for that.
Incidentally "CNAME chain as defined in [RFC2308]" is ambiguous. RFC
2308 has a definition of QNAME that includes the last CNAME in a chain,
but it does not define the term "CNAME chain".
--
Evan Hunt -- [email protected]
Internet Systems Consortium, Inc.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
