[systemd-devel] LLMNR priority over DNS
Petr Menšík
pemensik at redhat.com
Tue May 24 18:19:57 UTC 2022
Hi,
I have just filled issue #23494 [1]. I think LLMNR should not be offered
at all on DNS stub, if resolve NSS plugin is used.
Let's take Windows implementation as an example. I have found Microsoft
change of protocol describing used Windows variant, MS-LLMNR [2]. That
protocol reduces queried types only to A, AAAA and PTR records. Not any
other record is queried over this protocol.
But systemd-resolved breaks iterative questions over local stub. I tried
src.fedoraproject.org as an example, but it would fail any domain except
root.
I would like to propose serving LLMNR names just over getaddrinfo() and
similar functions. That means nss plugins in glibc. Resolved has already
plugin for it and that is enabled by default on Fedora. It is not
enabled by default on Ubuntu. The protocol is useful especially in cases
where no central server providing DNS is used. But for some reason it
favors unreliable multicast protocol over reliable unicast DNS.
What were my surprise, when dig org. dnskey told me it does not exist.
That is nonsense, yet it is the default result with systemd-resolved
enabled.
I would like to request similar behaviour as on Windows. Only single
label queries coming from non-DNS source as is getaddrinfo() would be
resolved by LLMNR in advance. DNS queries with single label would be
resolved over DNS first. If dns replies with NXDOMAIN, then LLMNR can be
tried for a backward compatibility. It would fix weird failures in
resolved and speed up single label queries for non-addres types. Such
behaviour would be closer to the only different LLMNR implementation on
Windows.
What would you think about such change?
Regards,
Petr
1. https://github.com/systemd/systemd/issues/23494
2.
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-llmnrp/eed7fe96-9013-4dec-b14f-5abf85545385
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik at redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
More information about the systemd-devel
mailing list