If you drop the A responses for api.snapcraft.io, you correctly then connect to the IPv6 address. So an IPv6 only customer of Mythic Beasts can workaround this with /etc/hosts
This is undesirable - we're now ignoring your DNS and have to maintain fake records locally.
The application should do
if (can_connect_v6) { connect_v6 } else { connect_v4 }
If you want to stick to preferring v4 because the 1990s were *awesome* and you want to stay there, then at least falling back to v6 if the v4 connection fails would be an improvement. That way your software would merely be slow, rather than broken.
If you drop the A responses for api.snapcraft.io, you correctly then connect to the IPv6 address. So an IPv6 only customer of Mythic Beasts can workaround this with /etc/hosts
2a00:1098: 0:80:1000: 3a:5bbd: 5c26 api.snapcraft.io 0:80:1000: 3a:c7e8: 3ad9 fastly. cdn.snapcraft. io 0:80:1000: 3a:a2d5: 2132 livepatch. canonical. com
2a00:1098:
2a00:1098:
This is undesirable - we're now ignoring your DNS and have to maintain fake records locally.
The application should do
if (can_connect_v6) { connect_v6 } else { connect_v4 }
If you want to stick to preferring v4 because the 1990s were *awesome* and you want to stay there, then at least falling back to v6 if the v4 connection fails would be an improvement. That way your software would merely be slow, rather than broken.