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 -- e...@isc.org
Internet Systems Consortium, Inc.

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to