Devices on my LAN cannot always be resolved (DNS) when I active IPv6

I wanted to get some experience with IPv6 so I actived IPv6 im my router.
IP version to the internet: IPv4
OS of my laptop: Fedora 41 workstation
IPv6 is active on my laptop’s WiFi interface.

Here is what resolvectl has:

$ resolvectl
Global
         Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (wlp0s20f3)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.178.1
       DNS Servers: 192.168.178.1 fe80::ce40:d0ff:fe49:8430
        DNS Domain: fritz.box

Everything works fine until fe80::ce40:d0ff:fe49:8430 becomes my current DNS Server which happens now and then. When this happens, the DNS resolution does not work for the devices within my LAN.

When I do a manual lookup I can replicate the problem:

$ nslookup omv.fritz.box 192.168.178.1
Server:		192.168.178.1
Address:	192.168.178.1#53

Name:	omv.fritz.box
Address: 192.168.178.63
Name:	omv.fritz.box
Address: 2003:e6:1727:e500:be24:11ff:fe7c:85f1

$ nslookup omv.fritz.box fe80::ce40:d0ff:fe49:8430
;; UDP setup with fe80::ce40:d0ff:fe49:8430#53(fe80::ce40:d0ff:fe49:8430) for omv.fritz.box failed: invalid file.
;; no servers could be reached
;; UDP setup with fe80::ce40:d0ff:fe49:8430#53(fe80::ce40:d0ff:fe49:8430) for omv.fritz.box failed: invalid file.
;; no servers could be reached
;; UDP setup with fe80::ce40:d0ff:fe49:8430#53(fe80::ce40:d0ff:fe49:8430) for omv.fritz.box failed: invalid file.
;; no servers could be reached

The lookup works when I specify the WiFi interface (here: wlp0s20f3) in the local link adress when doing the lookup:

$ nslookup omv.fritz.box fe80::ce40:d0ff:fe49:8430%wlp0s20f3
Server: fe80::ce40:d0ff:fe49:8430%wlp0s20f3
Address: fe80::ce40:d0ff:fe49:8430%2#53

Name: omv.fritz.box
Address: 2003:e6:1727:e500:be24:11ff:fe7c:85f1

So what is wrong with the default configuration?

I found a suggestion (I asked an AI) which is to modify the DNS servers in the IPv6 configuration. I did this, and it works, however I thought the network configuration should work out of the box, especially as I have to do it for all my access points.

Without an ipv6 /48 address into the internet you are very limited what you can test I expect. Basically all you have is the link local ipv6 addresses.

Having turned on ipv6 in your router it maybe that the router told your system it can route ipv6 into the internet. If so lots of networking will break.

Thanks for your answer. Now I noticed that I also got an IPv6 /56 adress from my ISP. However, the problem persists.

You will need to have your router configured to accept RA from the ISP and send RA with prefix deligation to your home network.
RA == router advertisement.

I’m glad for any help, thanks for your ideas.

The router advertisement is active. I wonder why fedora linux would decide to use a f800 Adress as the DNS server? It’s a link local address. When I use it to ping the server I get a warning to use the interface number to clarify for which interface it applies. So I would deduce this is not a good address to use for the DNS server.

The fe80 address is probably coming from your FritzBox. In principle, this is OK, and it is independent of the global address of the device.
But you should not pass it to behind another network interface because it’s strictly link-local and cannot be routed. If your LAN is on NetworkManager “shared”, I already filed a bug report for it but apparently not fixed. So either convince your Fritzbox to advertise a global IPv6, or set your Wifi to “Address Only” and enter your own value for IPv6 DNS, or build your own “Shared” with dnsmasq, advertising the LAN link-local or global address for DNS.
A fe80 address is not guaranteed unique, so the device has to be specified.

