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.
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
By default, if you enter a top-level domain (TLD), subdomains will be included automatically. If needed, configure separate Custom DNS Rules for subdomains to point at different IPs.
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.
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 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.
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: files
Hmm. I wouldn’t expect a dns server to ever respond with a cname, given the records you’ve set. But when your resolver is actually the systemd stub resolver inserting itself between the system and the actual server, then shit gets weird.
I would disable resolved and use a traditional and reliable method that doesn’t muck with resolution. https://fedoraproject.org/wiki/Changes/systemd-resolved#Opting_out_of_/etc/resolv.conf_that_points_to_the_localhost_stub_resolver
