Disable LLMNR protocol in default builds

[pemensik]

Even Microsoft has disabled resolution over LLMNR protocol in their Windows 10. I have found that when testing something and wondered, why mDNS works but LLMNR does not on Windows machine in our network. Found mDNS is now preferred and updated systems get it disabled.

Found an article about that is by design, not conincidental: https://techcommunity.microsoft.com/t5/networking-blog/aligning-on-mdns-ramping-down-netbios-name-resolution-and-llmnr/ba-p/3290816

Because the way systemd-resolved is breaking some operations in DNS, I would like it disabled by default. Multicast DNS is preferred solution and has separate .local domain. It makes it easier to decide which queries should be directed to multicast resolution. Legacy users on Windows 7 should be forced to enable it, if they want to use it.

Related: #23622

[poettering]

Has it actually been disabled in Windows 10? the way i read that document and the links they haven't done so yet, but are just planning to do so. is there any doc that makes clear they actually turned it off for good?

I am not sure we should hurry any change regarding this into v254. in particular as just switch this around might create problems to people who currently use it.

[pemensik]

Yes, I think we should hurry. I found that when trying to ping my father's pc running Windows 10, that it responded to <name>.local, but not anymore just <name>. I am quite sure I did not disable it on his PC nor he would know how to do that. That brings me to the only outcome, that it was disabled by some updates.

I have more stations to test it later, but I am quite sure the result will just confirm this.

Anyway, it was causing regressions to me and I am sure other people also. If they want that, let them express that by explicit line in resolved.conf. I am not saying it should not be possible to use it. I say people who never requested that should not get it enabled by default.

mDNS should be preferred for new deployments. It does not cause similar regressions.

[pemensik]

I mean, that article was written on Apr 22 2022. They may have just planned it back then, but it seems they have deployed it already. I have not found exact reference, but I do not think that really matters.

[bluca]

This is just the default of a build option, to do this experiment isn't it better to start from a distribution? IE change the Fedora build to disable it first, to shake the tree and see what falls off

[mstojens]

Hey @pemensik thank you for pinging me over on my blog post and I'm sorry I didn't see it for so long (I am the author of this post: https://techcommunity.microsoft.com/t5/networking-blog/aligning-on-mdns-ramping-down-netbios-name-resolution-and-llmnr/ba-p/3290816). I figured I would come over here to continue the discussion unless anyone has objections to that.

Hey everyone! I'm Tommy Jensen, a technical PM for the Windows DNS and HTTP native code stacks.

There is some unfortunate confusion around Windows 10 and Windows 11 because before Win11 was made public, Insider builds were called Windows 10 even though their features did not roll into Win10 by default. An example of this is another feature by our team: DNS over HTTPS (originally went to Win10 Insiders, but only shipped to Win11 in production).

All that to say that the changes you are describing apply to Win11, not Win10. That's not to say there weren't behavioral changes to other components that affected how name resolution occurred, but us placing NetBIOS NR into learning mode (it will only be called once mDNS times out) did not go into Win10, only Win11.

I cannot overstate how much I support everyone moving to mDNS. Having said that, I do respect the need to slowly ramp changes to avoid breaking in-market customers (hence we haven't entirely disabled LLMNR and NetBIOS NR yet even if we want to). How you time changes to systemd is your business. You can expect in the long run that the only multicast name resolution protocol Windows will use regularly is mDNS. Using multiple protocols for the same task just increases the possible attack surface of the machine, and it's clear that mDNS is the industry standard for this use case.

If you would like to engage with us privately so we can do things like exchange network traces, feel free to reach out to me at tojens@microsoft.com (though the weekend is starting where I live, so I'll see you next week). Side note: I also happen to be involved with encrypted DNS discovery in the IETF, so if you have any discussions about how that can work interoperably with Windows or the ecosystem at large, you can ping me for that too! We're passionate about seeing modern DNS protocols gain widespread adoption.

[bluca]

@keszybz could this be done in Fedora first given the next release is upcoming? Then we can get some real-world testing

[pemensik]

I have found later Windows desktops differentiate llmnr responder status based on network connection trust setting. If the Win10 box has public setting, which is I believe the default, it does not enable LLMNR responder on such connection. I believe that is how I got confused. You have to switch the network to trusted or home in order to have local resolution working. We lack that security default on Fedora, it just enables it always and even on servers.

At least firewall settings prevent it in public mode.

[rpigott]

I think it makes sense to disable llmnr by default, but I think we should first allow sending single-label names to mdns as host.local with a config toggle or with local in the search list.

[mstojens]

FWIW we are taking an approach in Windows where we first try mDNS, and then only try other protocols once mDNS has failed. This seemed like a safe way to reduce usage without requiring manual action from users/admins (and the few who rely on it can of course change the behavior back).

[pemensik]

FWIW we are taking an approach in Windows where we first try mDNS, and then only try other protocols once mDNS has failed. This seemed like a safe way to reduce usage without requiring manual action from users/admins (and the few who rely on it can of course change the behavior back).

Isn't the problem with this approach that mdns query to non-existent host adds significant visible timeout, before it can be considered failed? It seems to me mdns before others adds possible vector of attack, just like llmnr this way does. Except mDNS has own domain, so it is more clear when mDNS lookup should be attempted at all. I have seen again last week Active Directory example with domain.local, which seems MS legacy.

If single-label mDNS fallback needs to be explicitly enabled, then okay. But please do not give it higher priority than unicast DNS to local servers.

[mstojens]

Sorry, flying back from the IETF and catching up

If single-label mDNS fallback needs to be explicitly enabled, then okay. But please do not give it higher priority than unicast DNS to local servers.

What I was trying to say was only applicable to when we would have done LLMNR+mDNS+NBNR, now we will do mDNS->wait->then-LLMNR-NBNR, not change when we do unicast versus multicast name queries. I believe we did not change the logic for that decision... but I will double check and get back to you once I'm back to work.