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

Shumon Huque <> Mon, 18 June 2018 21:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 91FEE130F05 for <>; Mon, 18 Jun 2018 14:51:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F10l0p-lOYeD for <>; Mon, 18 Jun 2018 14:51:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B9E7C129C6B for <>; Mon, 18 Jun 2018 14:51:38 -0700 (PDT)
Received: by with SMTP id t198-v6so6185832ywc.3 for <>; Mon, 18 Jun 2018 14:51:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WQVw1TMZ1BOJ27GBRMBk7SRFNSEARnlZsZcYdlqKwSg=; b=o8bXvmSg2UtMhWHEHTlnw+R2ObBkeY2CuWgWarr0wCI9PC1EaSPYZt0f87xazJgWDd 9p7WlatuPiQBT+Ab9Ia2m0iFPeCdykhmnidnjKJD+9kJQ43/2KDO7k4ml0rCxs8q0H3X G/QJd5QKPKIpo9vaLKzUETb0kmI/3lpWHjqsLcmkXVtcgYSBxL+40+G5WhbbZpwyZnEQ yCXd7nQhIu2LbpFvPV6Y0IWI9EZFk/UaO7YH/vwznf6gVqLMlOqK45vMhSKgZDzGolCC AGkw2G8WfjjeaZnRauK1JFytXzWzFtaREJtFx0I2TZVCHASW8FbS/gNxDvnotMKFnsPR fO+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WQVw1TMZ1BOJ27GBRMBk7SRFNSEARnlZsZcYdlqKwSg=; b=NllPlDTCnsUcg0vXdizdiV680mFYcQO8J7CwqjLPcwmmVUJuQBzs/UQ9r8HqM09XZe FM/K7UbvuSsoTyoqnSDHOYwRwzF2dcrecapT5pqbp/cD2xHtJyDimzle8VdCMsJ0yK14 fdIXoJ6JXWYgPJKTfXYFAUGQjpto8rEH4IqTE+v1UhM8e6rHPpPT9gH4R/rDoi04SpvS Y0ufR5yLz5WrpYWLprxaPa0j/O8tAO1jq24HWpTvMpudmPe75fEHF65piBXUPInQwhlI tj322/FbwVgM7Cx3caHcsCVWZVR0GJ2wC9bxDqpqHmVjfTEJlAImHtfBXAA4DnM/fMnB 3rUA==
X-Gm-Message-State: APt69E1XGVTYepSxdyYAvxnVIk8PzFvNfOP4irqRrPF2CYCQsRVoyGLa BAAyVMHT1yS4Fd9hWMHhvfsceYC0YKAQx3L7bHo=
X-Google-Smtp-Source: ADUXVKI6X2L7E87EMcGd1apfpUKQeUintusr8IuNddkogs/Cu5vo5UGiWjDIgDMZH751mVnGe/FcLjXj5fye3Jbpdeg=
X-Received: by 2002:a81:7a08:: with SMTP id v8-v6mr6972014ywc.275.1529358697963; Mon, 18 Jun 2018 14:51:37 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <20180615195232.GA5926@jurassic> <> <> <> <>
In-Reply-To: <>
From: Shumon Huque <>
Date: Mon, 18 Jun 2018 17:51:26 -0400
Message-ID: <>
Cc: Paul Vixie <>, " WG" <>
Content-Type: multipart/alternative; boundary="000000000000ed25b1056ef191b4"
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 21:51:41 -0000

On Mon, Jun 18, 2018 at 5:14 PM 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.

I assume you're talking about the default destination address selection
rules specified in RFC 6724 (Section 6, Rule 9). Yeah, I agree this doesn't
seem wise to me. I'm not sure what the goal here was - this doesn't get
the client the topologically closest destination (in the general case; even
for IPv6 addresses unless the Internet was using solely provider aggregated
hierarchical routing, which isn't the case).

> 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.

Client applications delegate address sorting to name resolution functions
like getaddrinfo() - correct?

Doing some quick tests of getaddrinfo() just now on a recent *NIX machine,
it appears to return addresses sorted roughly in accordance with RFC
6724, but rule 9 (longest prefix match) seems to be only applied to
IPv6 addresses. For IPv4 addresses (using an upstream resolver
that randomizes the response RRset), the order returned by getaddrinfo()
is ever changing - I assume presented in the order received.

I haven't actually read the code, so perhaps someone can confirm this, or
share what portions of the default address selection algorithm common
name resolution libraries actually implement.