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

Matt Larson <matt@kahlerlarson.org> Mon, 26 September 2016 13:05 UTC

Return-Path: <matt@kahlerlarson.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 9474A12B1E8 for <dnsop@ietfa.amsl.com>; Mon, 26 Sep 2016 06:05:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.216
X-Spam-Level:
X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316] 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 2T96usVlHWY0 for <dnsop@ietfa.amsl.com>; Mon, 26 Sep 2016 06:04:56 -0700 (PDT)
Received: from twister.kahlerlarson.org (twister.kahlerlarson.org [104.237.149.128]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB24612B1E7 for <dnsop@ietf.org>; Mon, 26 Sep 2016 06:04:56 -0700 (PDT)
Received: from [10.96.9.20] (44-1.dc.icann.org [192.0.44.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by twister.kahlerlarson.org (Postfix) with ESMTPSA id A13571F624; Mon, 26 Sep 2016 13:04:55 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Matt Larson <matt@kahlerlarson.org>
In-Reply-To: <20160923082232.6j2jlr4wqp2fxs56@nic.fr>
Date: Mon, 26 Sep 2016 09:04:54 -0400
X-Mao-Original-Outgoing-Id: 496587894.535798-750dd18b29850b28f2566556771752cb
Content-Transfer-Encoding: quoted-printable
Message-Id: <2C1851F8-E4D4-402D-9F0A-2C37D40167B0@kahlerlarson.org>
References: <20160920161350.GA3288@laperouse.bortzmeyer.org> <20160923082232.6j2jlr4wqp2fxs56@nic.fr>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/WScVbxQNW5PUJqoO6vEiaCZ5v3U>
Cc: dnsop@ietf.org
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 13:05:01 -0000

> On Sep 23, 2016, at 4:22 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> 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.

+1 to this interpretation.

I think a good case can be made that QNAME is the last target in a chain of aliases based on the "variable substitution" use of QNAME in §4.3.2 of RFC 1035 and the definition of QNAME in RFC 2308.  However, I think this definition violates the principal of least astonishment, as this thread shows: I'd venture that more people familiar with the subject matter would define QNAME as the name in the question section of a DNS message.  (That's my sense of the definition, FWIW.)

I like the current text in draft-ietf-dnsop-nxdomain-cut-05, which avoids confusion by explicitly calling out "denied name".  Even if the consensus of this thread had been that the definition of QNAME was the "last alias target", I'd argue that we'd still want the "denied name" language to avoid any confusion because I don't think the "last alias target" of QNAME is the majority interpretation.

Matt