systemd version the issue has been seen with

systemd-251-1.fc37.x86_64

Used distribution

Fedora Rawhide (37)

Linux kernel version used (uname -a)

Linux *.redhat.com 5.18.0-0.rc7.54.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Mon May 16 14:40:06 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

CPU architecture issue was seen on

x86_64

Expected behaviour you didn't see

All dnssec enabled queries reach destination

Unexpected behaviour you saw

dig org. dnskey ended with NXDOMAIN, which is a nonsense

Steps to reproduce the problem

dnf install ldns-utils && drill -S org. dnskey

Additional program output to the terminal or log subsystem illustrating the issue

• LLMNR=yes
• DNSSEC=yes

# drill -S src.fedoraproject.org @127.0.0.53
;; Number of trusted keys: 1
;; Chasing: src.fedoraproject.org. A


DNSSEC Trust tree:
src.fedoraproject.org. (A)
|---fedoraproject.org. (DNSKEY keytag: 60624 alg: 14 flags: 256)
    |---fedoraproject.org. (DNSKEY keytag: 58125 alg: 14 flags: 257)
    |---fedoraproject.org. (DS keytag: 58125 digest type: 2)
No trusted keys found in tree: first error was: No DNSSEC public key(s)
;; Chase failed.

• LLMNR=no
• DNSSEC=yes

# drill -S src.fedoraproject.org @127.0.0.53
;; Number of trusted keys: 1
;; Chasing: src.fedoraproject.org. A


DNSSEC Trust tree:
src.fedoraproject.org. (A)
|---fedoraproject.org. (DNSKEY keytag: 60624 alg: 14 flags: 256)
    |---fedoraproject.org. (DNSKEY keytag: 58125 alg: 14 flags: 257)
    |---fedoraproject.org. (DS keytag: 58125 digest type: 2)
        |---org. (DNSKEY keytag: 15843 alg: 8 flags: 256)
            |---org. (DNSKEY keytag: 26974 alg: 8 flags: 257)
            |---org. (DS keytag: 26974 digest type: 2)
                |---. (DNSKEY keytag: 47671 alg: 8 flags: 256)
                    |---. (DNSKEY keytag: 20326 alg: 8 flags: 257)
;; Chase successful

I have found interesting document describing implementation on Windows. It clearly states no other resource records should be handled but A, AAAA and PTR.

I think because Fedora enables by default resolve NSS plugin, it should not serve the same records on DNS stub. It does not make sense for anything but host address queries anyway. I think it should be switched for DNS originated queries just as fallback in this case.

If it does not find it on DNS, check also LLMNR. Primary users would be via resolve plugin doing the translation directly. Programs using DNS want DNS reply in the first place. Queries done by unicast would be faster. But never respond to DNS query with negative LLMNR response without checking DNS as well.