IMHO, do not use the /56 as address mask, the standard IPv6 subnet is /64. This for autoconfiguration to work. The /56 is a prefix, which is delegated to your system to handle up to 256 routeable /64 subnets with global scope. In that way, your Wifi comes on e.g. aaaa:bbbb:cccc:dd01::/64, your LAN on aaaa:bbbb:cccc:dd02::/64. Those networks do not overlap, so routing works, but both have access to internet due to prefix delegation. No NAT. Of course, firewalld should allow forwarding.

Not true on a router. The ipv6 SLAAC will set the /48 or /56 for the router.

At least with my ISP I had to turn on the /48 routing. The default was a /64vthat I turned off.

If you create /48 or /56 addresses, then you loose routing possibilities.

If you want to do prefix delegation from /48, you have a /48 route on WAN and you get a /56 route for each downstream router. At the end, you can theoretically have 65536 autoconfigured /64 subnets starting from a /48 prefix.

All SLAAC addresses are /64 as far I know.

You make it sound like the DNS client is not using the zone index.

I tried reproducing the issue on a Fedora 41 machine by explicitly specifying the IPv6 LLA of the upstream gateway as an exclusive resolver, and it still works:

> getent hosts _gateway
fe80::5054:ff:fe41:cb69 _gateway

> sudo resolvectl dns eth0 fe80::5054:ff:fe41:cb69

> resolvectl status --no-pager
Global
         Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (eth0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
       DNS Servers: fe80::5054:ff:fe41:cb69

Link 3 (eth1)
    Current Scopes: LLMNR/IPv4 LLMNR/IPv6
         Protocols: -DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported

> resolvectl flush-caches

> resolvectl query example.edu --legend=no
example.edu: 96.7.129.25                       -- link: eth0
             2600:1406:bc00:17::6007:8119      -- link: eth0

I run this config on my router and routing works.
No idea why you think this is not going to work.

SLAAC takes the ISP allocation and send the config to the router.
In my case the /48 is sent and I use that to do prefix deligation.

Or are you talking about the client host and not the router?

I’m afraid it goes a bit off-topic and may be some confusion. I thought that SLAAC the process is where a system receives a router advertisement and automagically puts IPv6 /64 addresses on the interface, but I could be wrong in case of a router.

Unfortunately, I’ve only an ISP’s router. I know the router sends a DHCPv6 PD request to the ISP and receives a /48 prefix, from which it composes the router advertisement on the LAN for a /64 subnet. On the router itself is a /64 address on WAN and a /64 address on LAN for DNS, different subnets. Earlier firmware used the fe80:: L.L. LAN address for DNS, so I know O.P.s problem with DNS. Default route goes via the fe80:: address of the router, as there is no router specified in the router advertisement.
In your case, the ISP IPv6 handling might be different.

Here is what I see for the PPPoE

systemd-networkd[1066]: ppp0: DHCPv6 address 2001:xxx:1111:1111:0:ffff:51bb:dcaa/128 (valid for 1h 59min 59s, preferred for 59min 59s)
systemd-networkd[1066]: ppp0: DHCP: received delegated prefix 2001:xxx:yyy::/48

As you can see SLAAC (DHCPv6) received a /48.

And a client on the inside gets:

    inet6 2001:xxx:yyy:0:9496:bcff:feec:352f/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 3522sec preferred_lft 1722sec

I think we mostly agree apart from exact SLAAC/DHCPv6 definition. Your router does DHCPv6 NA request to get a /128 address, and a PD request to get a delegated prefix. The /128 address is on it’s own and has no influence on routing.
The delegated prefix is a /48, so the 4th block of the IPv6 address can be in the range 0000 to ffff, where 0 is already used for the LAN /64. So the LAN uses one out of 65535 possible subnets.

The SLAAC as I understand, stateless autonomous address configuration, so without intervention of a DHCPv6 server, is in it’s RFC not bound to a prefix length, but for ethernet type interfaces it is stated that you need a /64 prefix. The format is then 48 bit from the ISP, 16 bit for subnetting, and 64 bit to identify the host.