AAAA records have lower priority than A records if you don't have a v6 address assigned on your...

Dagger2 • yesterday at 7:44 PM • 1 reply • view on HN

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.

Replies

nyrikki • yesterday at 9:40 PM

> 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

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

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.

➕ show 3 replies

alt Hacker News

Replies