Description of problem: I just upgraded from F12 to F13 and that broke the precedence of IPv6 addresses over IPv4 (i.e. currently A records are used no matter if an AAAA record exists). I've tracked the problem down to the default getaddrinfo() result ordering - when /etc/gai.conf is empty/nonexistent, IPv4 addresses are sorted first. However, when I paste the supposed default rules from the gai.conf manpage to /etc/gai.conf, suddenly IPv6 is correctly preferred. I've even tried setting "options inet6" in resolv.conf, but it didn't change anything. Version-Release number of selected component (if applicable): glibc-2.11.90-20.x86_64 How reproducible: always Steps to Reproduce: 1.get rid of any /etc/gai.conf rules on a machine with IPv6 connectivity 2.run getent ahosts www.nix.cz (calling getaddrinfo() directly in a test program yields the same results) Actual results: 195.47.235.3 STREAM info.nix.cz 195.47.235.3 DGRAM 195.47.235.3 RAW 2a02:38::1001 STREAM 2a02:38::1001 DGRAM 2a02:38::1001 RAW Expected results: 2a02:38::1001 STREAM info.nix.cz 2a02:38::1001 DGRAM 2a02:38::1001 RAW 195.47.235.3 STREAM 195.47.235.3 DGRAM 195.47.235.3 RAW (Of course, using fedoraproject.org exhibits the same behavior, just the outputs are much longer.)
Created attachment 408867 [details] A simple test program
What are your interfaces and routes?
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 00:19:66:42:b3:ca brd ff:ff:ff:ff:ff:ff inet 192.168.169.5/29 brd 192.168.169.7 scope global eth0 inet6 fe80::219:66ff:fe42:b3ca/64 scope link valid_lft forever preferred_lft forever 3: teredo: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc pfifo_fast state UNKNOWN qlen 500 link/[65534] inet6 2001:0:53aa:64c:2872:9752:a64f:f89d/32 scope global valid_lft forever preferred_lft forever inet6 fe80::ffff:ffff:ffff/64 scope link valid_lft forever preferred_lft forever 192.168.169.0/29 dev eth0 proto kernel scope link src 192.168.169.5 169.254.0.0/16 dev eth0 scope link metric 1002 default via 192.168.169.1 dev eth0 unreachable ::/96 dev lo metric 1024 error -101 mtu 16436 advmss 16376 hoplimit 4294967295 unreachable ::ffff:0.0.0.0/96 dev lo metric 1024 error -101 mtu 16436 advmss 16376 hoplimit 4294967295 2001::/32 dev teredo proto kernel metric 256 mtu 1280 advmss 1220 hoplimit 4294967295 unreachable 2002:a00::/24 dev lo metric 1024 error -101 mtu 16436 advmss 16376 hoplimit 4294967295 unreachable 2002:7f00::/24 dev lo metric 1024 error -101 mtu 16436 advmss 16376 hoplimit 4294967295 unreachable 2002:a9fe::/32 dev lo metric 1024 error -101 mtu 16436 advmss 16376 hoplimit 4294967295 unreachable 2002:ac10::/28 dev lo metric 1024 error -101 mtu 16436 advmss 16376 hoplimit 4294967295 unreachable 2002:c0a8::/32 dev lo metric 1024 error -101 mtu 16436 advmss 16376 hoplimit 4294967295 unreachable 2002:e000::/19 dev lo metric 1024 error -101 mtu 16436 advmss 16376 hoplimit 4294967295 unreachable 3ffe:ffff::/32 dev lo metric 1024 error -101 mtu 16436 advmss 16376 hoplimit 4294967295 fe80::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295 fe80::/64 dev teredo proto kernel metric 256 mtu 1280 advmss 1220 hoplimit 4294967295 default dev teredo metric 1029 mtu 1280 advmss 1220 hoplimit 4294967295
This is deliberate, see bug 577626 for details.
In that case the gai.conf(5) man page is terribly misleading (claiming a default that is actually not used), please fix it (stating this is a deliberate violation of RFC3484). Perhaps this change of getaddrinfo() behavior should be mentioned in the release notes for F13, too (so that other users do not wonder why something that worked for years suddenly broke without warning).