Re: [DNSOP] Where in a CNAME chain is the QNAME?

"Peter van Dijk" <peter.van.dijk@powerdns.com> Mon, 26 September 2016 07:33 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 E511312B09A for <dnsop@ietfa.amsl.com>; Mon, 26 Sep 2016 00:33:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 o1HRyH5bBaqn for <dnsop@ietfa.amsl.com>; Mon, 26 Sep 2016 00:33:49 -0700 (PDT)
Received: from shannon.7bits.nl (shannon.7bits.nl [IPv6:2a01:1b0:202:40::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2291812B00A for <dnsop@ietf.org>; Mon, 26 Sep 2016 00:33:49 -0700 (PDT)
Received: from [192.168.137.1] (unknown [92.110.143.62]) (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 0176FC1B96; Mon, 26 Sep 2016 09:33:46 +0200 (CEST)
From: "Peter van Dijk" <peter.van.dijk@powerdns.com>
To: dnsop@ietf.org
Date: Mon, 26 Sep 2016 09:33:46 +0200
Message-ID: <7F671C9C-BEEC-479B-99FB-8618C3C75526@powerdns.com>
In-Reply-To: <20160923082232.6j2jlr4wqp2fxs56@nic.fr>
References: <20160920161350.GA3288@laperouse.bortzmeyer.org> <20160923082232.6j2jlr4wqp2fxs56@nic.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.5r5263)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/4a-pH7RXeGVlxCC4TlxaOdTeAGM>
Subject: Re: [DNSOP] Where in a CNAME chain is the QNAME?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 26 Sep 2016 07:33:51 -0000

Hello,

On 23 Sep 2016, at 10:22, Stephane Bortzmeyer wrote:

> On Tue, Sep 20, 2016 at 06:13:50PM +0200,
>  Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote
>  a message of 68 lines which said:
>
>> This issue was spotted by Peter van Dijk. It is about
>> draft-ietf-dnsop-nxdomain-cut-05, recently approved by IESG. The
>> problem is the definition of "QNAME" when there is a CNAME chain.
>
> OK, after reading the discussion, my opinion, as an author (but I'll
> of course defer the decision to the working group, the WG chairs, the
> RFC editor and the flying spaghetti monster):
>
> The re-definition of QNAME by RFC 2308 is awkward and does not match
> the general usage, or the previous definitions. Therefore, I prefer to
> keep the "common sense" usage "QNAME is the owner name of the record
> in the Question Section". Which means that, in my example, the QNAME
> is "www.afnic.fr" and the current text of
> draft-ietf-dnsop-nxdomain-cut-05 is correct.

2308 does not “redefine” QNAME. It clarifies that the usage in 1034 
4.3.2 is the definition we use in RFCs. 1035 4.1(.2) does not conflict 
with this; the QNAME there is just the initial QNAME.

Many other RFCs need 2308: 2874, 4035, 4343, 4592, 4470, 4471, 5074, 
5155, 6147, 6672 and most likely several others rely on the 2308 
definition of QNAME. Without 2308, each of these RFCs would need extra 
text such as the text your draft has now. It is simply not necessary.

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