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

[Shumon Huque <[e-mail]>]

On Tue, Jun 19, 2018 at 2:51 PM 神明達哉 <[e-mail]> wrote:

> At Mon, 18 Jun 2018 17:51:26 -0400,
> Shumon Huque <[e-mail]> 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.