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

"Paul Hoffman" <paul.hoffman@vpnc.org> Mon, 26 September 2016 14:33 UTC

Return-Path: <paul.hoffman@vpnc.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 06A9B12B2A1 for <dnsop@ietfa.amsl.com>; Mon, 26 Sep 2016 07:33:01 -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, HTML_MESSAGE=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 i3KbyPlHd0Fv for <dnsop@ietfa.amsl.com>; Mon, 26 Sep 2016 07:33:00 -0700 (PDT)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 E0CFE12B29F for <dnsop@ietf.org>; Mon, 26 Sep 2016 07:32:59 -0700 (PDT)
Received: from [10.32.60.130] (50-1-99-230.dsl.dynamic.fusionbroadband.com [50.1.99.230]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u8QEWvmt066312 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Sep 2016 07:32:58 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 50-1-99-230.dsl.dynamic.fusionbroadband.com [50.1.99.230] claimed to be [10.32.60.130]
From: "Paul Hoffman" <paul.hoffman@vpnc.org>
To: "Peter van Dijk" <peter.van.dijk@powerdns.com>
Date: Mon, 26 Sep 2016 07:32:57 -0700
Message-ID: <8A664A35-806C-4F8C-B836-B2A1438FAEA6@vpnc.org>
In-Reply-To: <7F671C9C-BEEC-479B-99FB-8618C3C75526@powerdns.com>
References: <20160920161350.GA3288@laperouse.bortzmeyer.org> <20160923082232.6j2jlr4wqp2fxs56@nic.fr> <7F671C9C-BEEC-479B-99FB-8618C3C75526@powerdns.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_B7F15C40-66E2-4441-A321-31D184DC2D57_="
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.5r5263)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/8CSX-RoJSnv2BH6mV7sLvBbv6TM>
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 14:33:01 -0000

On 26 Sep 2016, at 0:33, Peter van Dijk wrote:

> 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.

This seems like a very limited view of RFC 1034. RFC 1034 actually 
defines QNAME in Section 3.7.1:

3.7.1. Standard queries

A standard query specifies a target domain name (QNAME), query type
(QTYPE), and query class (QCLASS) and asks for RRs which match.

Further, the usage in Section 4.3.2 does not say that the QNAME is the 
last name in the chain, just that the algorithm itself repeats with a 
new value for QNAME:

             If the data at the node is a CNAME, and QTYPE doesn't
             match CNAME, copy the CNAME RR into the answer section
             of the response, change QNAME to the canonical name in
             the CNAME RR, and go back to step 1.

> 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.

I'm quite concerned about the assertion that RFC 4035 relies on RFC 
2038's definition. QNAME is only mentioned in Section 4.5 and 4.7 there, 
and I don't see how those usages indicate that it is the last name in a 
chain. Can you clarify?

--Paul Hoffman