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?

  • baronvonj@piefed.socialOP
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 day ago

    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
    
    • just_another_person@lemmy.world
      link
      fedilink
      English
      arrow-up
      4
      arrow-down
      1
      ·
      1 day ago

      Yes, 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.

      • baronvonj@piefed.socialOP
        link
        fedilink
        English
        arrow-up
        1
        ·
        23 hours ago

        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.

        • just_another_person@lemmy.world
          link
          fedilink
          English
          arrow-up
          2
          arrow-down
          1
          ·
          edit-2
          22 hours ago

          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.

          • baronvonj@piefed.socialOP
            link
            fedilink
            English
            arrow-up
            1
            ·
            22 hours ago

            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.

            • just_another_person@lemmy.world
              link
              fedilink
              English
              arrow-up
              2
              arrow-down
              1
              ·
              edit-2
              20 hours ago

              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.conf and /etc/resolv.conf?

              • baronvonj@piefed.socialOP
                link
                fedilink
                English
                arrow-up
                1
                ·
                18 hours ago
                $ 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
                
                • dcatdemon@infosec.pub
                  link
                  fedilink
                  English
                  arrow-up
                  1
                  ·
                  edit-2
                  6 hours ago

                  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

                  • disable the systemd-resolved stub listener. This is done by setting DNSStubListener=no
                  • change /etc/resolve.conf to point to run/systemd/resolve/resolv.conf instead of the stub.

                  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