Ipv6 address not resolved

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

The ping fails because your loopback interface has no IPv6 address, see:

sudo nmcli connection up lo
nmcli connection show lo | grep -i -e "ipv*6"
ip -6 addr show dev lo

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?

Thanks for your solution! In that way I can ping ::1 and the internet with ipv6 with no problem :slight_smile:

1 Like

Hi, I have also noticed that my network interface was renamed to eno1 after I upgrade to fedora server 40, it was enp... on fedora 39

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.

> lspci -nnk | grep -iA3 -E "network|ethernet"
08:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller I225-V [8086:15f3] (rev 03)
        DeviceName: Intel I225-V LAN
        Subsystem: ASUSTeK Computer Inc. Device [1043:87d2]
        Kernel driver in use: igc

Hi… The server cannot resolve any ipv6 addres as soon as I enable systemd-resolved, and tailscale needs that to work… What can I do about that?
Thanks

This looks like an issue related to Tailscale:
DNS Stuck on 100.100.100.100 · Issue #3817 · tailscale/tailscale · GitHub

Thanks, but what if I just want to enable systemd-resolved?

Thanks again

You should isolate the issue to determine its root cause.
When the issue started to happen and what changed?
Does it work if you disable Tailscale and reboot?

No, same problem happened with tailscale disabled

Check the output when the issue happens:

resolvectl flush-caches
resolvectl --no-pager query example.org
resolvectl --no-pager query example.org --type a
resolvectl --no-pager query example.org --type aaaa
grep -vrEe "^(#|$)" /{etc,run,usr/lib}/systemd/resolve*
journalctl --no-pager -b -u systemd-resolved.service
> resolvectl flush-caches
>  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
> grep -vrEe "^(#|$)" /{etc,run,usr/lib}/systemd/resolve*
/etc/systemd/resolved.conf:[Resolve]
/etc/systemd/resolved.conf:DNS=1.1.1.1
/run/systemd/resolve/stub-resolv.conf:nameserver 127.0.0.53
/run/systemd/resolve/stub-resolv.conf:options edns0 trust-ad
/run/systemd/resolve/stub-resolv.conf:search .
/run/systemd/resolve/netif/2:LLMNR=yes
/run/systemd/resolve/netif/2:MDNS=yes
/run/systemd/resolve/netif/2:DEFAULT_ROUTE=yes
/run/systemd/resolve/netif/2:SERVERS=1.1.1.1 2606:4700:4700::1111
/run/systemd/resolve/resolv.conf:nameserver 1.1.1.1
/run/systemd/resolve/resolv.conf:nameserver 1.1.1.1
/run/systemd/resolve/resolv.conf:nameserver 2606:4700:4700::1111
/run/systemd/resolve/resolv.conf:search .
/usr/lib/systemd/resolved.conf:[Resolve]
> 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.
1 Like

Try removing the redundant declaration of the IPv4 resolver:

sudo sed -i -e '/^DNS=/s/^/#/' /etc/systemd/resolved.conf
sudo systemctl restart systemd-resolved.service

If the issue persists, try using DoT:

sudo sed -i -e '$a DNSOverTLS=yes' /etc/systemd/resolved.conf
sudo systemctl restart systemd-resolved.service

Problem still presists:

> ping google.com
PING google.com (142.250.66.78) 56(84) bytes of data.
64 bytes from hkg12s27-in-f14.1e100.net (142.250.66.78): icmp_seq=1 ttl=118 time=3.50 ms
64 bytes from hkg12s27-in-f14.1e100.net (142.250.66.78): icmp_seq=2 ttl=118 time=3.22 ms
^C
--- google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 3.217/3.358/3.499/0.141 ms

> ping6 google.com
ping6: google.com: Address family for hostname not supported

Let’s make sure to flush the cache and verify the output:

resolvectl flush-caches
resolvectl --no-pager query example.org
> 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