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

Olafur Gudmundsson <> Sat, 25 February 2017 19:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CDE2C1294AC for <>; Sat, 25 Feb 2017 11:52:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zuXlDHS72NAF for <>; Sat, 25 Feb 2017 11:52:17 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8169B1294A5 for <>; Sat, 25 Feb 2017 11:52:17 -0800 (PST)
Received: from (localhost []) by (SMTP Server) with ESMTP id 9B005C0137; Sat, 25 Feb 2017 14:52:16 -0500 (EST)
Received: by (Authenticated sender: with ESMTPSA id 0E349C0133; Sat, 25 Feb 2017 14:52:15 -0500 (EST)
Received: from [] ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by (trex/5.7.12); Sat, 25 Feb 2017 14:52:16 -0500
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Olafur Gudmundsson <>
In-Reply-To: <>
Date: Sat, 25 Feb 2017 14:52:15 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Evan Hunt <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
Cc: Edward Lewis <>, "" <>
Subject: Re: [DNSOP] [Ext] order of records in DNAME responses
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 25 Feb 2017 19:52:19 -0000

> On Feb 24, 2017, at 12:35 PM, Evan Hunt <> wrote:
> 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?

While I would love to say Yes to above, that can not be any stronger than “SHOULD” 
The old RFC’s are much less prescriptive than modern ones. 
If we ever do a RFC2181-bis or followup work then this should be one of the topics 
There are basically two ways to handle it 
-  Prescribe order 
- Dicate that whole section must be consumed and “ordered” before processing.

One corner case that I seen on couple of occasions is CNAME chain out of order, 
I have no idea how that can happen … 

>> 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.
I was around the time DNAME was defined, and my recollection was that
CNAME after DNAME was so obvious that no-one thought is was needed to specify. 

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

Thank you for bringing real issue to WG