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

"Darcy Kevin (FCA)" <> Mon, 18 June 2018 23:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E37A8130E54 for <>; Mon, 18 Jun 2018 16:04:27 -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 hisaA1okuh5b for <>; Mon, 18 Jun 2018 16:04:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E8AAB130E36 for <>; Mon, 18 Jun 2018 16:04:24 -0700 (PDT)
Received: from (Unknown_Domain []) by (Symantec Messaging Gateway) with SMTP id 2F.38.05436.46A382B5; Mon, 18 Jun 2018 19:04:04 -0400 (EDT)
X-AuditID: 81096b23-31fbb9800000153c-07-5b283a64c4ee
Received: from (Unknown_Domain []) by (Symantec Messaging Gateway) with SMTP id 92.CD.16655.957382B5; Mon, 18 Jun 2018 18:51:06 -0400 (EDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 18 Jun 2018 19:04:22 -0400
Received: from ([fe80::cc0c:cb4f:1b3f:2701]) by ([fe80::cc0c:cb4f:1b3f:2701%18]) with mapi id 15.00.1365.000; Mon, 18 Jun 2018 19:04:21 -0400
From: "Darcy Kevin (FCA)" <>
To: dnsop WG <>
Thread-Topic: [DNSOP] BCP on rrset ordering for round-robin? Also head's up on bind 9.12 bug (sorting rrsets by default)
Thread-Index: AQHUBL/ub2Lp5GPc1U6ETp2lBUeQrqRl9JWAgACspDA=
Date: Mon, 18 Jun 2018 23:04:21 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyfbVnrm6KlUa0wbEXHBZ331xmcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrLJL9kKtkhVHH39k6WB8Y5kFyMnh4SAicS6WeeYQGwhge2M Eu0feOHi63+xdjFyAcXXM0p0L5zCCOGsY5TY0fqRBaJjJ6PE0T9aIDYbUMfCK3eZuxg5OEQE ZCX2vo4CCQsLVEqcXDqPGcQWEaiSuHV3DSOEbSUx7fJSsMUsAqoS59e0s4LYvAJOEt9uPWGD 2NXCKPH41h82kASngJ3ErlkzwZoZBcQkvp9aA9bMLCAucevJfCaIqwUkluw5zwxhi0q8fPyP FcI2kNi6dB8LhK0k8e3VGjaQO5kFNCXW79KHGKMoMaX7ITvEDYISJ2c+gSqfyyHx9l3mBEbJ WUi2zULonoWkexaS7gWMLKsYpfNTknITCwzM9VIrSooS9ZIziiqLc1KL9JLzczcxAqOvkTNb eQfjlLmWhxgFOBiVeHibxTWihVgTy4orcw8xSnAwK4nwJv9SjxbiTUmsrEotyo8vKs1JLT7E KM3BoiTOWySlEi0kkJ5YkpqdmlqQWgSTZeLglGpgVPZalWZ0hCut/K2+0I9pJbzb1lf+MCxS fHbZ/+ubHk8WU86/O5LUcxYc3SQ4fdK7Gv1pC+9mZFzhbPjZVaag/urqs1cPA8RuKZ+9enFG 2F8mnVi/bZu8vipuW8pl7CqTlsn41yotaNXhJxlVs/u37Zi80sqn73LshPM6+Z/rdkcfvKx6 7eFKTyWW4oxEQy3mouJEABpF5Uq6AgAA
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMKsWRmVeSWpSXmKPExsUyfbWInm6UuUa0wbQ7RhZ331xmcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrLJL9kKtkhVHH39k6WB8Y5kFyMnh4SAicS69b9Yuxi5OIQE 1jNKdC+cwgjhrGOU2NH6kQWkSkhgJ6PE0T9aIDYbUMfCK3eZuxg5OEQEZCX2vo4CCQsLVEqc XDqPGcQWEaiSuHV3DSOEbSUx7fJSJhCbRUBV4vyadlYQm1fASeLbrSdsELtaGCUe3/rDBpLg FLCT2DVrJlgzo4CYxPdTa8CamQXEJW49mc8EcbWAxJI955khbFGJl4//sULYBhJbl+5jgbCV JL69WsMGciezgKbE+l36EGMUJaZ0P2SHuEFQ4uTMJywTGMVmIdkwC6FjFpKOWUg6FjCyrGKU Ks5Iyk0sMLDUK85ISdZLziiqLM5JLdJLzs/dxAiOGc+cHYz/F1oeYhTgYFTi4Z0qrBEtxJpY VlyZe4hRkoNJSZQ35KV6tBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR3uRfQDnelMTKqtSifJiU NAeLkjivSoFDoJBAemJJanZqakFqEUxWg4NDoHfN6guMUix5+XmpShK8gtxAOwWLUtNTK9Iy c0oQSpk4OEEW8QAtesAFVMNbXJCYW5yZDpE/xWjO8aatp4eZY9oyEPnk8jQguWpJ/wRmIbDR UuK8uWxAbQIgbRmleXCTXzGKAz0rzLsNZCgPMKXCzXwFtI4JaN2WKpC/iksSEVJSDYz600wa 5H0lb+f0HTu7qVHiht2TkLfnBfpOTq/KVEvzkLlk95SZa7fQ1M2zT2lJMUyy8DqmrOR+K/r+ 1YiwK12LElyXcjayWEz39jWZuLc7I2bylQX27maraha01/lUaJ45qnNO4Snztw7XyzYhEcFe Fya1fJKP9nFQWLvyhJ3mn10xjaJ37JVYijMSDbWYi4oTAfUla1NmAwAA
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: Mon, 18 Jun 2018 23:04:28 -0000

RFC 6724 specifically says: "Rules 9 and 10 MAY be superseded if the implementation has other
means of sorting destination addresses. For example, if the
implementation somehow knows which destination addresses will result
in the 'best' communications performance."

So, technically, if an implementation chooses a method of "the exact order in which I received the address records from my upstream resolver" as a way to produce the "'best' communication performance", given the circumstances, then that is technically not a violation of the standard. The local optimization is to trust the upstream resolver to Do The Right Thing. It's not always a wise choice, but most of the time it's better than sorting based on prefix-length matching (right?)

RFC 6724 is, after all, about *default* address selection (that word is even in the title of the RFC). Defaults are made to be superseded -- that's kind of the definition of what a default *is*.

											- Kevin

-----Original Message-----
From: DNSOP <> On Behalf Of Florian Weimer
Sent: Monday, June 18, 2018 4:23 AM
To: Erik Nygren <>rg>; dnsop WG <>
Subject: Re: [DNSOP] BCP on rrset ordering for round-robin? Also head's up on bind 9.12 bug (sorting rrsets by default)

On 06/15/2018 05:45 PM, Erik Nygren wrote:
> 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.
> * There are a variety of ways to implement round-robin (randomize, 
> permute, etc).
> * 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?

Unless all addresses happen to have identical shared prefix length with the client address (that is, count-leading-zeros(client-address XOR
server-address) is the same), RFC 6724 Rule 9 requires that clients do
*not* perform random server selection.

I think this was a mistake in RFC 3484, and it is still wrong.  But I think procedurally, you cannot change this in a BCP.


DNSOP mailing list