NM fails to list IPv6 nameservers before IPv4 ones

Created attachment 467312
Proposed patch to correct /etc/resolv.conf ordering.

Description of problem:
In currently version of NetworkManager in Fedora, IPv6 DNS nameservers are getting prioritised last in /etc/resolv.conf this doesn't seem right compared to prioritization of IPv6/IPv4 in general IP stacks (for instance, web browsing).

Version-Release number of selected component (if applicable):
NetworkManager-0.8.1-10.git20100831.fc14.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Set up a dual stack IPv6/IPv4 network, in my case radvd is announcing IPv6 nameservers & IPs, dhcp is announcing IPv4 IPs & nameservers.
2.
3.

Actual results:

NetworkManager will write a /etc/resolv.conf in the following order:

domain <foo>
search <bar>
nameserver [IPv4 VPN Nameservers]
nameserver [IPv4 LAN Nameservers]
nameserver [IPv6 VPN Nameservers]
nameserver [IPv6 LAN Nameservers]

This means that DNS queries will happen over the IPv6 stack last.

Expected results:

My expected ordering is:

* IPv6 VPN Nameservers
* IPv4 VPN Nameservers
* IPv6 LAN Nameservers
* IPv4 LAN Nameservers

I prioritise IPv4 VPN over IPv6 LAN in consideration that there will be some IPv4 only VPN networks around for a while.

Additional info:

I have a patch that has worked over the last week on my home/personal laptop that corrects this issue. (Attached)

hm... certainly ip6_vpn_config should go above ip4_device_config (ignoring the fact that we don't have any ipv6 vpns yet...). Not sure if there's any rule that says ipv6 should go above ipv4 in general. I think for now it's probably better to keep ipv4 first, since people are more likely to accidentally have a broken ipv6 config than they are to accidentally have a broken ipv4 config...

That was my reasoning too, since people are *still* trying to work out IPv6. And you can still get IPv6 answers via IPv4 nameservers too, which depends on the IPv4 nameservers being set up correctly with AAA records of course.

Note that glibc also has a maximum of *3* 'nameserver' entries in resolv.conf, so if we really had both IPv4 VPN & normal and IPv6 VPN and normal nameservers, we'd be one over the limit. The only way to fix this is to use a local caching nameserver.

glibc queries the nameservers in the order they are listed in resolv.conf, so if the IPv4 servers don't know the address of the IPv6 machine it should fail and glib will query the IPv6 server. The apps themselves are the things that request AAA records (IPv6) instead of the A records and they are the ones that decide what to do with the records that actually get returned too. So unless the app is badly coded, is there a real difference which nameservers are first? Is ordering necessary to work around bad servers?

(In reply to comment #2)
> Is ordering necessary to work around bad servers?

There are some nameservers that drop AAAA requests on the floor. (Not many, and probably a lot fewer than there were a few years ago.) Using such a nameserver when you also have a global IPv6 address (presumably via a tunnel) will cause DNS resolution to become really slow, because you have to wait for glibc to time out on the AAAA request every time.

Presumably you're not likely to find such a broken nameserver listening on an IPv6 address. (Though, this being the internet, there's probably at least one, somewhere out there.) So that would be a point in favor of putting the IPv6 servers first. Not sure how it weighs against the "more likely to have broken IPv6 than IPv4" point.

(In reply to comment #2)

> So unless the app is badly coded, is there a real difference which
> nameservers are first? Is ordering necessary to work around bad servers?

Nearly two years down the track, and I'm beginning to agree, although, since then, systems like OpenVPN are getting close to IPv6 (OpenVPN 2.3 Alpha 3 has IPv6 support [1]), so at least correct priority of IPv6 VPN name servers over IPv4/6 LAN nameservers will be somewhat important in the near future.

It was my understanding when I filed the patch that there was likely an RFC that denoted the correct ordering of nameservers et al. in IPv4/v6 environments to match the expected prioritization of when IPv4 and IPv6 is available for a service/destination, IPv6 is chosen. But I haven't managed to find one, so my original reasoning appears to be out the window.

[1]: http://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn23

This message is a notice that Fedora 14 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 14. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 14 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping