4 ms·

AAAA records have lower priority than A records if you don't have a v6 address assigned on your system. (Link-locals don't count for this). You would only see

by Dagger2 6mo ago

AAAA records have lower priority than A records if you don't have a v6 address assigned on your system. (Link-locals don't count for this). You would only see a timeout to an AAAA record if the connection attempt to the A record already failed. Some software (looking at you, apt-get) will only print the last connection failure instead of all of them, so you don't see the failure to connect to the A record. I've seen people blame v6 for this even though they don't have v6 and it's 100% caused by their v4 breaking. Run `getent ahosts example.com` to see the order your system sorts addresses into. `wget example.com` (wget 1.x only though) is also nice, because it prints the addresses and tries to connect to them in turn, printing every error. I mean... adding v6 is the right thing to do either way, but "AAAA is higher priority than A" isn't the reason.

nyrikki 6mo ago
> AAAA records have lower priority than A records if you don't have a v6 address assigned on your system. (Link-locals don't count for this). There is an expired 6man draft that explains some of the issues here. https://www.ietf.org/archive/id/draft-buraglio-6man-rfc6724-update-03.html https://www.ietf.org/archive/id/draft-buraglio-6man-rfc6724-... To be clear, I go and clean out the temporary fixes for dual stack problems, but you want some more info so here it is. $ grep 'apt.systemd.daily' /var/log/syslog.1 | grep '^2026-04-16T01:09' | wc -l 86375 $ grep 'apt.systemd.daily' /var/log/syslog.1 | grep '^2026-04-16T01:09' | head -n 1 2026-04-16T01:09:15.276295-06:00 MrBig apt.systemd.daily[45660]: /usr/bin/unattended-upgrade:2736: Warning: W:Tried to start delayed item http://us.archive.ubuntu.com/ubuntu questing-updates/main amd64 bpftool amd64 <snip> $ grep 'apt.systemd.daily' /var/log/syslog.1 | grep '^2026-04-16T01:09' | head -n 1 | wc -c 8116 IPv6 aaaa timeout was shown to be the problem, adding `Acquire::ForceIPv4 "true";` fixed the problem on several hosts. $ getent ahosts us.archive.ubuntu.com 91.189.91.81 STREAM us.archive.ubuntu.com 91.189.91.81 DGRAM 91.189.91.81 RAW 91.189.91.82 STREAM 91.189.91.82 DGRAM 91.189.91.82 RAW 91.189.91.83 STREAM 91.189.91.83 DGRAM 91.189.91.83 RAW 2620:2d:4002:1::101 STREAM 2620:2d:4002:1::101 DGRAM 2620:2d:4002:1::101 RAW 2620:2d:4002:1::102 STREAM 2620:2d:4002:1::102 DGRAM 2620:2d:4002:1::102 RAW 2620:2d:4002:1::103 STREAM 2620:2d:4002:1::103 DGRAM 2620:2d:4002:1::103 RAW There are no non `fe80::` (link local addresses) on the host. $ ip a | grep inet6 inet6 ::1/128 scope host noprefixroute inet6 fe80::786a:e338:3957:b331/64 scope link noprefixroute inet6 fe80::a10c:eae9:9a49:c94d/64 scope link noprefixroute So to be clear, I removed my temporary ipv4 only apt config, but there are a million places for this to be brittle and you see people doing so with sysctl net.ipv6.conf.* netplan, systemd-networkd, NetworkManager, etc... plus the individual client etc.... Note: https://datatracker.ietf.org/doc/html/rfc6724#section-2.1 https://datatracker.ietf.org/doc/html/rfc6724#section-2.1 And how "::/0" > "::ffff:0:0/96" And the preceding text: > If an implementation is not configurable or has not been configured, then it SHOULD operate according to the algorithms specified here in conjunction with the following default policy table: One could argue that GUA's without a non-link-local IPv6 address should just be ignored...and in a perfect world they would. But as covered int the first link in this post this is not as easy or clear as expected and people tend to error towards following rfc6724 which states just below the above refrence: > Another effect of the default policy table is to prefer communication using IPv6 addresses to communication using IPv4 addresses, if matching source addresses are available. I am not an IPv6 hater...just giving observations that when you introduce a breaking change, and add additional friction, it dramatically reduces adoption. Many companies I have been at basically just implement enough to meet Federal Government requirements and often intentionally strip it out of the backend to avoid the brittleness it caused. I am old enough to remember when I could just ask for an ASN and a portable class-c and how nice that was, in theory IPv6 should have allowed for that in some form...I am just frustrated with how it has devolved into an intractable 'wicked problem' when there was a path. The fact that people don't acknowledge the pain for users, often due to situations beyond their control is a symptom of that problem. Ubuntu should never have even requested an IPv6 aaaa in the above system, and yes it only does because of politics and RFC requirements.
- simoncion 6mo ago
  E_NOREPRO user@ubuntu-server:~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 25.10 Release: 25.10 Codename: questing user@ubuntu-server:~$ uname -a Linux ubuntu-server 6.17.0-7-generic #7-Ubuntu SMP PREEMPT_DYNAMIC Sat Oct 18 10:10:29 UTC 2025 x86_64 GNU/Linux user@ubuntu-server:~$ getent ahosts us.archive.ubuntu.com 91.189.91.82 STREAM us.archive.ubuntu.com 91.189.91.82 DGRAM 91.189.91.82 RAW 91.189.91.81 STREAM 91.189.91.81 DGRAM 91.189.91.81 RAW 91.189.91.83 STREAM 91.189.91.83 DGRAM 91.189.91.83 RAW 2620:2d:4002:1::102 STREAM 2620:2d:4002:1::102 DGRAM 2620:2d:4002:1::102 RAW 2620:2d:4002:1::101 STREAM 2620:2d:4002:1::101 DGRAM 2620:2d:4002:1::101 RAW 2620:2d:4002:1::103 STREAM 2620:2d:4002:1::103 DGRAM 2620:2d:4002:1::103 RAW user@ubuntu-server:~$ ip --oneline link | grep -v lo: | awk '{ print $2 }' enp0s3: user@ubuntu-server:~$ ip addr | grep inet6 inet6 ::1/128 scope host noprefixroute inet6 fe80::5054:98ff:fe00:64a9/64 scope link proto kernel_ll user@ubuntu-server:~$ fgrep -r -e us.archive /etc/apt/ /etc/apt/sources.list.d/ubuntu.sources:URIs: http://us.archive.ubuntu.com/ubuntu/ user@ubuntu-server:~$ sudo apt-get update Hit:1 http://us.archive.ubuntu.com/ubuntu questing InRelease Get:2 http://security.ubuntu.com/ubuntu questing-security InRelease [136 kB] <snip> Get:43 http://security.ubuntu.com/ubuntu questing-security/multiverse amd64 c-n-f Metadata [252 B] Fetched 2,602 kB in 3s (968 kB/s) Reading package lists... Done I didn't think to wrap that in 'time', but it only took a few seconds to run... more than two and less than thirty. The IPv6 packet capture running during all that reveals that it never tried to reach out over v6 (but that my multicast group querier is happily running): user@ubuntu-server:~$ sudo tcpdump -i enp0s3 -s 0 -n 'ip6 or icmp6' tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on enp0s3, link-type EN10MB (Ethernet), snapshot length 262144 bytes 22:16:44.327503 IP6 fe80::5054:98ff:fe00:64a9 > ff02::2: ICMP6, router solicitation, length 16 22:17:35.823917 IP6 fe80::<REDACTED> > ff02::1: HBH ICMP6, multicast listener query v2 [gaddr ::], length 28 22:17:41.706930 IP6 fe80::5054:98ff:fe00:64a9 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 I even manually ran unattended-upgrade, which looks to have succeeded. Other than unanswered router solicitations and multicast group query membership chatter, there continued to be no IPv6 communication at all, and none of the messages you reported appeared either in /var/log/syslog or on the terminal. user@ubuntu-server:~$ sudo /usr/bin/unattended-upgrade user@ubuntu-server:~$ sudo grep -e 'Tried to start delayed item' /var/log/syslog user@ubuntu-server:~$ What am I doing wrong?

