Re: [DNSOP] BCP on rrset ordering for round-robin? Also head's up on bind 9.12 bug (sorting rrsets by default)

Andrew Sullivan <ajs@anvilwalrusden.com> Fri, 15 June 2018 17:12 UTC

Return-Path: <ajs@anvilwalrusden.com>
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 8A880130DFB for <dnsop@ietfa.amsl.com>; Fri, 15 Jun 2018 10:12:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=RnQXDw5B; dkim=pass (1024-bit key) header.d=yitter.info header.b=nftcSt+7
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 5D9mct1dOpLx for <dnsop@ietfa.amsl.com>; Fri, 15 Jun 2018 10:12:35 -0700 (PDT)
Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 026AD12F18C for <dnsop@ietf.org>; Fri, 15 Jun 2018 10:12:34 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 1E88BBE444 for <dnsop@ietf.org>; Fri, 15 Jun 2018 17:12:34 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1529082754; bh=ZX//7GGVRFVTlJws6D6xDzDeb8+oswbXuG1NzoZh4Ps=; h=Date:From:To:Subject:References:In-Reply-To:From; b=RnQXDw5BtsXJGmXEaCjlb1fbXgIBxZg+swt6Cct29FYhk5a1y0O25TS5MK79j618l 3Q2OooMIetUViCHLcSl2jRgydZRES8xGy+auHuIpNCdRol+KIU+rdOW93VC33HQxc0 pRQ/ufKTI0ph9Un+/rhHOiLuoLytXR9kZ8n6sV9c=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DERsAgSqyfU for <dnsop@ietf.org>; Fri, 15 Jun 2018 17:12:33 +0000 (UTC)
Date: Fri, 15 Jun 2018 13:12:31 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1529082753; bh=ZX//7GGVRFVTlJws6D6xDzDeb8+oswbXuG1NzoZh4Ps=; h=Date:From:To:Subject:References:In-Reply-To:From; b=nftcSt+7WBcPvsJcfwEtVSTlv5uPh6omhFfSWdZXbsJnkYEITAFsmqJj/B2+2AIJP 8esexrzoT5vBGkuYzSXKCBXYPk6bGFRFM2U3097yuyNXTOh5xCSB/z4OQpf5WYqdqY 9LYBYM6d7V3ffWQbjHRHrTDNwscV8CVhyxq/gG0s=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dnsop@ietf.org
Message-ID: <20180615171231.GF1126@mx4.yitter.info>
References: <CAKC-DJimMOtNCSE95kRs6Dy3dC_mxB=8O2WVA7badp8GK2ci-Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAKC-DJimMOtNCSE95kRs6Dy3dC_mxB=8O2WVA7badp8GK2ci-Q@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Pws84uJCxhbCB9cLam_siE9DrtE>
Subject: Re: [DNSOP] BCP on rrset ordering for round-robin? Also head's up on bind 9.12 bug (sorting rrsets by default)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.26
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, 15 Jun 2018 17:12:37 -0000

On Fri, Jun 15, 2018 at 11:45:19AM -0400, Erik Nygren wrote:
> A number of folks have been bitten by a bug in bind 9..12 where it silently
> changes the default sorting of rrsets to always be sorted (even if the
> authoritative response wasn't sorted).

I believe that RRsets are unordered sets by definition.  So I supect
that if people are relying on the order in which they come off the
wire, they're making a mistake.

This is a common mistake with unordered data sets; it results in lots
of complaints about SQL data responses, too, for instance.  (Of
course, in that case you always have the option of using an ORDER BY
clause, which we don't have in the DNS.)

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com