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

Jared Mauch <> Fri, 15 June 2018 16:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1BF3312F18C for <>; Fri, 15 Jun 2018 09:08:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5ezAR96yN9ve for <>; Fri, 15 Jun 2018 09:08:27 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 713DD130DC0 for <>; Fri, 15 Jun 2018 09:08:27 -0700 (PDT)
Received: from [IPv6:2603:3015:3606:cbe1:f5e8:84c:9df6:764a] (unknown [IPv6:2603:3015:3606:cbe1:f5e8:84c:9df6:764a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 1EF62540AE1; Fri, 15 Jun 2018 12:08:25 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Jared Mauch <>
In-Reply-To: <>
Date: Fri, 15 Jun 2018 12:08:22 -0400
Cc: dnsop WG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Erik Nygren <>
X-Mailer: Apple Mail (2.3445.6.18)
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: Fri, 15 Jun 2018 16:08:30 -0000

> On Jun 15, 2018, at 11:45 AM, 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).  This causes problems for services assuming at least some degree of round-robin behavior by clients as now many clients would sent all traffic to only the lowest IP.  Bug details:   If you are upgrading to or have upgraded to bind 9.12 you likely want to take a fix or override in config.
> This raises the question of whether there would be value in a more modern BCP covering round-robin expectations for recursive resolvers?  I suspect many (most?) service operators take at least some degree of DNS round-robin behavior by recursive resolvers as a default.
> I suspect starting assumptions are roughly in the range of:
> * Recursive (and stub?) resolvers (SHOULD/MUST?) do some form of round-robin in RRset responses.

Stub is in your desktop (and possible application, but may vary depending on OS, etc).

> * There are a variety of ways to implement round-robin (randomize, permute, etc).

Sure, but services should also be sufficiently robust should there be some amount of polarization in the hash algorithm.  I recall when the entropy went into bind4 to assist with balancing of some web services as well as mail/ftp stuff.

Perhaps this is something that could be done better with a flavor of happy-eyeballs in the client application, whereby you race not just v4 vs v6 but also some limited subset of answers the application gets back as part of getaddrinfo()

> * Server operators need to be aware that round-robin may be a part of a load balancing scheme (especially if capacity is far greater than average demand) but should not be relied on exclusively.  (Perhaps with examples of why...)
> Am I missing something in-terms of an existing BCP to this effect?  There's RFC 1794, but I couldn't find much else (but given the sheer number of DNS RFCs it's very likely I missed one).

Have you checked the DNS Camel :-)

I didn’t find anything else looking real quick, and it gave me a reminder of some of the folks that I used to interact with at ANS back in the day, so at least for a Friday it’s a fun and quick re-read to hit up 1794.

- Jared

> Best, Erik
> _______________________________________________
> DNSOP mailing list