On Tue, Jun 19, 2018 at 2:51 PM 神明達哉 <jin...@wide.ad.jp> wrote:
> At Mon, 18 Jun 2018 17:51:26 -0400, > Shumon Huque <shu...@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.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
