LLMNR [1] is multicast name resolution protocol. I think it should be disabled on all Server deployments unless explicitly requested by the administrator. Unfortunately it breaks some kinds of DNS queries [2] because the way it is implemented in systemd-resolved. It makes dig -t NS org. return error telling that domain does not exist.
I think LLMNR should be disabled in whole distribution, because even Microsoft is removing support for it [3]. I doubt it were wanted even in Server builds especially. Those usually rely on more controlled infrastructure, meaning standard unicast DNS.
If you would know a common use case, why it should be still wanted, can you share it? I have created issue #114 for it on fedora-server [4]. Have you ever used single label name to connect to your server? I think mDNS has less problematic implementation in avahi, but that has to be enabled explicitly. I think that is desired especially on servers.
It were introduced by systemd-resolved change [5], but there were no statement that it would have negative impact on DNS resolution.
What would you think about it?
1. https://www.rfc-editor.org/rfc/rfc4795 2. https://bugzilla.redhat.com/show_bug.cgi?id=2220973 3. https://techcommunity.microsoft.com/t5/networking-blog/aligning-on-mdns-ramp... 4. https://pagure.io/fedora-server/issue/114 5. https://fedoraproject.org/wiki/Changes/systemd-resolved#Local_multicast_DNS
On Sun, Jul 09, 2023 at 02:10:02AM +0200, Petr Menšík wrote:
I think LLMNR should be disabled in whole distribution, because even Microsoft is removing support for it [3]. I doubt it were wanted even in Server builds especially. Those usually rely on more controlled infrastructure, meaning standard unicast DNS.
I guess it can be disabled. It never gained any popularity.
I think mDNS has less problematic implementation in avahi, but that has to be enabled explicitly. I think that is desired especially on servers.
Actually, the coexistence of Avahi and system-resolved is an interesting topic, underdocumented in my opinion. It would be nice (but disabling LLMNR should not depend on) to have some FAQ on that. - both avahi and resolved seem to have resolving capacity for mDNS - only avahi can announce mDNS services (is this correct?) - how do apps needing mDNS resolver work? Like CUPS. Do those apps talk to avahi? To resolved? Are they using nss to resolve mDNS? - how to those apps register resources (like printers) to announce? With avahi? With resolved? - should avahi be disabled when using resolved with MulticastDNS=true (or =resolve)? - what exactly MulticastDNS=true mean? - which app should bind to port 5353/UDP - etc.
On 7/10/23 19:40, Tomasz Torcz wrote:
I guess it can be disabled. It never gained any popularity.
Unfortunately we have only opinions, not numbers to back this argument. I share that view however. Since Windows 10, every windows should respond to mDNS also. Apple systems respond only to mDNS.
I think mDNS has less problematic implementation in avahi, but that has to be enabled explicitly. I think that is desired especially on servers.
Actually, the coexistence of Avahi and system-resolved is an interesting topic, underdocumented in my opinion. It would be nice (but disabling LLMNR should not depend on) to have some FAQ on that.
- both avahi and resolved seem to have resolving capacity for mDNS
Current ability of released systemd-resolved is to resolve hosts only AFAIK. Maybe SRV entries too?
- only avahi can announce mDNS services (is this correct?)
Yes, I think so. Probably until PR #22532 is merged.
- how do apps needing mDNS resolver work? Like CUPS. Do those apps talk to avahi? To resolved? Are they using nss to resolve mDNS?
They are using nss-mdns plugin, which in turn uses avahi-daemon, when used from getaddrinfo() call, if they want just addresses. If they want list of services, avahi libraries are used by client applications like CUPS. Via DBus calls it obtains current cached entries from the avahi-daemon cache.
Of course nss-resolve plugin could do similar thing for addresses. But I am not sure how it should work for applications linking to avahi-libs.
- how to those apps register resources (like printers) to announce? With avahi? With resolved?
Applications have to use some API to request service announced, unless it is statically defined in avahi configuration.
- should avahi be disabled when using resolved with MulticastDNS=true (or =resolve)?
I read on some Microsoft article that multiple mdns stacks are common on single host. I guess it might be true also for Google Chrome browser.
There is continuous querying PR #22532 [1] in progress, which may add abilities to do also service browsing. Not sure how is handling by clients expected to work and how (in)compatible they would be.
It adds mdns-browse-services command, similar to avahi-browse command I assume.
- what exactly MulticastDNS=true mean?
It means systemd-resolved will send queries for .local domain (resolver part) and also answer to queries received from the network (responder part). Of course firewall might restrict it.
- which app should bind to port 5353/UDP
I am not sure whether multiple stacks listening on mdns port can work. I think only one should listen. I would prefer Avahi, as it already has known behaviour and widely used bindings.
- etc.
1. https://github.com/systemd/systemd/pull/22532
server@lists.fedoraproject.org
-
Petr Menšík -
Tomasz Torcz