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

Paul Vixie <paul@redbarn.org> Fri, 15 June 2018 17:24 UTC

Return-Path: <paul@redbarn.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 50AA4124D68 for <dnsop@ietfa.amsl.com>; Fri, 15 Jun 2018 10:24:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.88
X-Spam-Level:
X-Spam-Status: No, score=-0.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 1F80DNkXYXFb for <dnsop@ietfa.amsl.com>; Fri, 15 Jun 2018 10:24:02 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A63F124C04 for <dnsop@ietf.org>; Fri, 15 Jun 2018 10:24:02 -0700 (PDT)
Received: from [10.1.107.71] (unknown [194.157.37.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 8839289291 for <dnsop@ietf.org>; Fri, 15 Jun 2018 17:24:01 +0000 (UTC)
Message-ID: <5B23F62E.8060900@redbarn.org>
Date: Fri, 15 Jun 2018 20:23:58 +0300
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.25 (Windows/20180328)
MIME-Version: 1.0
CC: dnsop@ietf.org
References: <CAKC-DJimMOtNCSE95kRs6Dy3dC_mxB=8O2WVA7badp8GK2ci-Q@mail.gmail.com> <20180615171231.GF1126@mx4.yitter.info>
In-Reply-To: <20180615171231.GF1126@mx4.yitter.info>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/d3vxXDswcSEPlkzujlZ1L0M-5mU>
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:24:04 -0000


Andrew Sullivan wrote:
> 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.

that's what i've always said. especially after adding round-robin and 
getting all the complaints about it. famously one complaint came from 
TGV, who had a terminal server product that used TXT RRsets to describe 
possible "hosts" that could be reached through their product. for their 
internal corporate network, they had encoded carroll's _Jabberwocky_, 
one verse per internal server. the bug report that came to me as the 
BIND4 maintainer was, "you're scrambling jabberwocky" or words to that 
effect. my response when closing the report was, "how can you tell?"

> 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.)

i think round-robin does more good than harm. another famous bug report 
from the BIND4 era when i first added round-robin was from UC Berkeley, 
who had two NS RRs for berkeley.edu, and the second one had never 
worked, and after i added round-robin, it started to receive queries for 
the first time ever. to that complaint i said, "fix your NS RRset."

so while there's no way to please everybody, and while depending on the 
order (or in today's case, on the lack of order) of data whose ordering 
is not guaranteed is certainly an error, it's very implicit one, and we 
need sensible defaults rather than interminable whichness-of-what arguments.


-- 
P Vixie