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

"Peter van Dijk" <peter.van.dijk@powerdns.com> Thu, 21 September 2017 12:20 UTC

Return-Path: <peter.van.dijk@powerdns.com>
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 86C75132055 for <dnsop@ietfa.amsl.com>; Thu, 21 Sep 2017 05:20:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 o7dWNJfqo4qs for <dnsop@ietfa.amsl.com>; Thu, 21 Sep 2017 05:20:25 -0700 (PDT)
Received: from mx2.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 D67E612EC30 for <dnsop@ietf.org>; Thu, 21 Sep 2017 05:20:24 -0700 (PDT)
Received: by mx2.open-xchange.com (Postfix, from userid 1001) id F08C96A401; Thu, 21 Sep 2017 14:20:22 +0200 (CEST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.open-xchange.com (Postfix) with ESMTP id 34F2C6A3FC; Thu, 21 Sep 2017 14:20:17 +0200 (CEST)
Received: from [127.0.0.1] (helo=mx2.open-xchange.com) by localhost with ESMTP (eXpurgate 4.1.8) (envelope-from <peter.van.dijk@powerdns.com>) id 59c3ae81-034f-7f000001272a-7f000001c926-1 for <multiple-recipients>; Thu, 21 Sep 2017 14:20:17 +0200
Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx2.open-xchange.com (Postfix) with ESMTPS id 9D0EB6A3A6; Thu, 21 Sep 2017 14:20:16 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by open-xchange.com (Postfix) with ESMTP id 919773C19F4; Thu, 21 Sep 2017 14:20:16 +0200 (CEST)
Received: from open-xchange.com ([127.0.0.1]) by localhost (imap.open-xchange.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBPIgLYM9orW; Thu, 21 Sep 2017 14:20:16 +0200 (CEST)
Received: from [10.242.2.24] (095-096-086-198.static.chello.nl [95.96.86.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 754333C19EE; Thu, 21 Sep 2017 14:20:16 +0200 (CEST)
From: Peter van Dijk <peter.van.dijk@powerdns.com>
To: dnsop@ietf.org
Date: Thu, 21 Sep 2017 14:20:15 +0200
Message-ID: <8FD138C0-3D99-42E6-8EB2-97C5FA2F0C80@powerdns.com>
In-Reply-To: <20170921034533.d2isi2idl7cyepea@mx4.yitter.info>
References: <149894524329.526.18431408698564464455@ietfa.amsl.com> <20170824142147.lshdlmjv62nojd32@nic.fr> <20170921034533.d2isi2idl7cyepea@mx4.yitter.info>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
X-Mailer: MailMate (1.9.7r5418)
Content-Transfer-Encoding: quoted-printable
X-purgate-ID: 151428::1505996417-0000034F-1B5E1D16/0/0
X-purgate-type: clean
X-purgate-size: 2918
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate: clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/8ysS8D1NXYLNPNBPNp--c2irmZM>
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 12:20:26 -0000

Hello Andrew,

thank you for this, I like it a lot. One nit below.

On 21 Sep 2017, at 5:45, Andrew Sullivan wrote:

>       [RFC2308], however, has an alternate definition that puts the
>       QNAME in the answer (or series of answers) instead of the query.
>       It defines QNAME as: "...the name in the query section of an
>       answer, or where this resolves to a CNAME, or CNAME chain, the
>       data field of the last CNAME.  The last CNAME in this sense is
>       that which contains a value which does not resolve to another
>       CNAME."  This definition has a certain internal logic, because of
>       the way CNAME substitution works and the definition of CNAME.  If
>       a name server does not find an RRset that matches a query, but it
>       finds the same name in the same class with a CNAME record, then
>       the name server "includes the CNAME record in the response and
>       restarts the query at the domain name specified in the data field
>       of the CNAME record."  ([RFC1034] Section 3.6.2).  This is made
>       explicit in the resolution algorithm outlined in Section 4.3.2,

It’s unclear that 4.3.2 is in 1034, as 1034 is in parens just before.

>       which says to "change QNAME to the canonical name in the CNAME RR,
>       and go back to step 1" in the case of a CNAME RR.  Since a CNAME
>       record explicitly declares that the owner name is canonically
>       named what is in the RDATA, then there is a way to view the new
>       name (i.e. the name that was in the RDATA of the CNAME RR) as also
>       being the QNAME.
>
>       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
>       confusion comes from the iterative/recursive mode of resolution,
>       which finally returns an answer that need not actually have the
>       same owner name as the QNAME contained in the original query.
>
>       To address this potential confusion, it is helpful to distinguish
>       between two meanings:
>
>       QNAME (original)  The name actually sent in the Question
>          Section in the orignal query, which is always echoed in the
>          (final) reply in the Question Section when the QR bit is set to
>          1.
>
>       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].
>
> I'm certainly not wedded to these two names.

They certainly are adequate, and I do not have better suggestions.

Wonderful work!

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/