I mean you’re not wrong.

It seems to have stabilized itself over the last 24 hours. I haven’t touched the configuration on either side. Weirdy McWeirdsalot.

It seems to have stabilized itself over the last 24 hours. I haven’t touched the configuration on either side. Weirdy McWeirdsalot.

Well, I haven’t actually touched the configuration on either the Firewalla or resolved yet, and it seems to have magically stabilized itself. Been resolving correctly for all day. Really appreciate you trying to help me out, regardless.

$ 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

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 dig results 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.

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.

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-caches and 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: 63