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

"Peter van Dijk" <peter.van.dijk@powerdns.com> Tue, 29 August 2017 08:08 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 44ADA132197 for <dnsop@ietfa.amsl.com>; Tue, 29 Aug 2017 01:08:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 yiJHnQPNlQd7 for <dnsop@ietfa.amsl.com>; Tue, 29 Aug 2017 01:08:55 -0700 (PDT)
Received: from shannon.7bits.nl (shannon.7bits.nl [89.188.0.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 530FC132620 for <dnsop@ietf.org>; Tue, 29 Aug 2017 01:08:55 -0700 (PDT)
Received: from [172.24.17.49] (095-096-086-198.static.chello.nl [95.96.86.198]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: peter) by shannon.7bits.nl (Postfix) with ESMTPSA id 13E671BDA0; Tue, 29 Aug 2017 10:08:52 +0200 (CEST)
From: "Peter van Dijk" <peter.van.dijk@powerdns.com>
To: "dnsop@ietf.org" <dnsop@ietf.org>
Date: Tue, 29 Aug 2017 10:08:51 +0200
Message-ID: <AD596392-BCD6-46DB-A0CA-9FC2C05DA026@powerdns.com>
In-Reply-To: <06a96a6e59d14d378098013966f6641b@mxph4chrw.fgremc.it>
References: <149894524329.526.18431408698564464455@ietfa.amsl.com> <20170824142147.lshdlmjv62nojd32@nic.fr> <f3e75bd0-b398-1b6a-db3f-ecafd4f0c610@nic.cz> <20170824222734.C786E831AA5D@rock.dv.isc.org> <4DC2EF4E-8922-4531-958C-FC4BEF75EAFA@powerdns.com> <06a96a6e59d14d378098013966f6641b@mxph4chrw.fgremc.it>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.6r5347)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/msa5wN0FDIE1f4pOGA11i-ifG_c>
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: Tue, 29 Aug 2017 08:08:57 -0000

On 29 Aug 2017, at 0:20, Darcy Kevin (FCA) wrote:

> Please understand that I don't have a strong opinion on the DNS 
> terminology discussion, _per_se_, but I do have them with regard to 
> semantics, logic and proper citation, which was kind of my prior life, 
> before I even got into DNS, or even Information Technology (at various 
> times an English major, Philosophy major, a professional proofreader, 
> etc.)
>
> The erratum-to-the-erratum is that RFC 1034 didn't *define* QNAME. But 
> RFC 1035 did: Section 4.1.2, QNAME is one of the fields of the Query 
> Section, which, it is stated, constitute " the parameters that define 
> what is being asked". Thus, deductively, QNAME is defined in that 
> document as "the name that was asked [by the client, assumed]".

But it only defines it as such in the context of the query.

> RFC 2308 includes in its definition of "QNAME", end-of-CNAME-chain 
> (where applicable). This was not covered by the RFC 1035 definition, 
> since the client didn't ask for it.

Right, but end-of-CNAME-chain is implied in 1034 4.3.2.

> We can talk about "references" all we want, but the erratum, despite 
> an off-by-one error in RFC citation, is about *definitions*, and the 
> one in RFC 2308 differs from the earlier one from the RFC 1034/1035 
> matched set.

Then what we need is an erratum for 1034 and/or 1035 to make explicit 
what is implicit in 1034 4.3.2: that the QNAME follows the CNAME chain. 
Once that erratum is submitted and accepted, all is consistent again 
between 1034, 1035, 2308. Then, RFCs like 5155 which rely on the 2308 
definition remain correct in their usage of QNAME.

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