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

Erik Nygren <erik+ietf@nygren.org> Fri, 15 June 2018 20:17 UTC

Return-Path: <nygren@gmail.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 63ECF130E58 for <dnsop@ietfa.amsl.com>; Fri, 15 Jun 2018 13:17:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Level:
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 f2-DY3i35yyZ for <dnsop@ietfa.amsl.com>; Fri, 15 Jun 2018 13:17:02 -0700 (PDT)
Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 A8F2C130E44 for <dnsop@ietf.org>; Fri, 15 Jun 2018 13:17:02 -0700 (PDT)
Received: by mail-it0-x229.google.com with SMTP id 188-v6so4380882ita.5 for <dnsop@ietf.org>; Fri, 15 Jun 2018 13:17:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=NaUCJSYL4CrcdkHf18/t90Aw7551Z/VSZhcgB7Pocjs=; b=NVjBfR+GcDN1FCmhaPMEJ58LQmlKZbobhRF7DIiNZW3iDnW4VSVOALaP7Qh9se8yYK TJ0U644eMkFNmCUZBfBHm5/OXjJFESLxnz/+SYuqxCS91iKZ0qvuxfe32syaFZzSAeZ7 1RxoIAbiw6UPWzXLZuI+jSRNammqLm2JVBgWgOKCsmTxuCZOFT8EXiSuPjVz81wu0ept iU+aNtJ7Ryuii5SHhhYHV48nt1HHQE6mxbffkd4RxfGtxAEJEPwyebtDKQBt/hLX9dK0 usrIvV88O4WtVpDSGpkui+cRWqokOSBlfTLwbGXCNY4q3K4GqqIsB/Fumbb6ep0OSeHy zO8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=NaUCJSYL4CrcdkHf18/t90Aw7551Z/VSZhcgB7Pocjs=; b=IJVIhgEn1L+LamiWpV4ldYgW8RhODtyejlXk7+eOlNXXlSn1VDYXnfUAtl8LVDJvHN FNtEpD5Iwin6s6XxgFsj9epzBfk1TFMNGgG8E/k5Qc6msBDhreq86D3I/wVO7O4fCEcz MOsrPoJw/hst0abZiQdXu1zZ7UtuHi/t020J3A6WcY2Vt3MtVV4OuH1EZHBGSx6BilgO zawPtpdVI8wXG/HXoWHndtnOGXy8qAsrX7ta1arIBRrtwqIDGSMoCjgTyRnNa8d6BIrx 2V1vsPXZUw9+NKQP+drvtJWVZwjQ/pujyuVUoKH1sNsd2OoVqywK8XWVZnENTy/JVmvK y0og==
X-Gm-Message-State: APt69E1HYlSFFlKGdUMTi6LsxOOYdY6NF4clRXIEID8rbRCw+jGvmv/6 NO/KPvmBxgdrHsZye2RTN+qwKEzLTgCYov+5K6o=
X-Google-Smtp-Source: ADUXVKKlqtmfX5uZqp9rRCxYWQnfswqry56To7YkUXFEoghPHANDZ9nAGlQSismirTYn1dBYTMraTK0bh1t6o7bhEio=
X-Received: by 2002:a24:4e8f:: with SMTP id r137-v6mr2678253ita.9.1529093821732; Fri, 15 Jun 2018 13:17:01 -0700 (PDT)
MIME-Version: 1.0
Sender: nygren@gmail.com
Received: by 2002:a4f:4f4f:0:0:0:0:0 with HTTP; Fri, 15 Jun 2018 13:17:00 -0700 (PDT)
In-Reply-To: <20180615195232.GA5926@jurassic>
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>
From: Erik Nygren <erik+ietf@nygren.org>
Date: Fri, 15 Jun 2018 16:17:00 -0400
X-Google-Sender-Auth: jmr5pN8jWlqBBMx-UQ_ENws99y0
Message-ID: <CAKC-DJhRJwg7cw8iexCgq9axgjyjnQQaXP2+wD4u=sk3PtypRg@mail.gmail.com>
To: Mukund Sivaraman <muks@mukund.org>
Cc: Bob Harold <rharolde@umich.edu>, IETF DNSOP WG <dnsop@ietf.org>, Andrew Sullivan <ajs@anvilwalrusden.com>
Content-Type: multipart/alternative; boundary="000000000000129e52056eb3e613"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/jDMpvUvz4GBxwX5szBsg_TAS3E0>
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 20:17:05 -0000

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