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

"Peter van Dijk" <peter.van.dijk@powerdns.com> Tue, 27 September 2016 12:51 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 445A912B151 for <dnsop@ietfa.amsl.com>; Tue, 27 Sep 2016 05:51:42 -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 HlLrUJToHUQP for <dnsop@ietfa.amsl.com>; Tue, 27 Sep 2016 05:51:36 -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 C640B12B143 for <dnsop@ietf.org>; Tue, 27 Sep 2016 05:51:35 -0700 (PDT)
Received: from [192.168.137.1] (5356AEB1.cm-6-7c.dynamic.ziggo.nl [83.86.174.177]) (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 27F531BB9C; Tue, 27 Sep 2016 14:51:32 +0200 (CEST)
From: Peter van Dijk <peter.van.dijk@powerdns.com>
To: dnsop@ietf.org
Date: Tue, 27 Sep 2016 14:51:31 +0200
Message-ID: <DCD669F3-FE2B-457E-894F-30D7A278D85C@powerdns.com>
In-Reply-To: <8A664A35-806C-4F8C-B836-B2A1438FAEA6@vpnc.org>
References: <20160920161350.GA3288@laperouse.bortzmeyer.org> <20160923082232.6j2jlr4wqp2fxs56@nic.fr> <7F671C9C-BEEC-479B-99FB-8618C3C75526@powerdns.com> <8A664A35-806C-4F8C-B836-B2A1438FAEA6@vpnc.org>
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/rA1sjrREKf9gG8cJ2l3l7iiMbHc>
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: Tue, 27 Sep 2016 12:51:42 -0000

Hello Paul,

On 26 Sep 2016, at 16:32, Paul Hoffman wrote:

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

My reading of 3.7.1 + 4.3.2 is ‘the QNAME, at any time, means the name 
currently under consideration; initially this is the name from the query 
packet, but it gets updated on every CNAME follow’. To make QNAME work 
consistently between 1034, 2308 and several of the RFCs mentioned below, 
this is the only interpretation that makes sense to me. I don’t see 
any conflict between 1034 and 2308 given this reading.

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

I agree - on rereading that part of 4035 indeed it is talking about 
whole response packets. Must’ve confused it with denials, like in 
5155.

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