Since the release of Windows Server 2000, the preferred method for name resolution has been DNS queries. As long as the server has proper DNS client configuration in place, the name resolution process is often considered to be highly predictable, meaning that if a record is present in the DNS zone, the corresponding IP address is provided to the DNS client, as expected. At the same time, if a certain record is missing in the DNS zone, the non-existence of this name is presented as well. A negative DNS answer is, technically, called a NXDOMAIN reply.
Typically, the name resolution process is expected to end at a negative answer from the DNS server.
However, unknown to many administrators, Windows Server has no less than three additional mechanisms for name resolution.
The three non-DNS name resolution methods are called:
NetBIOS name broadcast
Link-Local Multicast Name Resolution (LLMNR)
MulticastDNS (mDNS)
These three methods have some common characteristics:
- All three methods are enabled by default.
- The three alternatives require no configuration to be operational.
- The methods are only used if the system, an application, or the administrator attempts to resolve a “short” name, i.e., not an FQDN.
- The alternative methods are only used after DNS resolution has failed, either by the queries timing out or the DNS server returning a negative answer (“NXDOMAIN”).
- The methods can only resolve names on the local subnet.
- The three methods are used simultaneously, i.e., the server will send the broadcast/multicast at the same moment, with no waiting time between the requests.
- The queries are sent, through broadcast and multicast, to all nodes on the local LAN segment.
- No authentication or verification is possible on the incoming replies. Any anonymous reply will be considered true.
The final point is important to consider in a security hardening process. Since any machine on the local subnet can reply to any request, legit or not, it is possible for a malicious user to intentionally provide incorrect answers. This option could be used to stage, e.g., various man-in-the-middle attacks.
(Example from an isolated test domain.)
For example, assume an administrator wishes to establish an RDP session to a particular server. However, the administrator accidentally misspells the short server name and the DNS query fails. The name resolution will now, likely unknown to the administrator, progress to the three broadcast / multicast-based methods. If a malicious person has control over one single device on the local IP subnet, this person can now respond, feeding back an incorrect IP address. This will provide a trivial opportunity to steal credentials, and in the worst case, even domain administrator credentials.
Network port usage of the involved protocols:
NetBIOS name broadcast:
The oldest method, but still included by default, since the release of the first versions of Windows NT in the early ‘90s. The network packet is sent to the local IP subnet broadcast address, e.g., 192.168.99.255. The data is transported on port UDP/137.
Link-Local Multicast Name Resolution:
LLMNR was introduced with Windows Server 2008. LLMNR is active unless disabled through a Group Policy setting. The protocol utilizes port UDP/5355 and is sent to multicast address 224.0.0.252.
MulticastDNS:
mDNS was introduced during the year 2022 to the server operating systems Windows 2019 and Windows 2022. mDNS has previously been used extensively in other setups, e.g., the Apple Bonjour suite. mDNS operates on port UDP/5353 and the queries are sent on the multicast address 224.0.0.251.
VERIFY THE STATUS:
To verify the current local state, use a classical Command Prompt (CMD) and run the following commands:
netstat -nao | FIND /i ":137 "
netstat -nao | FIND /i ":5353 "
netstat -nao | FIND /i ":5355 "If you receive any output, one or more of the local name resolution methods are active on your system.
To examine the current usage of these protocols on your network, Wireshark could be used with the following capture filter: udp port 137 or udp port 5353 or udp port 5355
To use the built-in packet sniffer PKTMON, use these filters to capture the non-DNS name resolution:
pktmon filter remove
pktmon filter add "NetBIOS" -t UDP -p 137
pktmon filter add "LLMNR" -t UDP -p 5355
pktmon filter add "mDNS" -t UDP -p 5353
pktmon filter listIn part two of this article series, you will learn how to disable the three protocols. Read the post here.