Fedora Account System
Red Hat Associate
Red Hat Customer
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
Fedora Linux 38 entered end-of-life (EOL) status on 2024-05-21. Fedora Linux 38 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.