RFC 6724

Florian Weimer fweimer@redhat.com
Mon Nov 12 11:21:00 GMT 2018

* Phillip Hellewell:

> Assuming the comments in gai.conf are accurate, glibc still use
> obsolete RFC 3484 for address selection.
> RFC 6724 came out in 2012, so why does glibc still use RFC 3484 rules?
> The changes since RFC 3484 can be seen here:
> https://tools.ietf.org/html/rfc6724#appendix-B

RFC 3484 has always been rather problematic (particularly Rule 9, which
we do not implement).

I seriously doubt that there is any benefit from address sorting.  It's
a layering violation, and it makes renumbering harder because you now
need to consider the impact on address sorting.  Its core assumptions
are also quite wrong on many networks (e.g., private addresses often
have less georeplication than public Internet service, so public
addresses are closer by).

In any case, I think address sorting should be performed by the caching
DNS resolver, not the stub resolver.  The caching resolver can obtain
more topology information.  For individual, short-lived application
processes, this is very hard.  On the stub resolver side, the only thing
that remains is the A/AAAA sorting policy because the caching DNS
resolver does not determine that.

Do you have a setup that actually relies on address sorting?  Do you
have any examples where DNS provides a set of addresses for a single
name with different labels/precedence, so that sorting the addresses
actually has an effect?

Currently, we have a lot of code which is questionable at best when it
makes a difference, but it's mostly unused.  I would like to remove it,
rather than keep maintaining it.


More information about the Libc-help mailing list