The modern standard for multicast name discovery is mDNS. However, Windows supports other multicast name resolutions protocols for historical reasons, including NetBIOS name resolution and LLMNR. More details about the documentation for each of these protocols can be found here.
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. Disabling these protocols needs to be balanced with real-world deployments which may still depend on them, but it is still the right direction to go.
NetBIOS name resolution has been turned off by default on cellular interfaces for some time because it should never be applicable there. In the latest Windows Dev and Beta Insider builds, it has been placed in “learning mode” where NetBIOS is only used as a fallback after mDNS and LLMNR queries fail. This means devices will typically stop using NetBIOS name resolution unless it is manually re-enabled because mDNS will most frequently answer first.
If this causes connectivity issues, the previous NetBIOS name resolution functionality can be restored by enabling the “Configure NetBIOS settings” Group Policy and select one of the allow or learning modes. This Group Policy can be found under Computer Configuration > Administrative Templates > Network > DNS Client.
Another way to restore the original NetBIOS name resolution behavior is to use the registry. Under the “ComputerHKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesDnscacheParameters” key, create a REG_DWORD called “EnableNetbios” and set it to one of the following values:
|2||Disabled on public networks|
|3||Learning mode (the current default in Insider builds)|
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.
Going forward, depending on how this first stage goes (so far, the data indicate it is going well), these protocols will progress toward being turned off by default in all cases. Like any other case of disabling long-enabled OS functionality, this will be a careful process open to feedback.