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

Edward Lewis <> Fri, 24 February 2017 14:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CEE81129865 for <>; Fri, 24 Feb 2017 06:46:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9NkgCD_OrARc for <>; Fri, 24 Feb 2017 06:46:32 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6F6E5129DCD for <>; Fri, 24 Feb 2017 06:46:32 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 24 Feb 2017 06:46:30 -0800
Received: from ([]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([]) with mapi id 15.00.1178.000; Fri, 24 Feb 2017 06:46:29 -0800
From: Edward Lewis <>
To: Evan Hunt <>, "" <>
Thread-Topic: [Ext] [DNSOP] order of records in DNAME responses
Thread-Index: AQHSjiwD4KoT0bB3kEid/D7WYDU4y6F4b4MA
Date: Fri, 24 Feb 2017 14:46:28 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
user-agent: Microsoft-MacOutlook/f.1f.0.170216
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3570774390_1385830826"
MIME-Version: 1.0
Archived-At: <>
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: Fri, 24 Feb 2017 14:46:35 -0000

On 2/23/17, 18:24, "DNSOP on behalf of Evan Hunt" < on behalf of> wrote:

>I'd like to start a discussion of that now.  Does anyone have a problem
>with the idea of clarifying the protocol here, saying that the order of
>records in the answer section of a chaining response is significant, and in
>particular, that a DNAME MUST precede the corresponding synthesized CNAME?

Protocol Specification Wars

A long, long time ago in a galaxy far, far away...

>From a time when I spent a lot of attention on the section titled "The Algorithm" in "Domain names - concepts and facilities", that is section 4.3.2 of RFC 1034, I was reminded by one of the originators of the protocol that the RFCs were intended to capture the spirit of the protocol, that passages such as that in 4.3.2 weren't crafted even to the point of being pseudo-code.  There were merely spirit guides.  Since then I've thought of the RFCs as guides to how to enable interoperability between implementations rather than standards documents with testable criteria for compliance.

(As an engineer and one-time coder, I wanted spec docs, tried to write that way.  I'm sympathetic to that desire, but, the IETF was founded to promote interoperability not solve user stories.)

I'm just throwing that out as a point of history, unsupported by any reference because it was either in person or in private email.  To me it explains how the, at least, early documents were prepared, with "earlier" meaning lower in RFC series number.

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.

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's the same for compression of domain names in RDATA - despite originally being limited to the first set of resources records, later code expanded it to the point that there's a set of resource records than must be expected to be compressed incoming and never compressed outgoing.

All in all, I think the suggestion makes sense.  But there are other cases where the original definitions are "too loose for comfort" to fix as well.  And, to spread fear, uncertainty and doubt, once we try to plug holes there's the ever-present chance we create a rift in the protocol.

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