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

Shumon Huque <shuque@gmail.com> Tue, 19 June 2018 21:26 UTC

Return-Path: <shuque@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28FBE130E51 for <dnsop@ietfa.amsl.com>; Tue, 19 Jun 2018 14:26:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0I1nwrAiust for <dnsop@ietfa.amsl.com>; Tue, 19 Jun 2018 14:26:10 -0700 (PDT)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B639130E2F for <dnsop@ietf.org>; Tue, 19 Jun 2018 14:26:10 -0700 (PDT)
Received: by mail-yw0-x22a.google.com with SMTP id p129-v6so429195ywg.7 for <dnsop@ietf.org>; Tue, 19 Jun 2018 14:26:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GBXJpXAnYlRfqQM6wxmaeEpXI5Du0Bz5rpk97EWf/8c=; b=kd+MbD2KmiaqrkoE4JEgwoFLxewyitvBO/5tf+UsrpnrCv0uKF7LgwagN9RZ/OqqBh wgpuIRMjNuKdV2bF+X0QdgZUVnHPts1JuDfF9ktmcVDg29FH8WYPOlTER9efrGSqrzFT bUTwG8LjLyoOqkWieAT4yO1IXqCm4uh4ugNSxWlLgj2zeu3Z5u0TXLa1YKjP1alhhMx0 fSVbGShlYFWNqlBRrhDs13/n9zIE81WvSqGaFMlFoZ7Rx7mIPkozfLdt/Cxld9jz/A6c nXkQHgh8EV8VxweR8/0Du7DH8LU/CFttymkHzZAIcG6T8ZIRB1GEMlr1Qnhe6iNnow1t BBSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GBXJpXAnYlRfqQM6wxmaeEpXI5Du0Bz5rpk97EWf/8c=; b=jpPW1uRuMzUKLRA2Hi1z9eHwhxKK/4a/oPjSK3yO9Gg2klhcKrOOu2E/lcLpAEZV3l ww7iRB6E0BUsvqXgvufrAO6zax+Qrkwc9037qAxfD/loZCebNBysKR6YpMxk8KUNr73H Jl9IvJvXafDi0L9sHQC6MUKpRwhc3zi99CzK0wRI3hYuw/m0domZ9Opa4b8Rz42LlNdR L9CG8uGWy+kWkHAbgXKvzKNeEHWC4cc4AQhD712MXa3H7dxNWp9gg5Do/Aw+ZndemfGY XaThMiFPc2tDagrxX/AwcCbE1c/eWT3BRtF3s20tyy6z6v9tiTVC7BzdOqTqvuxpedku +Bog==
X-Gm-Message-State: APt69E2GNAKXxpa0Jfau22oqeGz9DrqCkhOPE/vGU5gkCsHkEvVvZnYO AxIIcMOKh4vuq6za6CZAQdp13MWnaUS7VABSyMA=
X-Google-Smtp-Source: ADUXVKJ6LT2LL+n1woMrEu0xjpaBsoMwr4+sxk9W1Jj/8j+4hA03GT0fTbHRduIAk3/jXHuaKE2pQGBCi24LTDlInJk=
X-Received: by 2002:a0d:c9c6:: with SMTP id l189-v6mr9098920ywd.164.1529443569865; Tue, 19 Jun 2018 14:26:09 -0700 (PDT)
MIME-Version: 1.0
References: <CAKC-DJimMOtNCSE95kRs6Dy3dC_mxB=8O2WVA7badp8GK2ci-Q@mail.gmail.com> <20180615171231.GF1126@mx4.yitter.info> <CAHPuVdWP=DVj52diWYTHKqHBET0hFyUWvACT-VpH20iKzed-ww@mail.gmail.com> <CA+nkc8AS6+cZfi_NGT2T+FeQkQ5fKn--HQOOuusL1cYFkdKbKA@mail.gmail.com> <20180615195232.GA5926@jurassic> <CAKC-DJhRJwg7cw8iexCgq9axgjyjnQQaXP2+wD4u=sk3PtypRg@mail.gmail.com> <20180618150157.GB9377@mx4.yitter.info> <5B27EFB7.1020400@redbarn.org> <874lhzu7ae.fsf@mid.deneb.enyo.de> <CAHPuVdXiM3X3hyN14+JJEXWhSrjdepj1PwRDW07mzHmgLcHjAw@mail.gmail.com> <CAJE_bqfjGwMGLTEMp6L77RUihC9Jzkq_BcBVp=643H0RcjnkAQ@mail.gmail.com>
In-Reply-To: <CAJE_bqfjGwMGLTEMp6L77RUihC9Jzkq_BcBVp=643H0RcjnkAQ@mail.gmail.com>
From: Shumon Huque <shuque@gmail.com>
Date: Tue, 19 Jun 2018 17:25:58 -0400
Message-ID: <CAHPuVdW=iPYn23H5Vc1EqTmupu9vyvHLez5dG+u9dR8AVxu91w@mail.gmail.com>
To: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Cc: fw@deneb.enyo.de, "dnsop@ietf.org WG" <dnsop@ietf.org>, Paul Vixie <paul@redbarn.org>
Content-Type: multipart/alternative; boundary="000000000000af9873056f0554dd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/MbWEQ5NJx-_438OFiVu7nyfrsLQ>
Subject: Re: [DNSOP] BCP on rrset ordering for round-robin? Also head's up on bind 9.12 bug (sorting rrsets by default)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Jun 2018 21:26:14 -0000

On Tue, Jun 19, 2018 at 2:51 PM 神明達哉 <jinmei@wide.ad.jp> wrote:

> At Mon, 18 Jun 2018 17:51:26 -0400,
> Shumon Huque <shuque@gmail.com> wrote:
>
> > 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.
>
> The very original implementation of BSD getaddrinfo() conformed to the
> RFC, but FreeBSD seems to have changed the behavior a few years ago so
> rule 9 wouldn't apply to IPv4 addresses:
>
> https://github.com/freebsd/freebsd/commit/1390d13ae69089142f6c6465dbb24438f295edee
> The commit log suggests the rrset round-robin was exactly the
> motivation for the change (whether it was good or bad).
>

I took a quick look at glibc upstream source (from which I presume most
Linux distros take code) and see the following:

https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/posix/getaddrinfo.c;h=553833d1f22d6ea4ae24c68fe14e2140aa059d50;hb=HEAD#l1559

/* Rule 9: Use longest matching prefix.  */
[...]
          /* Outside of subnets, as defined by the network masks,
             common address prefixes for IPv4 addresses make no sense.
             So, define a non-zero value only if source and
             destination address are on the same subnet.  */

So again, no Rule 9 implementation for IPv4, unless there is a local subnet
destination involved, because it makes no sense otherwise (with which I
agree, as I previously remarked).

Shumon.