Bug 2228193

Summary: Disable LLMNR resolution on Workstation
Product: [Fedora] Fedora Reporter: Petr Menšík <pemensik>
Component: systemdAssignee: systemd-maint
Status: NEW --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 39CC: dtardon, extras-qa, fedoraproject, filbranden, lnykryn, msekleta, ryncsn, systemd-maint, yuwatana, zbyszek
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
URL: https://github.com/systemd/systemd/pull/28263
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 2228188 Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2228188    
Bug Blocks:    

Description Petr Menšík 2023-08-01 17:34:25 UTC
+++ This bug was initially created as a clone of Bug #2228188 +++

LLMNR is multicast resolution protocol. It is enabled in systemd-resolved since it has become default in f33 and provides Windows compatible resolution of names. It works over multicast on local networks and is potentially insecure. Any machine on the same network link can impersonate any hostname without dot present.

But even Microsoft, which is behind its RFC has announced its deprecation [MS-LLMNR].

What is not caused by the protocol itself, but the way systemd-resolved implements it, it directs single label names to LLMNR resolution *only*. So it also answers for queries not really intended for LLMNR resolution [stub-llmnr].

Reproducible: Always

Steps to Reproduce:
1. resolvectl llmnr
2. dig -t ns org.
Actual Results:  
# resolvectl llmnr
Global: resolve
Link 2 (eth0): resolve

# dig -t ns org.

; <<>> DiG 9.18.17 <<>> -t ns org.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 45940
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;org.				IN	NS

;; Query time: 3580 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Tue Aug 01 12:58:27 EDT 2023
;; MSG SIZE  rcvd: 32


Expected Results:  
# resolvectl llmnr
Global: no
Link 2 (eth0): no

# dig -t ns org.

; <<>> DiG 9.18.17 <<>> -t ns org.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18927
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;org.				IN	NS

;; ANSWER SECTION:
org.			3593	IN	NS	b2.org.afilias-nst.org.
org.			3593	IN	NS	b0.org.afilias-nst.org.
org.			3593	IN	NS	c0.org.afilias-nst.info.
org.			3593	IN	NS	d0.org.afilias-nst.org.
org.			3593	IN	NS	a0.org.afilias-nst.info.
org.			3593	IN	NS	a2.org.afilias-nst.info.

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Tue Aug 01 12:59:53 EDT 2023
;; MSG SIZE  rcvd: 170


Unlike Server variant, it may still make sense on networks with Windows 7, which do not have enabled mdns responder enabled and LLMNR is the only suitable protocol supported. But Windows 7 are already unsupported, so I doubt that should be reason for enabling the protocol in default installations on Fedora 39+.

[MS-LLMNR] https://techcommunity.microsoft.com/t5/networking-blog/aligning-on-mdns-ramping-down-netbios-name-resolution-and-llmnr/ba-p/3290816
[stub-llmnr] https://github.com/systemd/systemd/issues/23622

Comment 1 Petr Menšík 2023-08-01 17:40:17 UTC
Alternative change might be changing build default to ResolveUnicastSingleLabel=yes

That would still use LLMNR, but would try ALSO unicast DNS. Which it should do especially in cases when the query were received over port domain (53).

Comment 2 Zbigniew Jędrzejewski-Szmek 2023-08-09 14:12:54 UTC
I'm unsetting POST because there's no patch or clear decision yet.

Comment 3 Fedora Release Engineering 2023-08-16 08:13:50 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle.
Changing version to 39.