LLMNR resolution in systemd-resolved breaks resolution of single label names. It makes all queries to such names resolved over multicast resolution protocol only, when it often does not make sense. Reproducible: Always Steps to Reproduce: 1. nslookup -type=ns org 2. nslookup -type=ns arpa 3. nslookup -type=ds org Actual Results: $ nslookup -type=ns org Server: 127.0.0.53 Address: 127.0.0.53#53 ** server can't find org: NXDOMAIN $ nslookup -type=ns arpa Server: 127.0.0.53 Address: 127.0.0.53#53 ** server can't find arpa: NXDOMAIN $ nslookup -type=ds org Server: 127.0.0.53 Address: 127.0.0.53#53 ** server can't find org: SERVFAIL Expected Results: $ nslookup -type=ns org Server: 127.0.0.1 Address: 127.0.0.1#53 Non-authoritative answer: org nameserver = d0.org.afilias-nst.org. org nameserver = b0.org.afilias-nst.org. org nameserver = c0.org.afilias-nst.info. org nameserver = b2.org.afilias-nst.org. org nameserver = a2.org.afilias-nst.info. org nameserver = a0.org.afilias-nst.info. Authoritative answers can be found from: $ nslookup -type=ns arpa Server: 127.0.0.1 Address: 127.0.0.1#53 Non-authoritative answer: arpa nameserver = k.ns.arpa. arpa nameserver = l.ns.arpa. arpa nameserver = m.ns.arpa. arpa nameserver = a.ns.arpa. arpa nameserver = b.ns.arpa. arpa nameserver = c.ns.arpa. arpa nameserver = d.ns.arpa. arpa nameserver = e.ns.arpa. arpa nameserver = f.ns.arpa. arpa nameserver = g.ns.arpa. arpa nameserver = h.ns.arpa. arpa nameserver = i.ns.arpa. Authoritative answers can be found from: $ nslookup -type=ds org Server: 127.0.0.1 Address: 127.0.0.1#53 Non-authoritative answer: org rdata_43 = 26974 8 2 4FEDE294C53F438A158C41D39489CD78A86BEB0D8A0AEAFF14745C0D 16E1DE32 Authoritative answers can be found from: Even Microsoft decided to phase out LLMNR protocol and replace it with mdns. But in windows it does not break DNS resolution the way it does with systemd-resolved. Upstream issues: - https://github.com/systemd/systemd/issues/23622 - https://github.com/systemd/systemd/issues/23494 Related: - https://github.com/systemd/systemd/pull/28263 - https://techcommunity.microsoft.com/t5/networking-blog/aligning-on-mdns-ramping-down-netbios-name-resolution-and-llmnr/ba-p/3290816
RFC 8020 [1] clearly state that if NXDOMAIN is returned, anything beneath it does not exist as well. Which is of course not true, Fedora has its own domain there. $ nslookup -type=ns fedoraproject.org Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: fedoraproject.org nameserver = ns02.fedoraproject.org. fedoraproject.org nameserver = ns05.fedoraproject.org. fedoraproject.org nameserver = ns-iad01.fedoraproject.org. fedoraproject.org nameserver = ns-iad02.fedoraproject.org. Authoritative answers can be found from: $ nslookup -type=ns org Server: 127.0.0.53 Address: 127.0.0.53#53 ** server can't find org: NXDOMAIN I have tested that on windows and it seems systemd-resolved copied its behaviour. It works roughly the same way on my Windows 11 machine. Which is issue to be solved on Windows. But it should look like: $ nslookup -type=ns fedoraproject.org Server: 127.0.0.1 Address: 127.0.0.1#53 Non-authoritative answer: fedoraproject.org nameserver = ns-iad01.fedoraproject.org. fedoraproject.org nameserver = ns-iad02.fedoraproject.org. fedoraproject.org nameserver = ns02.fedoraproject.org. fedoraproject.org nameserver = ns05.fedoraproject.org. Authoritative answers can be found from: $ nslookup -type=ns org Server: 127.0.0.1 Address: 127.0.0.1#53 Non-authoritative answer: org nameserver = d0.org.afilias-nst.org. org nameserver = b0.org.afilias-nst.org. org nameserver = c0.org.afilias-nst.info. org nameserver = b2.org.afilias-nst.org. org nameserver = a2.org.afilias-nst.info. org nameserver = a0.org.afilias-nst.info. Authoritative answers can be found from: 1. https://www.rfc-editor.org/rfc/rfc8020.html