Windows 11 25H2 Still Uses LLMNR and NetBIOS: How to Disable Both Safely

The finding comes from a hands-on test by Gregory Gibson at MakeUseOf. He watched a Windows 11 virtual machine with Wireshark, turned off LLMNR and NetBIOS name resolution, and checked what stopped working. Very little did, until he connected to a Windows NT 4 share.

The protocols in question​

When you type a hostname, Windows needs an IP address. DNS usually supplies it. When DNS has no answer, especially for a single-label name like fileserver instead of fileserver.contoso.com, Windows has fallback methods:

• LLMNR (Link-Local Multicast Name Resolution): Microsoft's protocol documentation says it resolves names on the local link when ordinary DNS can't. In the MakeUseOf description, LLMNR asks devices on the same local network to help resolve a name.
• NetBIOS Name Service (NBNS): this broadcasts a query, and a corresponding machine with that NetBIOS name responds with its IP address. It is old enough that its RFCs (1001 and 1002) date from the 1980s.
• mDNS (Multicast DNS): this is the replacement Microsoft prefers. It can work without conventional DNS, and is used by devices like Google Chromecast for device discovery. Windows has supported it starting with Microsoft Windows 10 1703, according to UNBLOG.

All three work the same basic way: a PC asks the whole local network who owns a name and trusts whoever answers. That trust is the security problem, as explained below.

What Microsoft promised in 2022​

On April 22, 2022, Microsoft's Windows Core Networking team published a post titled "Aligning on mDNS: ramping down NetBIOS name resolution and LLMNR." The post stated that NetBIOS name resolution and LLMNR are rarely used today. This means that having them enabled needlessly expands the attack surface of devices and increases the load on the networks they use. It also acknowledged that disabling these protocols needs to be balanced with real-world deployments which may still depend on them.

The 2022 plan had stages:

• Cellular: NetBIOS name resolution has been turned off by default on cellular interfaces for some time.
• Insider builds: NetBIOS is in learning mode. Learning mode means that NetBIOS is used as a fallback if mDNS and LLMNR queries fail.
• LLMNR: The default LLMNR behavior has not been changed in Windows yet. This will be part of the next steps toward the "mDNS is the only multicast name resolution protocol on by default" goal.

Microsoft has never published a removal date. As MakeUseOf notes, the company described a gradual transition and cited network traffic and an increased attack surface, while still acknowledging that some networks do still need these older protocols.

In short: Microsoft set a clear goal of making mDNS the only multicast name resolution protocol on by default, but gave no deadline. In 2026, both older protocols are still around.

What the test showed​

Gibson used a lightly configured Windows 11 25H2 Pro VM on Proxmox. Before changing anything, he found that NetBIOS over TCP/IP was Enabled. The adapter option was Default, which means DHCP controlled the setting and enabled NetBIOS. The group policy object for turning off LLMNR was Not Configured, leaving that protocol also enabled.

He filtered a Wireshark capture for DNS, LLMNR, NetBIOS Name Service and mDNS traffic, then ran ping muo-test-01, a name that didn't exist on his network. The ping failed, as expected. Before it failed, Windows sent:

• LLMNR queries for muo-test-01
• mDNS queries for muo-test-01.local
• NetBIOS name queries for MUO-TEST-01, broadcast to the local subnet

The VM's network profile was set to Public throughout, and NetBIOS traffic still appeared.

Two caveats​

First, a nonexistent name sends every fallback. Under learning mode, NetBIOS runs only after mDNS and LLMNR fail. A name that doesn't exist makes everything fail, so NetBIOS would show up either way. The capture proves NetBIOS was active. It can't tell whether it was in learning mode or fully enabled. That is my reading of the method, not something Gibson claimed.

Second, the Public-profile result doesn't match Microsoft's documented default. Microsoft's ADMX_DnsClient policy reference says the DNS client disables NetBIOS name resolution on public networks by default. Gibson's VM had the adapter's NetBIOS setting at Default, which leaves the decision to DHCP, and his DHCP server had NetBIOS turned on. The adapter setting and the DNS client policy are separate controls, and the order in which they apply isn't spelled out in the material I reviewed. Treat the Public-profile result as specific to that machine and network, not proof that every Windows PC behaves this way.

How to switch them off​

Gibson made two changes. Both match Microsoft's documentation.

1. Disable LLMNR with Group Policy​

• Open the Local Group Policy Editor (gpedit.msc). It is included in Pro, Enterprise and Education, not Home.
• Go to Computer Configuration → Administrative Templates → Network → DNS Client.
• Open Turn off multicast name resolution and set it to Enabled.

Yes, you set it to Enabled to turn the protocol off. Microsoft's policy reference says enabling it disables LLMNR on every network adapter, while Disabled or Not Configured leaves LLMNR on. Despite the name, Gibson notes, this policy won't disable mDNS. Microsoft's LLMNR security guidance has listed this same policy, along with blocking TCP/UDP 5355, as a workaround. It also warns that as a consequence the computer may become invisible to other computers.

2. Disable NetBIOS over TCP/IP on the adapter​

