alt Hacker News> 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-...
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
$ 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
$ 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
Note:
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.
Replies
The getent output shows that addresses are being sorted properly for a machine without v6. apt-get and other properly-written software will try the addresses in the order listed there, i.e. all v4 addresses first and only then the v6 addresses.
So... I don't think `Acquire::ForceIPv4 "true";` could fix the problem, because apt-get wouldn't have even tried the v6 addresses if any of the v4 ones were working. If you run `wget http://us.archive.ubuntu.com/ubuntu` while the problem is happening it should give you clearer log messages.
Another possibility is a DNS failure that causes your DNS queries to go missing sometimes. If this is the issue then it probably affects both your A and AAAA queries, but you wouldn't notice it on the AAAA queries if you don't have v6. You would only notice when the A queries go missing and the lookup only returns AAAAs; programs will try v6 "first" if this happens, since v6 is all there is to try.
> And how "::/0" > "::ffff:0:0/96"
It has higher precedence, but DNS results are sorted by "do the labels match?" first and by precedence second (rules 5 and 6 in section 6). The idea is to prefer connecting to addresses where the kernel would select the same type of address (as identified by the labels) for the source address. In your case, the algorithm is looking at something like this:
src addr → dest addr
<your v4 address> → 91.189.91.81 (label 4 → 4) (precedence 35)
<your v4 address> → 91.189.91.82 (label 4 → 4) (precedence 35)
<your v4 address> → 91.189.91.83 (label 4 → 4) (precedence 35)
fe80::786a:e338:3957:b331 → 2620:2d:4002:1::101 (label 13 → 1) (precedence 40)
fe80::786a:e338:3957:b331 → 2620:2d:4002:1::102 (label 13 → 1) (precedence 40)
fe80::786a:e338:3957:b331 → 2620:2d:4002:1::103 (label 13 → 1) (precedence 40)
Note the label sort is the only one that considers your source addresses. If that step wasn't there, the sort order would be the same on machines with and without v6, which would be bad.
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
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
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:~$
(Long post was long so I split it into two short... shortish... uh... here, enjoy two walls of text instead of one.)
> I am not an IPv6 hater...just giving observations that when you introduce a breaking change, and add additional friction, it dramatically reduces adoption.
It's not like we had a choice. We needed to increase the available address space but v4 doesn't support doing that, so there's your breaking change. (v6 did the work to introduce family-agnostic socket API calls, so applications can now use new address families without breaking, but those calls didn't exist before v6).
Also... v6 suffers from massive double standards. When people hit a problem in v4 they treat it as a problem to fix, but when they hit a problem in v6 -- or a problem with v4 that causes a colon to be printed --- they skip trying to find and fix the problem and just go "oh my god look how shit v6 is disable it now".
Computers break all the time. "It's always DNS" is a meme, so clearly things that aren't v6 break too. But if people are willing to forgive the other things for problems and fix them but refuse to do either with v6, and will blame v6 for problems it reveals in other things, then v6 could be far more reliable than v4 and people would still be moaning about it breaking all the time.
We're in this situation because the people who designed v4 made it too small. It sucks but we need to deal with it, and the sooner we do that the sooner we can stop being annoyed by it. Dragging our feet on v6 just maximizes the amount of time we need to deal with transitioning to it.
> Ubuntu should never have even requested an IPv6 aaaa in the above system, and yes it only does because of politics and RFC requirements.
getaddrinfo() has the AI_ADDRCONF flag for this. I don't know why it doesn't pass it here, but it could.