There's a Bugzilla bug in, 1467, titled 'resolver(5) "sortlist" option
missing' that was closed with an unacceptable resolution. The issue,
which we suffer from as well, is that the resolver libraries in "glibc"
on redhat don't support the "sortlist" option in "/etc/resolv.conf". The
"sortlist" option allows you to sort responses returned from BIND in
chosen network order and is particularly used to make lookups for hosts
with multiple interfaces work correctly when clients share some common
networks.

Without this option there is no way, at least that I know, for a Linux
client to consistently choose the correct interface on a server with
multiple interfaces. For instance, we have a server, Leda, with two
addresses:

    leda.coat.com.      IN      A       164.153.1.2
                        IN      A       192.168.100.5

If the client Blackhole:

    blackhole.coat.com. IN      A       192.168.100.6

which is on the same network as one of the two interfaces of Leda, but
not on the other goes to connect to Leda through Telnet, NFS, or any
other media under Linux it will always randomly select one of the two
addresses rather than making the correct choice of "192.168.100.5". That
is, telnet or NFS from Blackhole might select "164.153.1.2" not
"198.168.100.5" because there is no way to sort the addresses by local
network. If "sortlist" did work then we could add:

    sortlist 192.168.100.0

to Blackhole's "/etc/resolv.conf" and this would fix this.

This Redhat choice is wrong for large networks in production
environments. It essentially makes Linux clients inappropriate for use
in large enterprises with systems that have multiple interfaces. It also
makes RedHat effectively incompatible by default with other Unixes such
as Sun and IRIX which do provide this functionality (Suns even sort by
local interfaces by default period).

I ask that RedHat reconsider this ill chosen decision to not make the
resolver libraries with the -DRESOLVSORT.

Matt Fahrner
Manager of Networking
Burlington Coat Factory



_______________________________________________
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-devel-list

Reply via email to