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

Erik Nygren <> Sat, 16 June 2018 00:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E094D130F14 for <>; Fri, 15 Jun 2018 17:53:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 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, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 50AH74qfZ3Ox for <>; Fri, 15 Jun 2018 17:53:32 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7C388130F4C for <>; Fri, 15 Jun 2018 17:53:02 -0700 (PDT)
Received: by with SMTP id n7-v6so5074782itn.1 for <>; Fri, 15 Jun 2018 17:53:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=avCGWMgEyeqP+kw2qOSTziQSmTFk9IKvhEbJKabfCjg=; b=pwRkMfTj6DcD7t+OTQvRDyZtRp0xeykwlTkIKKNCDQ+HTTD+vNcuZHCuYK15YlR8bv Ev7bMLUilholngjvyXaXpTPkuKrNedtnPd8vFc3cVm3k8rda+bPm3F1myLLJcdnDQcy4 oPyjb2lrwCcK7uYI7nKpn6nCIrA6GTfGbMDYnU7xSoGIMolnSvPaK8d/fd/Z7hANHqGE QCag3BaWBC4n7/UA5tpnjQ7EToYguimatGazkVLodVID6gYbd9XOG/v7VCXCQl5dfIoP WffqUOWUOYqSmLFaHocyAUk9Nd7U6cvIMxFXn191KP4NWjAVIjpjzzZAT9Iu0rlmSIq3 rvcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=avCGWMgEyeqP+kw2qOSTziQSmTFk9IKvhEbJKabfCjg=; b=aEv5r38iJ5FgASfvz94CDB38xHnY6R12u9+5vT9zDO1PKHxvKBYeCobcQe+w/upJfi iho0r+LN+rJlRv1By+bkY1FbOTY7C3iVKp+aH4so3uzgxUMS2EZ7xmDDDda6W1kryIFj v/op2ZoJJNXpZUpfMzekRgNTIjruyvxnHyDKxCZlN7twjWDOiNlAkleYgYkIwE6RmGYl NzYAZlg9ukALoFV+CxU66iaeYqJWKZ0YyfbG9Rqv94KJmTIOjAzsM9cBKu+eUNDVz9Va RXFZzrm7+m35iAvK6/sCgkZ8VnWYFIL0HfOzfBc0owoWpQiNz5kVovrXhaz2e432juPI QlrQ==
X-Gm-Message-State: APt69E1En4pjpZBvwyiPRl2J8Q0ZwVjtyac8xFHS1GhvcnyzyDkrBCkW hTyjYP08b8k+NsEJ9//+oF51wpHTcSIMrq9nYns=
X-Google-Smtp-Source: ADUXVKKFesjVx+qLE06Vvp2tBSZtdeDR12r/HeaDaY4JtGPF1Oy1H0mF4Siyw9jA/AxYAQusW10EvvmHB8qlQgsXPKw=
X-Received: by 2002:a24:7809:: with SMTP id p9-v6mr3009344itc.20.1529110381666; Fri, 15 Jun 2018 17:53:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:4f4f:0:0:0:0:0 with HTTP; Fri, 15 Jun 2018 17:53:01 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Erik Nygren <>
Date: Fri, 15 Jun 2018 20:53:01 -0400
X-Google-Sender-Auth: zb3fMnUSEvKygzQJ_GcMiNp8SPs
Message-ID: <>
To: Shumon Huque <>
Cc: Mark Andrews <>, " WG" <>
Content-Type: multipart/alternative; boundary="0000000000001f28ee056eb7c199"
Archived-At: <>
Subject: Re: [DNSOP] BCP on rrset ordering for round-robin? Also head's up on bind 9.12 bug (sorting rrsets by default)
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 16 Jun 2018 00:53:43 -0000

On Fri, Jun 15, 2018 at 8:12 PM, Shumon Huque <> wrote:

> On Fri, Jun 15, 2018 at 6:40 PM Mark Andrews <> wrote:
>> What we should be asking is why a service that needs multiple machines
>> isn’t using SRV. It has randomisation between servers explicitly defined
>> along with proportional load balancing.
> That would be nice, but sadly major applications like the web, have (in my
> assessment) never seriously shown any interest in using SRV records. To
> quote some of the discussion of HTTP2 on this subject:

Agreed that it would be nice (and a good recommendation for protocols to
support SRV records),
but for all of the other protocols we're stuck operating today today with
the implementations we have,
not just the ones we wish we had.

(Side-note, I do recommend folks provide feedback on the ALTSVC draft:
It adds enough value and extensibility beyond just SRV that
browsers show more interest in implementing it.)

> Yeah, good point about side channels. Let's stick to recommending

Good point!  Agreed.  I hadn't thought about that and had otherwise been
thinking of shuffling and randomization as roughly equivalent as long as you
pick a random initial offset for the shuffling.
(More reasons to write current best practices down in a draft.)
Shuffling may also have some weird patterns showing up depending on the
relation between
TTLs and number of clients querying, but I don't know if this is ever
beyond the side-channel issue.