Re: [DNSOP] [Ext] order of records in DNAME responses

Evan Hunt <each@isc.org> Fri, 24 February 2017 17:35 UTC

Return-Path: <each@isc.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 9249D129437 for <dnsop@ietfa.amsl.com>; Fri, 24 Feb 2017 09:35:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 yJyECxBpcbj5 for <dnsop@ietfa.amsl.com>; Fri, 24 Feb 2017 09:35:21 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 CD62D129424 for <dnsop@ietf.org>; Fri, 24 Feb 2017 09:35:21 -0800 (PST)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id E4E383493BC; Fri, 24 Feb 2017 17:35:19 +0000 (UTC)
Received: by bikeshed.isc.org (Postfix, from userid 10292) id D705D216C1C; Fri, 24 Feb 2017 17:35:19 +0000 (UTC)
Date: Fri, 24 Feb 2017 17:35:19 +0000
From: Evan Hunt <each@isc.org>
To: Edward Lewis <edward.lewis@icann.org>
Message-ID: <20170224173519.GB55999@isc.org>
References: <20170223232432.GA41294@isc.org> <475CA1CA-E1D3-44D8-AE4D-6629A52C068C@icann.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <475CA1CA-E1D3-44D8-AE4D-6629A52C068C@icann.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/eItRFPZtYmDlS8nWOzvC71bRjvM>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
Subject: Re: [DNSOP] [Ext] order of records in DNAME responses
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: Fri, 24 Feb 2017 17:35:22 -0000

On Fri, Feb 24, 2017 at 02:46:28PM +0000, Edward Lewis wrote:
> The reason I point this out is that the order of records in a section has
> been famously undefined, with the convention of supporting round robin
> (an undocumented feature of the protocol) hanging around, for all of
> eternity.  I can see an implementation recommendation note because it
> makes sense, but, if we use the old rule of "for interoperability" I
> don't see specifying the order of records as necessary.

The order of RR's within an RRset is undefined and needs to remain so, but
can there be constraints on the order of RRsets within a section?

> I also think that goats have already left the burning barn on this.
> Going forward code might put the DNAME ahead of the CNAME, but if past
> code doesn't, going forward code must account for that.

It took us a very long time to encounter the first server that did
CNAME-first.  Most are going to do DNAME-first because it's simpler to
code that way: it's easier to append to a message than insert something
into the middle.

IMHO the problem is now big enough to see, but still small enough
to step on by declaring we didn't mean for it to be legal.

> Not to mention the difficulties in writing so-called clarification
> documents.  They aren't all that pleasant...

Well, that's why I started with an email thread...

-- 
Evan Hunt -- each@isc.org
Internet Systems Consortium, Inc.