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

Colm MacCárthaigh <colm@allcosts.net> Fri, 15 June 2018 21:54 UTC

Return-Path: <colm@allcosts.net>
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 807F5130E74 for <dnsop@ietfa.amsl.com>; Fri, 15 Jun 2018 14:54:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.com
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 S7wXT5tNyiR5 for <dnsop@ietfa.amsl.com>; Fri, 15 Jun 2018 14:54:33 -0700 (PDT)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 136D1130E71 for <dnsop@ietf.org>; Fri, 15 Jun 2018 14:54:32 -0700 (PDT)
Received: by mail-yw0-x22a.google.com with SMTP id p129-v6so3836786ywg.7 for <dnsop@ietf.org>; Fri, 15 Jun 2018 14:54:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FDszY+ZesK1+LoTiFhjCjXAYtOwIzS3NovJywvkVqB0=; b=0NVBXyOfci9CbLLZm2kpUCv6eeDmIRFZMp1xj1hpbMFvoNoppotBqzZCzK8HpHhiMD hIqaPsJ++AjfQFDyUfwIKChqEkULscFdDGBGSyqPIehHDWgo4TqYAFDgCcuZBxF2NRn/ mWPxicROj014rn/YWYnTtVqkMAfdKCK/PSGi+6/ZVQUjQ6sEfSlwuh+gMeBIcGNLyO35 mPU2UUvqtuRi9mVtVIv0rIgxNa5cng7jqSzi4WsjOftRDfC6KhH4KJWC3AI8enma59gm A9QZWngAoVPYJ1QFU0cbaSQfJY0SIa5J9kydLQhzg/I28jtLkYY4PEY9RVDt5hDs0x5s Dmww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FDszY+ZesK1+LoTiFhjCjXAYtOwIzS3NovJywvkVqB0=; b=jLxJrL+sEq7MB88/xySMUC8yo/v/9sNiVvXxSL2d/4L3B34RAGi7fcVPk8qxmJVVC1 xw1ZZAb4p0OUMSScPmCmbGhTqu4uZ9vBIjIISuO1KhvG4io/u+3TbB/YqYnAsiAWEMxy vvjXXYlVLWgAe8XYW266U5moRS+HX7C+I+dVappK5+TEFm5mMzYC3EUNoWoqJmT/sxzT D9OS9LHJXbjmuN5Tmx8bAhXB8NPro1E+UdGb6pq9JMYOTGIfTCojwDNh21uFXBjOQqK5 4zgUfNri4FFoF06kFR2a5WSo+3HvPQ7iiKp7hH3vZkJqikmhEXxP229UNIq5v9/r1Qcu RyMw==
X-Gm-Message-State: APt69E1bkjrNWPg58pIVBTPLI6O8t5ekrSOYH/OOTruKHqBmpZu63sFx phkvZuIlCF/HUCt+wW8eOZP4IBTmf1J2FG+BB+g+Nw==
X-Google-Smtp-Source: ADUXVKKJJwZK9BQ2fk5eH4SlE1JoIMyA6OHqSxi3YG0L0lh91kAYlxJWew+p/mt8C+u9XQamRqeGeVNkkGGvAGjPCVg=
X-Received: by 2002:a0d:f885:: with SMTP id i127-v6mr1831498ywf.144.1529099671864; Fri, 15 Jun 2018 14:54:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a81:7bc4:0:0:0:0:0 with HTTP; Fri, 15 Jun 2018 14:54:31 -0700 (PDT)
In-Reply-To: <CAKC-DJhRJwg7cw8iexCgq9axgjyjnQQaXP2+wD4u=sk3PtypRg@mail.gmail.com>
References: <CAKC-DJimMOtNCSE95kRs6Dy3dC_mxB=8O2WVA7badp8GK2ci-Q@mail.gmail.com> <20180615171231.GF1126@mx4.yitter.info> <CAHPuVdWP=DVj52diWYTHKqHBET0hFyUWvACT-VpH20iKzed-ww@mail.gmail.com> <CA+nkc8AS6+cZfi_NGT2T+FeQkQ5fKn--HQOOuusL1cYFkdKbKA@mail.gmail.com> <20180615195232.GA5926@jurassic> <CAKC-DJhRJwg7cw8iexCgq9axgjyjnQQaXP2+wD4u=sk3PtypRg@mail.gmail.com>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= <colm@allcosts.net>
Date: Fri, 15 Jun 2018 14:54:31 -0700
Message-ID: <CAAF6GDfSoE9-VhuFeh2QkABamC0zmLO61qggV6YjP13wvLaQ7g@mail.gmail.com>
To: Erik Nygren <erik+ietf@nygren.org>
Cc: Mukund Sivaraman <muks@mukund.org>, Bob Harold <rharolde@umich.edu>, IETF DNSOP WG <dnsop@ietf.org>, Andrew Sullivan <ajs@anvilwalrusden.com>
Content-Type: multipart/alternative; boundary="000000000000c49eec056eb542ea"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Aa4CikBW2Cm8CnGzRNlUPyz2pRQ>
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 21:54:36 -0000

Just a question on this: was the old/classic behavior really
random/shuffled? Or was it that bind would "rotate" through iterations
where the order was the same each time if you think of the rrset list as a
ring, but with a different start and end point within that ring? (That's
what's described here:
https://docstore.mik.ua/orelly/networking_2ndEd/dns/ch10_07.htm)


On Fri, Jun 15, 2018 at 1:17 PM, Erik Nygren <erik+ietf@nygren.org> wrote:

> On Fri, Jun 15, 2018 at 3:52 PM, Mukund Sivaraman <muks@mukund.org> wrote:
>
>> On Fri, Jun 15, 2018 at 02:38:00PM -0400, Bob Harold wrote:
>> > Round-robin is a documented feature that many applications use.
>> Removing
>> > it from DNS resolvers, and then having to add it to a much larger
>> number of
>> > applications, does not seem like a good trade-off.
>>
>> The _default_ in BIND 9.12 was changed from order random to order
>> none. It seems to be missing from the release notes by mistake, but the
>> administrator manual mentions what the default is
>>
>
> We have many years of software that relies on emergent behaviors from the
> current default.
> While pedantically it may be true that these should be treated as
> unordered sets and that
> applications or stub resolver libraries should do some permutations or
> randomized selection,
> that doesn't match the current reality for widely used software (eg, curl
> and ssh, which I'm
> sure is just the tip of the iceberg).
>
> Software should have safe defaults that matches common expectations.
> Those common expectations, as demonstrated by the configuration of all
> of the large public resolvers I've tested, as well as by how common
> software behaves,
> is that the order of results is NOT consistent.  In many environments,
> this lack
> of consistency is relied upon for systems to work properly..  Switching to
> consistent
> order is no big deal on a small scale, but a widespread shift (eg, as
> would happen
> due to a change in default in popular software) would almost certainly
> have
> significant operational impact and is something that warrants significant
> discussion
> about the practical implications.
>
> This ambiguity in the current specifications results in this mismatch
> between the pedantic (rrsets are explicitly unordered, and a consistent
> order is a subset of that) and the current reality (applications and
> services
> rely on resolvers-at-scale to be explicitly inconsistent in the ordering
> of rrsets)
> is why I started off by proposing that we may need a BCP or informational
> RFC
> that describes the currently assumed defaults and best-practices
> (ie, round-robin is assumed in many places so don't consistently order
> at-scale by default).
>
>         Erik
>
>
>
>
>
>
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>


-- 
Colm