Why disable LLMNR if you use public Wi-Fi?

The LLMNR protocol is a familiar face in Microsoft environments. In networks where Windows is the mainstay, it's enabled by default, and while it once made sense, today it's often more of a headache than a help. That's why it's a good idea to know how to use it. how to disable LLMNR especially if we are using a public WiFi network.

Before making any decisions, it's a good idea to understand what it does and why it's recommended to disable it. The good news is that disabling it is easy. on both Windows (including Windows Server) and Linux, either through policies, Registry, Intune, or by tuning systemd-resolved.

What is LLMNR and how does it work?

LLMNO are the acronyms of Link-Local Multicast Name Resolution. Its purpose is resolve hostnames within the local segment without relying on a DNS serverIn other words, if a machine can't resolve a name via DNS, it can try querying the neighborhood using multicast to see if anyone "takes the hint."

This mechanism uses the port UDP 5355 and is designed to operate within the local network. The query is sent by multicast to the immediate network, and any computer that “recognizes” the name can respond by saying “that’s me.” This is a quick and simple approach for small or improvised environments where DNS wasn’t available or didn’t make sense to configure.

In practice, the LLMNR query travels to the local segment, and devices listening to that traffic can respond if they believe they are the correct destination. Its scope is limited to the local link, and hence its name and its vocation as a “patch” when there is no formal name service on the network.

For years, especially in smaller networks or ad-hoc deployments, it proved useful. Nowadays, with widespread and cheap DNS, the use case has narrowed down so much that it almost always makes sense to turn off LLMNR and live more peacefully.

Is the LLMNR really necessary? Risks and context

The million-dollar question: should I take it down or leave it? In a domestic setting, the most common answer is "yes, feel free to take it down." In a company it is convenient to validate impact: If the environment's DNS is set up correctly and searches work, LLMNR provides nothing and exposes unnecessary risks.

The biggest problem is that LLMNR does not incorporate protection against impersonationAn attacker on your own subnet can "impersonate" the target device and respond early or preferentially, redirecting the connection and causing chaos. It's a classic old-school "man-in-the-middle" (MitM) attack scenario.

As an analogy, it recalls the Wi‑Fi WEP standard, which was born without considering modern attacks and has become obsolete. Something similar happens with LLMNR: It was useful in the past, but today it's an open door to deception if you leave it alive on corporate networks.

Additionally, in the hands of an adversary with the right tools, they can force your computers to “sing” sensitive information like NTLMv2 hashes when they think they are talking to a legitimate server. Once the attacker obtains those hashes, can try to crack them—with varying success depending on policies and password complexity—increasing the risk of a real intrusion.

When to disable LLMNR?

In the vast majority of modern deployments, you can disable it without breaking anything. If your clients always resolve by DNS And if you don't rely on "magic" on the local network, LLMNR is superfluous. Still, validate in critical environments before pushing the policy to the entire organization.

Keep in mind that the decision isn't just technical: it also reduces your operational and compliance risk. Disabling LLMNR is a simple, measurable, and impactful hardening control., just what any sensible security framework calls for.

Disable LLMNR in Windows

Here are the main options available to disable LLMNR in Windows:

Option 1: Local Group Policy Editor (gpedit.msc)

On standalone computers or for quick testing, you can use the Local Group Policy Editor. Press WIN + R, type gpedit.msc and accept to open it.

Then, navigate through: Computer Configuration > Administrative Templates > Network. In some editions, the setting appears under DNS client. Find the entry “Disable multicast name resolution” (name may vary slightly) and set the policy to “Enabled”.

In Windows 10 the text is usually read as “Disable multicast name resolution.” Apply or accept the change and restart your computer. to ensure that the team-side settings are applied correctly.

Option 2: Windows Registry

If you prefer to get straight to the point or need a scriptable method, you can create the policy value in the Registry. Open CMD or PowerShell with administrator permissions and runs:

REG ADD "HKLM\Software\Policies\Microsoft\Windows NT\DNSClient" /f
REG ADD "HKLM\Software\Policies\Microsoft\Windows NT\DNSClient" /v "EnableMulticast" /t REG_DWORD /d 0 /f

With this, LLMNR will be disabled at the policy level. Restart the computer to close the cycle and prevent processes with a previous state from remaining in memory.

Disable LLMNR with GPO in a domain

Another way to disable LLMNR is to apply the change centrally from a domain controller by opening the Group Policy Management Console. Create a new GPO (for example, “MY-GPO”) and edit it.

In the editor, follow the path: Computer Configuration > Administrative Templates > Network > DNS Client. Enable the “Disable multicast name resolution” policy and close the editor to save. Then, link the GPO to the appropriate OU and force the policy refresh or wait for normal replication.

Done. You now have a domain policy that consistently cuts LLMNR. Remember that the exact nomenclature of the adjustment may vary. slightly between versions of Windows Server, but the location is as indicated.

Intune: “Applied” but gpedit shows “Not Configured”

