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

Paul Vixie <> Tue, 19 June 2018 13:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B7822130EBB for <>; Tue, 19 Jun 2018 06:02:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CEOq1Knb8AFr for <>; Tue, 19 Jun 2018 06:02:53 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 56CD3130EBC for <>; Tue, 19 Jun 2018 05:58:14 -0700 (PDT)
Received: from [IPv6:2001:559:8000:c9:c5a5:2598:307c:17c0] (unknown [IPv6:2001:559:8000:c9:c5a5:2598:307c:17c0]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id F17BB89291 for <>; Tue, 19 Jun 2018 12:58:11 +0000 (UTC)
Message-ID: <>
Date: Tue, 19 Jun 2018 08:58:10 -0400
From: Paul Vixie <>
User-Agent: Postbox 5.0.25 (Windows/20180328)
MIME-Version: 1.0
References: <> <> <> <> <20180615195232.GA5926@jurassic> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Tue, 19 Jun 2018 13:03:00 -0000

Florian Weimer wrote:
> * Paul Vixie:
>> in other words we should re-order rrsets by default, so that very few
>> people or agents are ever prone to think their order is stable. the spec
>> says they are unordered, but human nature says, expect more of what
>> you're seeing.
> But the client has to sort them again based on shared prefix length
> with its own address.

happy eyeballs says so, but some clients won't implement anything like 
that, or will have local knowledge (access to a routing table via an API 
of some kind) that gives them even better information. the question of 
what a client should do, and whether a given client can or should, is 
clearly independent of what order the response comes to them in.

> I think we should fix that as well, otherwise the overall protocol
> disadvantages new entrants who cannot get a contiguous prefix in
> which they can place all their load balancer endoints, so that they
> are immune from that mandatory client sorting.

i have no strongly held view on whether clients should sort. but i'm 
sure a client will have better information to base such sorting on than 
the dns servers will have. therefore i'd like to pursue a simple rule 
whereby the server perturbs the order somehow. simplistic clients, and 
clients who aren't nearby any shard of a load balanced service, should 
see some kind of chaos in the ordering, not just know it can be there.

P Vixie