by Dagger2 6mo ago

nyrikki 6mo ago

> AAAA records have lower priority than A records if you don't have a v6 address assigned on your system. (Link-locals don't count for this). There is an expired 6man draft that explains some of the issues here. https://www.ietf.org/archive/id/draft-buraglio-6man-rfc6724-update-03.html https://www.ietf.org/archive/id/draft-buraglio-6man-rfc6724-... To be clear, I go and clean out the temporary fixes for dual stack problems, but you want some more info so here it is. $ grep 'apt.systemd.daily' /var/log/syslog.1 | grep '^2026-04-16T01:09' | wc -l 86375 $ grep 'apt.systemd.daily' /var/log/syslog.1 | grep '^2026-04-16T01:09' | head -n 1 2026-04-16T01:09:15.276295-06:00 MrBig apt.systemd.daily[45660]: /usr/bin/unattended-upgrade:2736: Warning: W:Tried to start delayed item http://us.archive.ubuntu.com/ubuntu questing-updates/main amd64 bpftool amd64 <snip> $ grep 'apt.systemd.daily' /var/log/syslog.1 | grep '^2026-04-16T01:09' | head -n 1 | wc -c 8116 IPv6 aaaa timeout was shown to be the problem, adding `Acquire::ForceIPv4 "true";` fixed the problem on several hosts. $ getent ahosts us.archive.ubuntu.com 91.189.91.81 STREAM us.archive.ubuntu.com 91.189.91.81 DGRAM 91.189.91.81 RAW 91.189.91.82 STREAM 91.189.91.82 DGRAM 91.189.91.82 RAW 91.189.91.83 STREAM 91.189.91.83 DGRAM 91.189.91.83 RAW 2620:2d:4002:1::101 STREAM 2620:2d:4002:1::101 DGRAM 2620:2d:4002:1::101 RAW 2620:2d:4002:1::102 STREAM 2620:2d:4002:1::102 DGRAM 2620:2d:4002:1::102 RAW 2620:2d:4002:1::103 STREAM 2620:2d:4002:1::103 DGRAM 2620:2d:4002:1::103 RAW There are no non `fe80::` (link local addresses) on the host. $ ip a | grep inet6 inet6 ::1/128 scope host noprefixroute inet6 fe80::786a:e338:3957:b331/64 scope link noprefixroute inet6 fe80::a10c:eae9:9a49:c94d/64 scope link noprefixroute So to be clear, I removed my temporary ipv4 only apt config, but there are a million places for this to be brittle and you see people doing so with sysctl net.ipv6.conf.* netplan, systemd-networkd, NetworkManager, etc... plus the individual client etc.... Note: https://datatracker.ietf.org/doc/html/rfc6724#section-2.1 https://datatracker.ietf.org/doc/html/rfc6724#section-2.1 And how "::/0" > "::ffff:0:0/96" And the preceding text: > If an implementation is not configurable or has not been configured, then it SHOULD operate according to the algorithms specified here in conjunction with the following default policy table: One could argue that GUA's without a non-link-local IPv6 address should just be ignored...and in a perfect world they would. But as covered int the first link in this post this is not as easy or clear as expected and people tend to error towards following rfc6724 which states just below the above refrence: > Another effect of the default policy table is to prefer communication using IPv6 addresses to communication using IPv4 addresses, if matching source addresses are available. I am not an IPv6 hater...just giving observations that when you introduce a breaking change, and add additional friction, it dramatically reduces adoption. Many companies I have been at basically just implement enough to meet Federal Government requirements and often intentionally strip it out of the backend to avoid the brittleness it caused. I am old enough to remember when I could just ask for an ASN and a portable class-c and how nice that was, in theory IPv6 should have allowed for that in some form...I am just frustrated with how it has devolved into an intractable 'wicked problem' when there was a path. The fact that people don't acknowledge the pain for users, often due to situations beyond their control is a symptom of that problem. Ubuntu should never have even requested an IPv6 aaaa in the above system, and yes it only does because of politics and RFC requirements.