A common question: you push a configuration profile from Intune, it tells you it was applied correctly, and when you open gpedit, you see the setting as “Not Configured.” This does not necessarily mean that it is not active.. Intune applies settings via CSP/Registry that are not always reflected in the local editor as “Configured.”

The reliable way to check this is to consult the Policy Log: If it exists and is equal to 0, the value EnableMulticast on HKLM\Software\Policies\Microsoft\Windows NT\DNSClient, LLMNR is disabled even though gpedit shows “Not configured”.

If you prefer to ensure this via script (useful like Remediation in Intune), here's a simple PowerShell script to create the value and verify it:

New-Item -Path "HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient" -Force | Out-Null
New-ItemProperty -Path "HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient" -Name "EnableMulticast" -PropertyType DWord -Value 0 -Force | Out-Null
(Get-ItemProperty -Path "HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient").EnableMulticast

This covers the case where Intune says it was applied, but you want maximum certainty or to troubleshoot “rogue” devices. To audit in bulk, combine the script with your inventory tool or with Intune/Defender for Endpoint reports.

Disable LLMNR on Linux (systemd-resolved)

On distributions like Ubuntu or Debian that use systemd-resolved, you can “kill” LLMNR directly. Edit the resolver settings So:

sudo nano /etc/systemd/resolved.conf

In the file, set the corresponding parameter so that it is unambiguous. For example:

[Resolve]
LLMNR=no

Save and restart the service or computer: Restarting the service is usually sufficient, although a reboot is also valid if it is more convenient for you.

sudo systemctl restart systemd-resolved

With that, systemd-resolved will stop using LLMNR. If you use another resolution solution (or other distros), check their documentation: the pattern doesn't differ too much and there is always an equivalent “switch”.

About NBT‑NS and Windows Firewall

Disabling LLMNR is half the battle. Responder and similar tools also exploit NetBIOS Name Service (NBT‑NS), which works over classic NetBIOS ports (UDP 137/138 and TCP 139). This raises the question many people ask: is it enough to block ports in the firewall, or do you have to explicitly disable NBT‑NS?

If you apply strict rules on your local firewall—both inbound and outbound—blocking 137/UDP, 138/UDP, and 139/TCP, you greatly reduce your exposure. However, best practice in enterprise environments is to disable NetBIOS over TCP/IP. in interfaces, to prevent unwanted responses or advertisements if the firewall policy changes or is modified by an application.

In Windows, there is no “factory” GPO as direct as in LLMNR, but you can do it via WMI or Registry. This WMI-based PowerShell disables it on all IP-enabled adapters:

Get-WmiObject -Class Win32_NetworkAdapterConfiguration -Filter "IPEnabled=TRUE" | ForEach-Object { $_.SetTcpipNetbios(2) } 

If you prefer firewall rules, go ahead, but make sure they are bidirectional and persistent. Blocks 137/UDP, 138/UDP and 139/TCP and monitors that there are no conflicting rules in other GPOs or EDR/AV solutions that manage the firewall.

Verification: How to check that LLMNR and NBT-NS are out of play

For LLMNR on Windows, look at the Registry: HKLM\Software\Policies\Microsoft\Windows NT\DNSClient\EnableMulticast must exist and be equal to 0. Quick Check in PowerShell would:

(Get-ItemProperty -Path "HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient").EnableMulticast

At the traffic level, a simple technique is to run a search for a non-existent name and use Wireshark to observe that no UDP 5355 packets are output. If you don't see multicast to the local segment, you're on the right track.

On Linux with systemd-resolved, check the status with resolvectl or systemctl: Make sure LLMNR is set to “no” in the effective configuration and that the service was restarted without errors.

For NBT‑NS, confirm that your firewall rules block 137/UDP, 138/UDP, and 139/TCP or that NetBIOS is disabled on the adapters. You can also sniff the net for a while to check that there are no NetBIOS requests or advertisements on the air.

Frequently asked questions and useful nuances

• Will I break anything by disabling LLMNR? In networks with well-maintained DNS, this is typically not the case. In special or legacy environments, validate first in a pilot group and communicate the change to support.
• Why does gpedit show “Not Configured” even though Intune says “Enforced”? Because the local editor doesn't always reflect states imposed by MDM or CSP. The truth is in the Registry and the actual results, not in the gpedit text.
• Is it mandatory to disable NBT‑NS if I block NetBIOS on the firewall? If the blocking is complete and robust, you greatly reduce the risk. Still, disabling NetBIOS over TCP/IP eliminates stack-level responses and avoids surprises if the rules change, so it's the preferable option.
• Are there any ready-made scripts to disable LLMNR? Yes, via Registry or PowerShell, as you've seen. For Intune, package the script as Remediation and add compliance checking.

Turning off LLMNR reduces the spoofing surface on the local network and nips hash-grabbing attacks with tools like Responder in the bud. If you also block or disable NBT‑NS and take care of your DNSYou'll have a simple and effective security cocktail: less noise, less risk, and a network that's much better prepared for everyday use.