ipv6 addresses cannot be resolved on fedora server 40, both ping ::1 and ping -6 ipv6.google.com fails:
> ping -6 ::1
ping: connect: Network is unreachable
> ping ::1
PING ::1 (::1) 56 data bytes
^C
--- ::1 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3064ms
> ping -6 ipv6.google.com
ping: ipv6.google.com: No address associated with hostname
Here are some info:
> resolvectl --no-pager status
Global
Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 2606:4700:4700::1111
DNS Servers: 2606:4700:4700::1111
Link 2 (eno1)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 1.1.1.1
DNS Servers: 1.1.1.1 2606:4700:4700::1111
Link 3 (tailscale0)
Current Scopes: DNS
Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 100.100.100.100
DNS Servers: 100.100.100.100
DNS Domain: ainu-morpho.ts.net ~.
> cat /etc/resolv.conf
# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 127.0.0.53
options edns0 trust-ad
search ainu-morpho.ts.net
> resolvectl dns
Global:
Link 2 (eno1): 1.1.1.1 2606:4700:4700::1111
Link 3 (tailscale0): 100.100.100.100
Link 4 (br-61565b199df7):
> ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether e8:9c:25:78:b4:46 brd ff:ff:ff:ff:ff:ff
altname enp8s0
inet 192.168.1.144/24 brd 192.168.1.255 scope global dynamic noprefixroute eno1
valid_lft 85926sec preferred_lft 85926sec
inet6 2404:c804:1ac1:d300:35da:9bb2:dff7:54b2/64 scope global dynamic noprefixroute
valid_lft 594sec preferred_lft 594sec
inet6 fe80::5730:e3fe:e97:5c36/64 scope link noprefixroute
valid_lft forever preferred_lft forever
... Some docker bridges ...
124: tailscale0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc fq state UNKNOWN group default qlen 500
link/none
inet 100.107.84.68/32 scope global tailscale0
valid_lft forever preferred_lft forever
IPv6 works fine for me by default, so something must be messing your configuration and specifically the loopback interface.
It could be a kill switch integrated with Tailscale or some other VPN application, which is designed to prevent IPv6 traffic leaks.
Check the relevant sysctl and interface settings, inspect system logs, try to isolate the problem by temporarily disabling third-party services or removing the related packages.
Hi, I solved this by masking the systemd-resolved, and I am now able to ping6 ipv6.google.com, but the weird part is localhost cannot be ping from localhost, i.e. ping6 ::1 fails:
> ping6 localhost
PING localhost (::1) 56 data bytes
Wait for a few seconds, then interupt by ^C
--- localhost ping statistics ---
57 packets transmitted, 0 received, 100% packet loss, time 57326ms
Actually the lo device should have an IPv6 address.
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
# ping ::1
PING ::1 (::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.032 ms
64 bytes from ::1: icmp_seq=2 ttl=64 time=0.037 ms
64 bytes from ::1: icmp_seq=3 ttl=64 time=0.028 ms
Though what the OP shows does not reveal that.
This appears to definitely be a misconfiguration somewhere in his network. Tailscale only has an IPv4 address as does lo, but eno1 has both IPv4 & IPv6 addresses.
I also note that his ethernet port (eno1) did not get renamed by bus ID as most systems do.
Mine is enp4s0. I have to wonder if this may be interrelated?
Could it be related to the change in f40 with randomizing the mac address for connections?
I don’t have that problem. What is the adapter installed? It may be related to the driver used. lspci -nnk | grep -iA3 -E "network|ethernet" should show that for us.
> resolvectl --no-pager query example.org
example.org: 93.184.215.14 -- link: eno1
-- Information acquired via protocol DNS in 2.9ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network
> resolvectl --no-pager query example.org --type a
example.org IN A 93.184.215.14 -- link: eno1
-- Information acquired via protocol DNS in 612us.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: cache
> resolvectl --no-pager query example.org --type aaaa
example.org IN AAAA 2606:2800:21f:cb07:6820:80da:af6b:8b2c -- link: eno1
-- Information acquired via protocol DNS in 2.9ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network
> journalctl --no-pager -b -u systemd-resolved.service
May 19 08:01:11 fedodesk systemd[1]: Starting systemd-resolved.service - Network Name Resolution...
May 19 08:01:11 fedodesk systemd-resolved[1361448]: Positive Trust Anchors:
May 19 08:01:11 fedodesk systemd-resolved[1361448]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
May 19 08:01:11 fedodesk systemd-resolved[1361448]: Negative trust anchors: home.arpa 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa 22.172.in-addr.arpa 23.172.in-addr.arpa 24.172.in-addr.arpa 25.172.in-addr.arpa 26.172.in-addr.arpa 27.172.in-addr.arpa 28.172.in-addr.arpa 29.172.in-addr.arpa 30.172.in-addr.arpa 31.172.in-addr.arpa 170.0.0.192.in-addr.arpa 171.0.0.192.in-addr.arpa 168.192.in-addr.arpa d.f.ip6.arpa ipv4only.arpa resolver.arpa corp home internal intranet lan local private test
May 19 08:01:11 fedodesk systemd-resolved[1361448]: Using system hostname 'fedodesk'.
May 19 08:01:11 fedodesk systemd[1]: Started systemd-resolved.service - Network Name Resolution.
May 19 08:01:11 fedodesk systemd-resolved[1361448]: eno1: Bus client set default route setting: yes
May 19 08:01:11 fedodesk systemd-resolved[1361448]: eno1: Bus client set DNS server list to: 1.1.1.1, 2606:4700:4700::1111
May 19 08:01:13 fedodesk systemd-resolved[1361448]: Flushed all caches.
May 19 08:01:25 fedodesk systemd-resolved[1361448]: Flushed all caches.
> resolvectl flush-caches
> resolvectl --no-pager query example.org
example.org: 93.184.215.14 -- link: eno1
-- Information acquired via protocol DNS in 8.1ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: yes
-- Data from: network
> resolvectl flush-caches
> resolvectl --no-pager query example.org --type aaaa
example.org IN AAAA 2606:2800:21f:cb07:6820:80da:af6b:8b2c -- link: eno1
-- Information acquired via protocol DNS in 8.0ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: yes
-- Data from: network
> ping6 ipv6.google.com
ping6: ipv6.google.com: No address associated with hostname
> ping6 example.com
ping6: example.com: Address family for hostname not supported
