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

Edward Lewis <edward.lewis@icann.org> Fri, 24 February 2017 17:24 UTC

Return-Path: <edward.lewis@icann.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 704BC129424 for <dnsop@ietfa.amsl.com>; Fri, 24 Feb 2017 09:24:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_U6jI_I5Avo for <dnsop@ietfa.amsl.com>; Fri, 24 Feb 2017 09:24:07 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EE491293FF for <dnsop@ietf.org>; Fri, 24 Feb 2017 09:24:07 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 24 Feb 2017 09:24:04 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Fri, 24 Feb 2017 09:24:04 -0800
From: Edward Lewis <edward.lewis@icann.org>
To: Evan Hunt <each@isc.org>, =?utf-8?B?TWF0dGjDpHVzIFdhbmRlcg==?= <matthaeus.wander@uni-due.de>
Thread-Topic: [Ext] Re: [DNSOP] order of records in DNAME responses
Thread-Index: AQHSjopz6zsF1qRoj0WNLXZT5U75PKF46AsA//+ywIA=
Date: Fri, 24 Feb 2017 17:24:04 +0000
Message-ID: <87D4CC1A-E173-450E-8E4C-CAD9598716D9@icann.org>
References: <20170223232432.GA41294@isc.org> <8c600688-2ec3-141e-82af-d0b73a9ca865@uni-due.de> <20170224170031.GA55999@isc.org>
In-Reply-To: <20170224170031.GA55999@isc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1f.0.170216
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.47.234]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3570783843_1746629285"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/kvY-OC6NhlJV9hAZrtO3MQZjqF4>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
Subject: Re: [DNSOP] [Ext] Re: 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:24:08 -0000

On 2/24/17, 12:00, "DNSOP on behalf of Evan Hunt" <dnsop-bounces@ietf.org on behalf of each@isc.org> wrote:

>    On Fri, Feb 24, 2017 at 11:40:26AM +0100, Matthäus Wander wrote:
>    > Do you mean clarifying as in "how it always was meant to be but stated
>    > in unclear words" or as in "change to protocol"?
>    
>    I meant the former.  I wasn't involved, but I suspect that DNAME-first
>    was the intended behavior all along, and nobody thought to mention it.
>    However, if the group doesn't agree, then I guess I mean the latter.

I wasn't there either...but in general, whenever you want to "clarify" what was intended by stating it explicitly, someone somewhere will claim it is a change and not a clarification.  That was my experience with wild cards and to a lesser extent zone transfer (but someone else had and is why that document fell to me).

>    
>    > In the latter case, you'd still need code to parse responses from
>    > implementations that don't make assumptions about the order of records.
>    
>    What I'd like is to be able to send FORMERR with a clear conscience.

Given the lax rules of the field, I'd lean to saying you can't.

For DNSSEC this was a pain.  Because we couldn't outlaw round robin we had to sort the records in the set as it arrived.  All we could do was simplify the sorting comparison but not having to copy the data, sort, work, and dispose of the copy to retain the original ordering.  The copy came to be 100% wasted cycles as you had to retain the original order.