I recently switched from Windows to Fedora 43. It has systemd-resolved. I’m having an issue with local DNS just on this one computer (everyone else’s Windows and Chromebook computers, all mobile devices, TVs, etc seem to be unaffected). My home router is a Firewalla, and I make use of their custom dns rules capability. I setup a home.example.com domain pointing to one IP address, and this acts as a catchall for *.home.example.com to go to my primary home server. But I have a few other specific subdomains <host>.home.example.com that I add with their correct IP. What I’m seeing with dig <host>.home.example.com is both the A record for the host pointing to the correct IP, and also a CNAME aliasing to home.example.com. So ultimately applications on my Fedora machine keep going back to the .50 IP instead of the .55 IP as resolved seems to prefer that record which doesn’t actually exist in my router config.
$ dig myapp.home.example.com
; <<>> DiG 9.18.44 <<>> myapp.home.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42761
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;myapp.home.example.com. IN A
;; ANSWER SECTION:
myapp.home.example.com. 1589 IN CNAME home.example.com.
home.example.com. 0 IN A 192.168.68.50
;; AUTHORITY SECTION:
example.com. 1589 IN SOA ns1.example.net. hostmaster.example.net. 1771471443 10800 3600 604800 10800
;; Query time: 9 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Thu Feb 19 13:19:04 CST 2026
;; MSG SIZE rcvd: 136
But I don’t get that extra CNAME when I query direct to my router
$ dig @192.168.68.1 myapp.home.example.com
; <<>> DiG 9.18.44 <<>> @192.168.68.1 myapp.home.example.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48829
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;myapp.home.example.com. IN A
;; ANSWER SECTION:
myapp.home.example.com. 0 IN A 192.168.68.55
;; Query time: 10 msec
;; SERVER: 192.168.68.1#53(192.168.68.1) (UDP)
;; WHEN: Thu Feb 19 13:23:17 CST 2026
;; MSG SIZE rcvd: 65
So what gives here. Anyone know how to fix systemd-resolved?
From the docs you linked it specifically says it only works for A or AAAA records. Don’t know how your other machines are somehow working as you thought they would.
I assume it’s because of this, from the documentation
If I run lookups on subdomains which I have not explicitly defined a rule for, they work in systemd-resolved. It’s just the ones that I have explicitly defined a rule where systemd-resolved just keeps going to that CNAME result. I can
resolvectl flush-cachesand get the correct result briefly, but within like 15 minutes it goes back to the CNAME instead of the A record.$ dig @192.168.68.1 bob.home.example.com foo.home.example.com ; <<>> DiG 9.18.44 <<>> @192.168.68.1 bob.home.example.com foo.home.example.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44860 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;bob.home.example.com. IN A ;; ANSWER SECTION: bob.home.example.com. 0 IN A 192.168.68.50 ;; Query time: 5 msec ;; SERVER: 192.168.68.1#53(192.168.68.1) (UDP) ;; WHEN: Thu Feb 19 15:12:17 CST 2026 ;; MSG SIZE rcvd: 63 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15296 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;foo.home.example.com. IN A ;; ANSWER SECTION: foo.home.example.com. 0 IN A 192.168.68.50 ;; Query time: 5 msec ;; SERVER: 192.168.68.1#53(192.168.68.1) (UDP) ;; WHEN: Thu Feb 19 15:12:17 CST 2026 ;; MSG SIZE rcvd: 63Yes, because it would actually as an accidental Round-Robin return in the case that there is a conflict with a wildcard A record, and a CNAME which isn’t supposed to be working.
This is a combo of your DNS setup being misconfigured, and DNS caching working differently on Windows vs Linux.
Resolution is just fixing your DNS to work properly.
What do you suggest I do for that? What records? I do have more manual control of it via the shell than what the UI offers, and it’s running dnsmasq under the covers. Note, I do also have a support ticket open with Firewalla, they’re pointing the finger at resolved.
Switch those CNAME records to A records, clear your cache, then see how it works.
I can promise you this is not a resolved issue. If it was, you’d be seeing posts like this everywhere. It’s behaving as it should.
Your setup on the Firewalls is not what I would call a “standard” setup. There is both a proper DNS forwarded, AND what they are calling “DNS Filtering” at play with that service. I can’t see your record setup, but depending on which gives the defacto answers when you make a request, you may get conflicting responses, so I would just do away with any kind of non-A records in your setup and see what happens since their docs specifically say it’s only meant for those records and not CNAME or Alias.
CNAME gives you no benefit to what you’re doing here anyway since you only have the couple machines and not MANY records pointing to various places or using named hosts requests or something.
I do actually have far more services deployed on the .50 IP than I do other servers with an explicit DNS rule defined. I have a TLS cert deployed with a wildcard SAN for *.home.example.com on that one server, and use reverse proxy to send the traffic to the right service based on hostname. The other couple of rules are just when I need to override that for a service on a different server (like running something on my Pi).
It would make sense that there’s a CNAME buried in there on the router, but the
digresults going direct to the router don’t include that record. I’ll poke around to see if I can find where there’s a CNAME, though, and keep harping on it to Firewalla support.I get what you’re saying, and it’s all logical and rational. But when consistently every one of several dozen other clients/devices on the network that aren’t using resolved are working, and only resolved is not, it’s kind of pointless to say everyone else is doing it wrong. Being technically correct doesn’t matter much at that point.
Out of curiosity, does this machine in question have a hostname that falls under the domain you’re using for DNS resolution?
Also, what are the contents of
/etc/nsswitch.confand/etc/resolv.conf?$ hostname -f firefly $ cat /etc/resolv.conf | grep -v -e '^#' nameserver 127.0.0.53 options edns0 trust-ad search lan $ cat /etc/nsswitch.conf | grep -v -e '^#' passwd: files systemd shadow: files systemd group: files [SUCCESS=merge] systemd hosts: files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns services: files netgroup: files automount: files aliases: files ethers: files gshadow: files systemd networks: files dns protocols: files publickey: files rpc: filesInstead of writing a novel here, tried to find a post to explain what I think is happening.
Try this
I had the same problem as you as I was starting with this as well on debian trixie. What finally worked was this.
I think you should
This should remove the 127.0.0.53 naneserver and put the real one in it.
From the man pages
systemd-resolved maintains the /run/systemd/resolve/resolv.conf file for compatibility with traditional Linux programs. This file may be symlinked from /etc/resolv.conf and is always kept up-to-date, containing information about all known DNS servers. Note the file format’s limitations: it does not know a concept of per-interface DNS servers and hence only contains system-wide DNS server definitions. Note that /run/systemd/resolve/resolv.conf should not be used directly by applications, but only through a symlink from /etc/resolv.conf.
My 2 cents