Fedora 40 Ignoring local DNS server

Ask Fedora
, , ,
1

Hello,

I’m having some issues in my Fedora 41 Workstation installation trying to resolve some local DNS records in my local DNS server.

I have two local DNS servers, both getting handed out by DHCP and apparently getting correctly picked up by resolved. However, anytime I try to resolve any internal record I get no reply. It seems like resolved is ignoring the local DNS server, since it returns no replies and these records are not in any public DNS server.

The behaviour seems very similar to this other thread, with the difference I have no external records: Fedora 40 - Split DNS Resolution(Internal/External) Issue - Favortizing External Resolution

Below are resolvectl status output, and a few dig commands highlighting the issue. I redacted the domain and tld.

❯ lsb_release -a                                      
LSB Version:	n/a
Distributor ID:	Fedora
Description:	Fedora Linux 41 (Sway)
Release:	41
Codename:	n/a

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

Link 2 (enp34s0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: fe80::861e:a3ff:feb1:f8e7
       DNS Servers: 192.168.1.12 192.168.1.13 fe80::861e:a3ff:feb1:f8e7
        DNS Domain: lan

Link 3 (docker0)
    Current Scopes: none
         Protocols: -DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported

~
❯ dig @192.168.1.12 arsenal.pve.<redacted>.<tld>

; <<>> DiG 9.18.33 <<>> @192.168.1.12 arsenal.pve.<redacted>.<tld>
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40469
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;arsenal.pve.<redacted>.<tld>.		IN	A

;; ANSWER SECTION:
arsenal.pve.<redacted>.<tld>.	10	IN	A	192.168.1.25

;; Query time: 2 msec
;; SERVER: 192.168.1.12#53(192.168.1.12) (UDP)
;; WHEN: Sun Apr 13 10:22:46 WEST 2025
;; MSG SIZE  rcvd: 55


~
❯ dig arsenal.pve.<redacted>.<tld>              

; <<>> DiG 9.18.33 <<>> arsenal.pve.<redacted>.<tld>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 9191
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;arsenal.pve.<redacted>.<tld>.		IN	A

;; AUTHORITY SECTION:
<redacted>.<tld>.		1321	IN	SOA	ajay.ns.cloudflare.com. dns.cloudflare.com. 2369959234 10000 2400 604800 1800

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Sun Apr 13 10:22:48 WEST 2025
;; MSG SIZE  rcvd: 112


~
❯ resolvectl query arsenal.pve.<redacted>.<tld> --cache=false
arsenal.pve.<redacted>.<tld>: Name 'arsenal.pve.<redacted>.<tld>' not found

Thanks in advance for any help!

2

Great info!

I notice that you have a IPv6 link local address in the resolver, but you did not test that it works and it’s the current DNS server.

I’ve just got into running a full IPv4/Ipv6 home network and some apps did not work correctly until I debugged by IPv6 configuration. Are you sure you have a working IPv6 network?

3

Thanks for the reply Barry.

I noticed that as well when reviewing the info when posting.
To be honest, I’m not sure. I know the ISP Router has IPv6 enabled and I’m pretty sure my local computers have both a link local IPv6 and an addressable IPv6. I haven’t really touched the IPv6 settings in the router, I’ll have to dig a little further and report back

1 Like
4

The way I setup my IPv6 was to use “prefix deligation” from the router to give each of my systems it’s own /64. Your ISP should have provisioned a /48 or /56 so you can do this.

5

Last night I did some light digging.

I was unable to query the link-local address directly, possibly just due to user error as I think I couldn’t quite nail the syntax dig and nslookup wanted.
But looking into my router settings, I noticed that it had DHCPv6 enabled by default.
The settings are pretty sparse, but I believe disabling DHCPv6 enables SLAAC, as my computers continue to receive a /64. resolvectl status now doesn’t show any link-local adresses, only the DNS servers I configured in my network and as such everything seems to be working, although I didn’t explicitly tried to test IPv6 connectivity

I’m not sure if this the the most correct configuration, but since it seems to be working for now I’ll leave it and get back to it later.

Thanks for the input!

6

The syntax for a ipv6 address is to put it in square brackets.
Like [fe80::861e:a3ff:feb1:f8e7].

1 Like
7

I am not sure link-local IPv6 addresses are fully supported by all tools. At least bind-utils dig and host tools did not support proper form of fe80::861e:a3ff:feb1:f8e7%eth0 in resolv.conf, at least few years back. But local /etc/resolv.conf should point to localhost systemd-resolved and that should be able to handle even interface specific addresses, even if it does not print it together with %interface at current DNS server. I think any address starting with fe80: should end with explicit interface specification. Because if the system has more than one interface, as it quite common on laptops or machines running libvirt or docker interfaces. resolvectl status prints the address for the link explicitly, but when used in dig, you would have to use dig @fe80::861e:a3ff:feb1:f8e7%enp34s0 arsenal.pve.example.net or host arsenal.pve.example.net fe80::861e:a3ff:feb1:f8e7%enp34s0. Link-local addresses have the same prefix for multiple interfaces and there is no heuristic to choose the correct interface, it always have to be specified when that address is used. That makes these address not suitable for local DNS responses, because DNS packets can contain just bare address, without interface specification.

Could you please show which exact name you are trying in dig and how the response looks in it? What exactly you mean by “returns no replies”? DNS should always return response, even if it is NXDOMAIN or empty answer NOERROR status.

Following command would try router.lan name on all resolvers on your system. Note that link-local has interface too and tries both UDP and TCP. Can you ensure all servers return the same responses?

H=router.lan;
SERVERS="192.168.1.12 192.168.1.13 fe80::861e:a3ff:feb1:f8e7%enp34s0";
for DNS in $SERVERS; do 
    echo "# $DNS"; dig +short @$DNS $H; dig +tcp +short @$DNS $H;
done
8

That syntax applies only when used in URI like https://[fe80::861e:a3ff:feb1:f8e7]. But again, for non-local link local address also interface id or name needs to be specified. Either as https://[fe80::861e:a3ff:feb1:f8e7%2] or https://[fe80::861e:a3ff:feb1:f8e7%enp34s0].

9

I’ve not figured out a hard and fast rule.
If the IPv6 does not work I use the and it tends to work, so far.

10

Systemd-resolved has special handling of interfaces bundled with link-local addresses. I think it should work and send queries correctly even to link-local addresses received, but it does not print it in a simple to reuse way. I think it should work anyway, just the diagnostic what exactly is wrong is more difficult.

Can you please share what router model and vendor is sending such link-local IPv6 address? Is this default behaviour of that device or it is required to configure it to offer DNS via link-local address only?

I assume address fe80::861e:a3ff:feb1:f8e7 is of local router. Are addresses 192.168.1.12 and 192.168.1.13 leading to the router device or something different? Is it possible only DHCP were reconfigured to serve different than default DNS servers (which know special names), but IPv6 servers were left to vendor defaults?

11

I expect you mean to reply to the OP and not me.