simoncion 6mo ago
E_NOREPRO user@ubuntu-server:~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 25.10 Release: 25.10 Codename: questing user@ubuntu-server:~$ uname -a Linux ubuntu-server 6.17.0-7-generic #7-Ubuntu SMP PREEMPT_DYNAMIC Sat Oct 18 10:10:29 UTC 2025 x86_64 GNU/Linux user@ubuntu-server:~$ getent ahosts us.archive.ubuntu.com 91.189.91.82 STREAM us.archive.ubuntu.com 91.189.91.82 DGRAM 91.189.91.82 RAW 91.189.91.81 STREAM 91.189.91.81 DGRAM 91.189.91.81 RAW 91.189.91.83 STREAM 91.189.91.83 DGRAM 91.189.91.83 RAW 2620:2d:4002:1::102 STREAM 2620:2d:4002:1::102 DGRAM 2620:2d:4002:1::102 RAW 2620:2d:4002:1::101 STREAM 2620:2d:4002:1::101 DGRAM 2620:2d:4002:1::101 RAW 2620:2d:4002:1::103 STREAM 2620:2d:4002:1::103 DGRAM 2620:2d:4002:1::103 RAW user@ubuntu-server:~$ ip --oneline link | grep -v lo: | awk '{ print $2 }' enp0s3: user@ubuntu-server:~$ ip addr | grep inet6 inet6 ::1/128 scope host noprefixroute inet6 fe80::5054:98ff:fe00:64a9/64 scope link proto kernel_ll user@ubuntu-server:~$ fgrep -r -e us.archive /etc/apt/ /etc/apt/sources.list.d/ubuntu.sources:URIs: http://us.archive.ubuntu.com/ubuntu/ user@ubuntu-server:~$ sudo apt-get update Hit:1 http://us.archive.ubuntu.com/ubuntu questing InRelease Get:2 http://security.ubuntu.com/ubuntu questing-security InRelease [136 kB] <snip> Get:43 http://security.ubuntu.com/ubuntu questing-security/multiverse amd64 c-n-f Metadata [252 B] Fetched 2,602 kB in 3s (968 kB/s) Reading package lists... Done I didn't think to wrap that in 'time', but it only took a few seconds to run... more than two and less than thirty. The IPv6 packet capture running during all that reveals that it never tried to reach out over v6 (but that my multicast group querier is happily running): user@ubuntu-server:~$ sudo tcpdump -i enp0s3 -s 0 -n 'ip6 or icmp6' tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on enp0s3, link-type EN10MB (Ethernet), snapshot length 262144 bytes 22:16:44.327503 IP6 fe80::5054:98ff:fe00:64a9 > ff02::2: ICMP6, router solicitation, length 16 22:17:35.823917 IP6 fe80::<REDACTED> > ff02::1: HBH ICMP6, multicast listener query v2 [gaddr ::], length 28 22:17:41.706930 IP6 fe80::5054:98ff:fe00:64a9 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 I even manually ran unattended-upgrade, which looks to have succeeded. Other than unanswered router solicitations and multicast group query membership chatter, there continued to be no IPv6 communication at all, and none of the messages you reported appeared either in /var/log/syslog or on the terminal. user@ubuntu-server:~$ sudo /usr/bin/unattended-upgrade user@ubuntu-server:~$ sudo grep -e 'Tried to start delayed item' /var/log/syslog user@ubuntu-server:~$ What am I doing wrong?