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

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 29 September 2016 08:17 UTC

Return-Path: <ietf-dane@dukhovni.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 245BC12B075 for <dnsop@ietfa.amsl.com>; Thu, 29 Sep 2016 01:17:32 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 HAlzxbgegsvW for <dnsop@ietfa.amsl.com>; Thu, 29 Sep 2016 01:17:30 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DB9F12B015 for <dnsop@ietf.org>; Thu, 29 Sep 2016 01:17:30 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E9EC1284ADC; Thu, 29 Sep 2016 08:17:28 +0000 (UTC)
Date: Thu, 29 Sep 2016 08:17:28 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dnsop <dnsop@ietf.org>
Message-ID: <20160929081728.GR4670@mournblade.imrryr.org>
References: <20160920161350.GA3288@laperouse.bortzmeyer.org> <20160923082232.6j2jlr4wqp2fxs56@nic.fr> <7F671C9C-BEEC-479B-99FB-8618C3C75526@powerdns.com> <CAN6NTqyCuLQJ=aYCfxiLPyRgoMR2CQDwtpsSSt499wA3Y_168A@mail.gmail.com> <20160928212638.GD4192@laperouse.bortzmeyer.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20160928212638.GD4192@laperouse.bortzmeyer.org>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/qpORHRQclQqwQcc2WVHYQwvQEQQ>
Subject: Re: [DNSOP] Where in a CNAME chain is the QNAME?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: dnsop@ietf.org
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: Thu, 29 Sep 2016 08:17:32 -0000

On Wed, Sep 28, 2016 at 09:26:38PM +0000, Stephane Bortzmeyer wrote:

> On Mon, Sep 26, 2016 at 12:33:39PM +0100,
>  Ólafur Guðmundsson <olafur@cloudflare.com> wrote 
>  a message of 148 lines which said:
> 
> > The RCODE applies to the RRSET pointed to by the last CNAME in answer
> > section (or the missing one).
> 
> This specific case was settled in RFC 6604 and I did not intend to
> reopen it. My problem was with the definition of QNAME, not with the
> proper rcode for a chain of CNAME.

By the way, is it the case that CNAMEs in the answer section MUST
appear in their natural chaining order:

	A. IN CNAME B.
	B. IN CNAME C.
	C. IN CNAME D.
	D. IN CNAME E.

Which is to say can stub resolvers assume that this is always the
case, or would it prudent to reassemble the list by finding the
CNAME whose owner is the qname, and using the target alias to find
the name CNAME, ... recursively without making assumptions about
the order in which the records appear?

I am writing some code in Haskell that process DNS responses, and
made no assumptions about CNAME ordering in the response, because
Haskell is recursive anyway and finding the starting point rather
than using the first remaining response is easy enough.  So this
code is more robust in the face of unexpected CNAME ordering,
irrelevant CNAME responses that are even part of the chain, ...

What I'm wondering about is whether this is just quaint pedantry,
encouraged by a language that makes it all too easy, or sensibly
defensive programming... :-)

Or put another way, does step "3 a" of Section 4.3.2 of RFC 1034
imply that responses MUST contain any CNAMEs in the typically
expected order?  And, if so, is it then the case that clients
(wether stub or iterative) need make no effort to deal with responses
that are not so ordered?  Should clients take care to deal with
CNAMEs in the answer section that don't form a linear chain (out
of order, or not even possible to re-order as a linear chain).

-- 
	Viktor.