• Open the network adapter's Properties.
• Select Internet Protocol Version 4 (TCP/IPv4), then Properties → Advanced.
• On the WINS tab, change the setting from Default to Disable NetBIOS over TCP/IP.
• Restart. Gibson restarted before testing again.

This is a per-adapter setting. A laptop with both Ethernet and Wi-Fi needs it on each adapter.

For fleets​

• DHCP: Microsoft documents a vendor-class option, 001 Microsoft Disable Netbios Option with the value 0x2, that disables NetBIOS over TCP/IP on Windows 10 and Windows 11 clients whose adapters are set to take the NetBIOS setting from DHCP. That is the same Default setting Gibson's VM used.
• NetBIOS policy: Newer DNS Client policy templates include a Configure NetBIOS settings policy. According to gHacks, its choices include Disable NetBIOS name resolution -- Turns off NetBIOS support on the device., disabling it only on public networks, and learning mode.

Check that it worked​

• ipconfig /all should show NetBIOS as disabled on the adapter. Gibson used this check.
• net config redirector or net config server lists SMB transport bindings. Microsoft documents that NetbiosSmb is the NetBIOS-less transport, while each NetBT_Tcpip entry means NetBIOS over TCP is still bound to an adapter.
• To confirm the traffic itself has stopped, run a packet capture before and after.

Gibson's second capture with the same filter and the same failed ping showed:

What broke, and what didn't​

With both protocols off, these still worked on Gibson's network:

• Web browsing
• His Proxmox dashboard, which his local DNS server resolves
• An SMB file server that still broadcasts a NetBIOS name
• An SMB share on an old Windows 8 tablet

This is expected. Microsoft's documentation on direct-hosted SMB says Windows has run file and printer sharing directly over TCP port 445 since Windows 2000 (KB 204279), well before the SMB 2.0.2 dialect shipped with Windows Vista and Server 2008. If you turn off NetBIOS, SMB still works but relies on DNS to find servers. Microsoft lists that as a benefit: one name-resolution path and one less legacy protocol for attackers.

The Windows NT 4 Workstation VM was where things broke. Gibson turned on SMB1 and re-enabled NetBIOS on the Windows 11 VM, then connected to the NT share and opened a test file. When he disabled NetBIOS and restarted, the connection failed. When he re-enabled it and restarted, it worked again. Microsoft's own documentation gives the same warning: disabling NetBIOS over TCP/IP can stop a Windows PC from talking to older operating systems over SMB.

In short: For a modern network with working DNS, turning off LLMNR and NetBIOS caused no problems in this test. For anything that depends on NetBIOS, such as old OS shares, WINS, or legacy line-of-business devices, it will cause problems.

Why security teams want them off​

Both protocols take answers from anyone on the network. If an attacker on the same network replies first, Windows trusts the reply. It may then send the attacker authentication attempts that can be cracked or relayed. MITRE ATT&CK tracks this attack as T1557.001 (Man-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay). It is a standard technique in internal penetration tests because a mistyped share name can be enough to start it.

A Microsoft program manager on the networking team went further in the 2022 comment thread. He said that in a Zero Trust deployment, multicast name resolution should not be used at all. With mDNS, LLMNR and NetBIOS name resolution all disabled, every query goes to the configured unicast DNS servers. That was one engineer's comment in a discussion, not a formal support statement, but it shows where Microsoft wants enterprise networks to end up.

mDNS is not risk-free. It also accepts answers from whoever replies on the network. Moving to it reduces three multicast responders to one. It does not remove the trust problem.

Why the phase-out is slow​

The NT 4 result explains the delay. Old operating systems are rare, but plenty of things still rely on broadcast name lookup: networks with no internal DNS, old NAS boxes, industrial controllers, and lab equipment running decades-old embedded Windows. If Microsoft turned the protocols off everywhere in a cumulative update, many networks would lose access to devices nobody remembers depend on NetBIOS.

The cautious approach still has a cost. Every year the defaults stay the same, a home user with a misspelled share name sends a request any device on the café Wi-Fi can answer. A mid-sized company can audit and turn this off with one GPO. Most home users won't know the setting exists.

Practical advice​

• Home users on a modern network: Turning off LLMNR and NetBIOS is a low-risk change if your NAS and shares resolve through DNS or mDNS. Test your shares and printers afterward.
• Admins: Do it in stages. Run a packet capture or check DNS client logs on a pilot group first, then roll out the LLMNR GPO and the NetBIOS DHCP option or policy. Keep a list of exceptions for older systems.
• Anyone with legacy kit: Isolate those devices on their own network segment rather than leaving NetBIOS on for every machine to support one old system. That machine likely also needs SMB1, which is a bigger problem.

Microsoft's 2022 plan is still unfinished. On Gibson's VM, both protocols were active, two settings turned them off, and the only thing that broke was a share on a 25-year-old operating system.

Correction (October 22, 2026): Fixed the direct-hosted SMB date: Microsoft documents SMB directly over TCP port 445 since Windows 2000 (KB 204279), not since SMB 2.0.2 in Windows Vista and Server 2008. Also corrected the MITRE ATT&CK technique name to T1557.001 "Man-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay" per attack.mitre.org.