Re: [DNSOP] Definition of QNAME (Was: I-D Action: draft-ietf-dnsop-terminology-bis-06.txt

Evan Hunt <each@isc.org> Thu, 21 September 2017 16:01 UTC

Return-Path: <each@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E515132D53 for <dnsop@ietfa.amsl.com>; Thu, 21 Sep 2017 09:01:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbyPcem5726P for <dnsop@ietfa.amsl.com>; Thu, 21 Sep 2017 09:01:50 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91A4F132125 for <dnsop@ietf.org>; Thu, 21 Sep 2017 09:01:50 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [149.20.48.19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 028CA34BD26; Thu, 21 Sep 2017 16:01:16 +0000 (UTC)
Received: by bikeshed.isc.org (Postfix, from userid 10292) id E6F97216C1E; Thu, 21 Sep 2017 16:01:15 +0000 (UTC)
Date: Thu, 21 Sep 2017 16:01:15 +0000
From: Evan Hunt <each@isc.org>
To: Peter van Dijk <peter.van.dijk@powerdns.com>
Cc: dnsop@ietf.org
Message-ID: <20170921160115.GA20526@isc.org>
References: <149894524329.526.18431408698564464455@ietfa.amsl.com> <20170824142147.lshdlmjv62nojd32@nic.fr> <20170921034533.d2isi2idl7cyepea@mx4.yitter.info> <8FD138C0-3D99-42E6-8EB2-97C5FA2F0C80@powerdns.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8FD138C0-3D99-42E6-8EB2-97C5FA2F0C80@powerdns.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/UNV7ZClO8nrwx9uAaK5iyl5Mv3Q>
Subject: Re: [DNSOP] Definition of QNAME (Was: I-D Action: draft-ietf-dnsop-terminology-bis-06.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Sep 2017 16:01:52 -0000

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