The Order of Name Resolution on Windows — hosts, the DNS Cache, LLMNR/mDNS, and DoH

“The settings are the same, but only this PC cannot reach the internal server.” “It opens in the browser, but the business app fails at name resolution.” “I put it in hosts and it has no effect.”

When investigating problems like these, the first thing to establish is which mechanism is answering for that name. Windows has several paths: the cache, hosts, the DNS server, LLMNR, NetBIOS, and mDNS, and some apps use a path of their own that is separate from Windows.

This article first gives the overall picture, sorts out the shape of a name and the differences between the paths, and then moves on to the actual isolation procedure. If you need to investigate right now, jump to the relevant section from the following table.

Prerequisites for This Article

The packet capture article covers the packets that flow on the wire, and the proxy article covers “whose proxy settings get read”. This article covers the step before those: “where did the destination IP address come from”, organized on the basis of Microsoft’s primary sources.

1. The Bottom Line First

There are three things to remember.

• Windows name resolution does not always proceed down a single queue in order. The cache and hosts come first, but for a single-label name, DNS and LLMNR/NetBT run in parallel by default.³⁴
• The same name gives different results when the PC’s settings and the app’s path differ. Think of suffixes, VPN, the NRPT, and the browser’s built-in resolver separately.⁵⁶⁷
• In an investigation, restrict the path in use and compare the results. Separate cache, DNS, and link-local with the switches of Resolve-DnsName, then confirm with a settings diff against a working PC and with a capture.⁸

Use the following diagram as the overall map.

flowchart TB
    accTitle: Name resolution is a stack of layers
    accDescr: A name resolution request goes from the app's API to the DNS Client service; the cache and hosts are checked first, then the DNS server, and for single-label names only, LLMNR and NetBIOS (in parallel with DNS by default) are tried. For .local names, mDNS is an additional path alongside the configured DNS. The browser has its own resolver outside this queue
    app["App (getaddrinfo)"] --> svc["DNS Client service"]
    svc --> cache["Cache (including hosts)"]
    cache -->|if absent| dns["Query the DNS server"]
    cache -->|"if absent, single-label name (parallel with DNS by default)"| ll["LLMNR / NetBIOS"]
    svc -->|".local name (additional path)"| mdns["mDNS"]
    browser["Browser"] -.->|own resolver, DoH| ext["Separate path"]

The cache is checked first; beyond it, DNS and, for single-label names, LLMNR and NetBIOS run in parallel. The browser has a separate path.

Below, “which layer answers” is covered in Chapters 3 to 5, “how the query is sent” in Chapter 6, and “how to verify” in Chapters 7 and 8. DoH is a feature that switches the transport to the DNS server to HTTPS; it does not replace the order of hosts, cache, and NRPT.⁹

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (48 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

2. “Name Resolution” Is Not a Single Operation

All the App Gets Back Is an Address or an Error

When an app connects using a name such as www.example.com, Winsock’s getaddrinfo (the Unicode version is GetAddrInfoW) is called. For the NS_DNS namespace, this function converts the name to an address through DNS, the local hosts file, and other mechanisms. If several namespace providers respond, it aggregates their responses and returns them.¹⁰

In other words, from the result the app receives, you cannot tell which layer answered.

.NET’s Dns.GetHostAddresses also uses getaddrinfo on Windows. For a host listed in hosts, it returns that address without querying a DNS server. HttpClient runs on top of this Dns class as well, so a .NET app that connects directly to its destination inherits the Windows name resolution order.¹¹

Through an HTTP proxy, the name that gets resolved changes. What is resolved locally is the proxy’s name; the destination name is resolved on the proxy side. In that case the local hosts, cache, suffixes, and NRPT play no part in resolving the destination. Which proxy settings are used is covered in the proxy article.

2.1 The DNS Client Service Decides the Order

Working beneath getaddrinfo is the DNS Client service (service name Dnscache). Microsoft’s documentation describes the basic order as follows.³

1. Check the cache.
2. Check the hosts file.
3. Query the DNS server.

Because the contents of hosts are loaded into the cache when the service starts, this article treats the first two together as layer 1, “cache and hosts”.⁵

Beyond that, the path branches depending on the name and the policies.

The default “smart multi-homed name resolution” sends DNS, LLMNR, and NetBT queries to all networks in parallel. Which response is adopted is decided by the rules in Sections 4.3 and 5.2.⁴

Therefore, “when the query is sent” and “the priority given to the answers that come back” are two different matters. Seeing LLMNR or NetBT in a capture does not by itself mean “DNS failed”. The “three layers” in this article are a division for explanation; they do not mean that the layers always run sequentially in time order.

2.2 Things Outside the Queue

The two that are especially easy to confuse are these.

Using Edge’s built-in client does not by itself mean that the DNS server changes. Section 6.2 treats it separately from the Secure DNS setting that selects a different provider.

3. Layer 1 — The Cache and hosts

What you want to know at this layer is what answers remain inside the PC. The cache holds not only correct answers but also stale answers and “the name does not exist” answers.

3.1 hosts Is Loaded Into the Cache

The hosts file is at C:\Windows\System32\drivers\etc\hosts. When the DNS Client service starts, its name-to-IP-address mappings are loaded into the resolver cache. Records obtained from DNS queries are held in the same cache for their TTL (time to live).⁵

ipconfig /displaydns shows both the entries loaded from hosts and the entries obtained by recent DNS queries.¹³ In Microsoft’s own example, if you put contoso.com in hosts, Resolve-DnsName contoso.com returns that address and no DNS traffic flows.³

How to Read the Absence of DNS Packets

If you resolve an FQDN without DoH or DoT, name resolution succeeds, and there is no query on port 53, the cache or hosts is presumably answering. First, however, rule out the following other paths.

Do not conclude “cache” just because “there is nothing on port 53”; look at the paths that could be in use as well. A single line of test hosts left on a development machine can send an investigation astray.

Editing hosts requires administrator rights, and security products may detect the change. A design that makes business app operations depend on hosts should be avoided.

3.2 Negative Responses Are Cached Too

“Not found” is also one of the answers that get cached. The DNS client stores negative responses as well as positive ones.⁵

If ipconfig /displaydns shows “Name does not exist” for the target name, a negative response from the DNS server remains on the client. Microsoft’s procedure tells you to discard it with ipconfig /flushdns.¹⁴¹³

The retention time of the negative cache is MaxNegativeCacheTtl under HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters, and the default is 5 seconds.¹⁵ This is why a PC can keep returning failures for a few seconds even right after a record has been added to DNS.

3.3 TTL and “Only Some PCs Are Stale”

Positive responses also remain for their TTL. A PC that resolved the name before the server’s IP address was changed keeps using the old answer, while a PC that resolves it for the first time after the change gets the new one. Even with the same DNS server, the result differs when the time of the lookup differs.⁵

Clear-DnsClientCache behaves the same as ipconfig /flushdns and deletes the entire contents of the cache, including negative responses.¹⁶ With Get-DnsClientCache, you can retrieve the cache as objects and check the record type and the remaining TTL.¹⁷

# Is a specific name in the cache, and how many seconds of TTL remain?
Get-DnsClientCache -Entry 'app01.corp.example.com' |
    Select-Object Entry, Type, Status, TimeToLive, Data

# Check the contents of hosts and the cache together
ipconfig /displaydns | Select-String -Pattern 'app01' -Context 0,6

# Discard the cache (including negative responses)
Clear-DnsClientCache

If an answer is found at layer 1, this lookup is decided before it reaches the DNS server. However, the possibility remains that a wrong answer was originally learned from the DNS server. Do not stop at clearing it; also check the answer obtained afresh in Step 3 of Chapter 8.

4. Layer 2 — Querying the DNS Server

If layer 1 has no answer, resolution proceeds to DNS. Here, think separately about which name is sent, to which server, and at what timing.

4.1 Single-Label Names and Suffixes

First, check the shape of the name the app passed.⁵

A suffix is the domain part appended after a short name. Appending corp.example.com to app01 makes the queried name app01.corp.example.com.

When a Search List Exists

Suffixes from the DNS suffix search list are appended in order from the top, and the name is sent with a trailing dot. Once a search list is configured, only that list is used. The primary suffix, connection-specific suffixes, and name devolution are not used.¹⁸

When There Is No Search List

The primary DNS suffix is appended. If name devolution is enabled, the leftmost label is dropped after each failure and the name is tried again; for example, from www.test.contoso.com to www.contoso.com. If an adapter has a connection-specific DNS suffix, that is appended and sent too.⁵

For this reason, the same server01 expands differently in an environment where Group Policy distributes a search list and in an environment where domain membership supplies a primary suffix.

A Long List Also Increases the Wait

If the correct suffix is near the end of the list, the query time accumulates until it is reached. Microsoft also explains this delay with an example that tries six suffixes. To try only one specific expansion, append a trailing dot, as in internal.contoso.com..³

# Global settings: search list and devolution
Get-DnsClientGlobalSetting

# Per interface: connection-specific suffix and registration settings
Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix, UseSuffixWhenRegistering

# DNS servers per interface (both IPv4 and IPv6)
Get-DnsClientServerAddress | Where-Object ServerAddresses | Select-Object InterfaceAlias, AddressFamily, ServerAddresses

Get-DnsClientGlobalSetting returns the global settings such as the search list and whether and to what level devolution is enabled; Get-DnsClient returns the per-interface settings.¹⁹²⁰

4.2 The Order of Multiple DNS Servers and Timeouts

When “it does not fail, but there is a wait of several seconds”, suspect retransmissions to an unresponsive DNS server. For the DNS servers configured on a single NIC, the default retransmission timing lines up as follows.²¹

This is the table for the case where there is no response. In particular, do not confuse the following two.

When “we stopped one of them but it does not switch over”, if a server holding an old zone keeps running and returns negative responses, resolution does not move on to the next server.²¹

The Fourth and Later Servers Are Not Reached Until 4 Seconds In

If the server that can respond is fourth or later in the list, at least 4 seconds pass after the first query. If the app’s deadline is shorter than that, it fails at the name resolution stage. To get the query out sooner, you would have to move that server into the first three, but the root fix is to repair the unreachable servers ahead of it, or remove them from the settings. Review the app-side timeout as well.²¹

In Microsoft’s example, too, a configuration in which only one of four servers is reachable takes about 4 seconds to complete. You can measure the elapsed time with Measure-Command, and the same document treats under 1 second as acceptable.³

# Ask a specific server directly, DNS only, and get the elapsed time in milliseconds
(Measure-Command {
    Resolve-DnsName -Name 'app01.corp.example.com' -Server 10.0.1.2 -DnsOnly
}).TotalMilliseconds

Because this command pins the server, it measures the response time of that server alone. The delay until the fourth entry in the list is reached is checked with a query without -Server, or with a capture of that query.

Note that the DNS client moves faster-responding servers up, remembers unresponsive servers, and retries them periodically. The initial timeout is also adjusted within a range of 25 to 1,000 milliseconds based on past performance. The table above is the default skeleton, which is why actual measurements deviate from it.⁵

4.3 Multiple NICs and “Smart Multi-Homed Name Resolution”

On a PC with both wired and Wi-Fi, or a PC to which a VPN adapter is added, check not only the list of DNS servers but also the querying across networks and the selection of the response.

Retransmission to Multiple Adapters

In Microsoft’s query procedure, the query goes to the first DNS server of the preferred adapter, with a 1-second wait. If there is no response, it goes to the first server of every adapter still in the candidate set, with a 2-second wait, and after that to all servers of all adapters, with waits of 2, 4, and 8 seconds. When a server on one adapter returns a negative response, the other servers of that adapter are removed from the candidates.⁵

The Policy That Controls Parallel Querying

The Group Policy setting “Turn off smart multi-homed name resolution” controls the following behavior.⁴

Because the policy is named “Turn off”, note that enabling the policy disables the optimization.

An Example Where VPN Changes the Result

When an internal name is queried, the DNS on the VPN side returns the internal address, and the DNS on the home router side can also return a different positive response: a public address under the same domain name as the internal one, or the address of an advertising page substituted for a non-existent name, for example.

With two positive responses, the adoption is decided by the binding order. On current Windows, this priority is determined by the interface metric; the smaller the InterfaceMetric shown by Get-NetIPInterface, the higher the priority. Differences in this order from PC to PC become differences in the result.²²

If, on the other hand, the home side returns a negative response, that adapter is removed from the candidates and the VPN side’s answer is used.⁵ VPN products distribute the NRPT or “Turn off smart multi-homed name resolution” precisely to control these differences.

4.4 NRPT — Changing Where Queries Go per Namespace

The NRPT (Name Resolution Policy Table) is a table that specifies, per namespace such as .corp.contoso.com, which DNS servers to use and the DirectAccess and DNSSEC settings. DirectAccess and Always On VPN profiles write rules into it to produce behavior such as “send only internal names to the internal DNS”.²³⁶

Get-DnsClientNrptPolicy -Effective shows the rules actually in effect.

# The NRPT rules actually in effect
Get-DnsClientNrptPolicy -Effective

# Show only the rules for a specific namespace. -Namespace only filters on the Namespace attribute; it does not match against a name.
# Passing 'app01.corp.example.com' does not return the suffix rule for '.corp.example.com'.
# To find which rule applies to a name, enumerate the rules and match them yourself, as in Step 4 of Chapter 8
Get-DnsClientNrptPolicy -Effective -Namespace '.corp.example.com'

The NRPT applies only to apps that use the Windows DNS API. Apps with their own DNS implementation bypass that path. The VPNv2 CSP documentation cites nslookup as an example and requires Resolve-DnsName for checking the NRPT. The browser’s built-in resolver and DoH are also outside the Windows DNS API.⁶

5. Layer 3 — The Escape Routes for Single-Label Names: LLMNR, NetBIOS, and Then mDNS

5.1 How the Three Protocols Differ

LLMNR and NetBIOS over TCP/IP (NetBT) are alternative means of resolving a single-label name such as app01. By default they run in parallel with DNS, and a link-local response can be adopted even when DNS returns a positive response. They become sequential after a DNS failure only when smart multi-homed name resolution has been turned off.⁴

mDNS is separate from these; it is an additional path for .local names. It is not a catch-all that kicks in after DNS resolution of a single-label name has failed.²⁴

Even for .local, Do Not Skip Checking DNS

.local does not become mDNS-only. If the Active Directory domain is something like corp.local, that name continues to be resolved by the configured DNS servers and the NRPT as well. RFC 6762 also allows coexistence with unicast DNS. When investigating .local names, check the DNS and VPN policies too.²⁴

NetBT Depends on Whether WINS Exists and on the Node Type

Without WINS configured the default is B-node; with even one WINS server configured, the default is H-node.²⁹ LLMNR and NetBT broadcasts do not cross subnets, but queries to WINS are unicast and therefore can.

nbtstat -c shows the NetBIOS name cache, and nbtstat -R purges the cache and reloads LMHOSTS.³¹

5.2 Which One Takes Priority

Which response takes priority after the parallel queries is also governed by policy.⁴

On home or public networks, the answer from a nearby device with the same name can take priority over DNS. Here too, it matters to read the response priority separately from whether the queries are sequential or parallel.

5.3 Microsoft’s Direction: Aligning on mDNS

In April 2022, Microsoft announced a direction of aligning on mDNS and gradually ramping down NetBIOS name resolution and LLMNR.²⁷ Old and insecure device discovery protocols such as Computer Browser have been deprecated as well.³² Designs that supplement single-label names with multicast or broadcast are on their way out.

Microsoft’s information on the LLMNR vulnerability lists, as workarounds, blocking TCP/UDP 5355 and enabling the Group Policy setting “Turn off multicast name resolution”. It also states that as a consequence the computer may become invisible to other computers.²⁵ Enabling this policy disables LLMNR on all adapters of the DNS client.⁴

The decision to disable them is itself correct, but a replacement for the path that disappears has to be provided in DNS. For devices not registered in DNS, register their A records or enable dynamic registration through DHCP, and change the destinations to FQDNs. Devices that support mDNS can use .local names, but the reach is limited to where multicast gets through.

5.4 The Typical “Only Some PCs Cannot Connect” Case: Single-Label Names

When a configuration file or shortcut contains \\fileserver01 or http://app01/, the same name produces the following differences.

What Resolve-DnsName app01 -LlmnrOnly tells you is “whether it can be resolved through LLMNR”. It does not tell you where the answer adopted in everyday queries came from. Comparison with the result without switches, and captures, are done in Step 5 of Chapter 8.⁸

The Root Fix Is FQDNs and DNS Registration

Change destinations that depend on single-label names to FQDNs, and consolidate name resolution on DNS.

SMB2 and later connect directly on TCP 445 and do not use NetBIOS sessions.³³ That, however, is a matter of transport. At the stage of resolving the name in a destination such as \\fileserver01\share, LLMNR or NetBT may be used. Specify the FQDN, as in \\fileserver01.corp.example.com\share, to remove the dependency on the single-label-name path.

Some cautions remain even with FQDNs, though. An FQDN without a trailing dot is also tried with suffixes if the policy that appends suffixes to multi-label names is enabled. A name ending in .local may use mDNS alongside DNS. The form that pins the name unconditionally is the absolute name with a trailing dot. The premise for treating “an FQDN is pinned to DNS” as true in practice is that the policy above is disabled and that the internal domain name does not use .local.

6. The Transport to the DNS Server — DoH Does Not Change the Order

6.1 DoH on Windows 11 / Windows Server 2022

Windows DoH is a feature that sends queries to the DNS server over HTTPS. It is integrated with the existing hosts, cache, and NRPT, and with per-adapter and per-profile resolver settings; it does not replace the order described in Chapters 3 and 4.⁹

The Windows 11 DNS client supports DoH, and newer versions also support DoT (DNS over TLS). Microsoft’s description, however, does not state which versions support DoT, so it is not guaranteed to be available on every environment this article assumes. The following covers DoH.⁹

First, Check the List of Known DoH Servers

Unless DDR is enabled, only servers in the list of known DoH servers can be used. The default list contains Cloudflare, Google, and Quad9, and it can be checked with Get-DnsClientDohServerAddress. For an internal DNS server and the like, register a DoH template together with the fallback and auto-upgrade settings.¹³⁴

# The list of known DoH servers
Get-DnsClientDohServerAddress

# Register the internal DNS server as a DoH server (no plaintext fallback, with auto-upgrade)
Add-DnsClientDohServerAddress -ServerAddress '10.0.1.2' `
    -DohTemplate 'https://dns.corp.example.com/dns-query' `
    -AllowFallbackToUdp $false -AutoUpgrade $true

Registration is also possible with netsh dnsclient add encryption. The global netsh dnsclient set global doh=yes|no|auto is a setting separate from the per-server autoupgrade.³⁵

auto alone does not prohibit falling back to plaintext. Whether to fall back to UDP on failure is decided separately by the per-server udpfallback, or -AllowFallbackToUdp in PowerShell. To restrict resolution to encrypted transport only, disable the fallback as well.³⁵

With DDR Enabled, There Is a Dynamic Discovery Path Too

On versions that support DDR (Discovery of Designated Resolvers), a resolver configured in plaintext can advertise its encrypted DNS endpoints. Because the connection can be upgraded to encryption without a registration in the static list, you cannot say “it is not in the list, so it is not DoH”.³⁵

For DDR to work, both the global netsh dnsclient set global ddr=yes and the per-adapter set interface <name> ddr=yes are required. Whether to fall back to plaintext when encrypted resolution obtained through DDR fails is decided by ddrfallback, which is disabled by default.

In an investigation, besides the known list, check netsh dnsclient show global and netsh dnsclient show state, and the values set with set interface on adapters that have DNS servers. The show subcommands defined in the documentation are encryption, global, and state; there is no adapter-specific show subcommand.³⁵

Separate “Allow”, “Require”, and Falling Back to Plaintext

In the Settings app, set the DNS settings to manual; “Preferred DNS encryption” can be chosen only when the preferred DNS server is in the known list. There are three options.¹

The Group Policy setting “Configure DNS over HTTPS (DoH) name resolution” has Allow, Prohibit, and Require. With Allow, DoH is used when, in addition to a registration in the known list, conditions such as auto-upgrade, the adapter’s encryption setting, or the global doh=auto are met. With “Require”, name resolution itself fails against servers that do not support DoH.¹³⁵

Do not apply “Require DoH” to domain-joined PCs. Microsoft warns about this explicitly. Active Directory Domain Services depends heavily on DNS, and the DNS Server service that ships with Windows Server does not support DoH queries.¹

In a Capture, Read the Settings and the Actual Traffic Separately

Queries actually sent over DoH go inside TLS on port 443 rather than UDP 53. Even with “Allow DoH”, however, queries to servers not in the known list, and fallbacks after an encryption failure, flow in plaintext. Having DoH configured does not make port 53 traffic disappear.

If no DNS queries are visible, check DoH and DoT (port 853) in addition to hosts and the cache. For how to capture, see the packet capture article.

6.2 DoH in the Browser Is Separate From the OS

Edge’s built-in DNS client and the change of query destination through Secure DNS are easier to understand when split into two stages.

The built-in client is controlled by BuiltInDnsClientEnabled, and DoH queries are always made by the built-in resolver.⁷ Secure DNS is disabled by default on organization-managed PCs and is configured with DnsOverHttpsMode (off / automatic / secure) and DnsOverHttpsTemplates.³⁶³⁷

An Edge that has a different provider chosen may resolve external sites but fail to resolve names known only to the internal DNS. Conversely, Edge alone may still open pages when the OS DNS is unhealthy. If it stays with the current provider, the query destination does not change.

The conclusion is: do not treat the browser’s success and the business app’s success as evidence about the same path. Check the OS path with Resolve-DnsName or ping.

7. Which Path Does the App Take?

Before choosing the tools for an investigation, align the path you are looking at.

The main switches of Resolve-DnsName, organized by investigation purpose, are as follows.⁸

7.1 A and AAAA: IPv6 Comes Back First

Even when name resolution succeeds, the address selection that follows can make the connection slow.

The DNS client queries both A (IPv4) and AAAA (IPv6). In a capture, too, both queries appear as a pair.³ After the answers come back, getaddrinfo and the connecting stack choose the address to use. Windows Vista and later use the RFC 3484 prefix table, and by default prefer IPv6 global unicast over IPv4.³⁸

However, an AAAA answer alone does not mean an IPv6 connection is always attempted. Destination selection first discards unusable destinations, such as those with no IPv6 source address or route, and then orders the candidates.³⁹

The problem arises in environments where an IPv6 source address and route appear to exist but do not actually work. Name resolution succeeds, yet time is lost on the connection. Whether IPv6 was really attempted is confirmed not from the DNS response alone but from connection logs or a capture.

Microsoft does not recommend disabling IPv6 as the remedy, because some Windows components stop working. Instead, it describes setting DisabledComponents to 0x20 to prefer IPv4 in the prefix policy.³⁸ The case where localhost resolves to ::1 and conflicts with an investigation that assumed 127.0.0.1 is also covered in the packet capture article.

8. The Isolation Procedure — Peel the Layers Off From the Top

On the failing PC, run the following in order. Each command exists to restrict the path, and its success alone does not prove the path taken in everyday resolution. Combine the comparison of results with the capture at the end.

Step 1: Check the Shape of the Name

Check, in a log or a configuration file, the name the app actually passes. The path changes depending on whether it is a single-label name, ends in .local, or has a trailing dot. For a short name such as http://app01/, start from the completion in Section 4.1 and the per-PC differences in Section 5.4.

Step 2: Can It Be Resolved From the Cache and hosts Alone?

Resolve-DnsName -Name 'app01.corp.example.com' -CacheOnly
Get-DnsClientCache -Entry 'app01.corp.example.com'
Get-Content "$env:SystemRoot\System32\drivers\etc\hosts" | Select-String -Pattern 'app01'

-CacheOnly only restricts this lookup to the local cache. If a wrong answer was learned from the DNS server, the same value comes back after clearing. The fact that it was in the cache is not proof that the DNS server is unrelated.⁸

Step 3: Can It Be Resolved Through DNS Alone?

# Exclude hosts, send no LLMNR/NetBIOS, and query only the configured DNS servers
Resolve-DnsName -Name 'app01.corp.example.com' -NoHostsFile -DnsOnly

If Step 2 had no answer and this step merely succeeds, it is usually an ordinary cache miss. You can call it a cache or hosts problem only when Step 2 showed a stale answer, a wrong answer, or a negative cache entry.

If this step fails too, investigate the route to the DNS server, the server side, and the client-side policies. Before proceeding to Step 4, check the following.

• Get-DnsClientNrptPolicy -Effective: is there a rule that directs the name to a different DNS server?
• Get-DnsClientDohServerAddress and the DoH Group Policy: is “Require DoH” set against a server that does not support it?

If there is an NRPT, the target servers in Step 4 change. If “Require DoH” is the cause, only name resolution fails while the route and the server are both healthy. Finish the checks in Sections 4.4 and 6.1 first.

Step 4: Ask Each Server Directly

Collect the DNS servers of the connected adapters, and if an NRPT rule applies to the target name, replace them with the servers of that rule. Include DNS servers configured only for IPv6 as well.

$name = 'app01.corp.example.com'
# Collect the DNS servers of the connected interfaces from both IPv4 and IPv6.
# Servers left in the settings of a disconnected VPN or virtual switch are not part of the current resolution path, so exclude them (do not miss servers configured only for IPv6)
$connected = @((Get-NetIPInterface -ConnectionState Connected).ifIndex | Select-Object -Unique)
$servers = @((Get-DnsClientServerAddress |
    Where-Object { $_.ServerAddresses -and ($connected -contains $_.InterfaceIndex) }).ServerAddresses)
# The servers of the NRPT rule that applies to this name (written by Always On VPN or DirectAccess) do not appear in the adapter settings, so pick them from the effective policy.
# The -Namespace parameter of Get-DnsClientNrptPolicy only filters on the rule's Namespace attribute; it does not match against the name.
# So match the Any rule (.), suffix rules (leading dot; apply to the namespace itself and child domains), FQDN rules, and prefix rules (the host name part; wildcards such as web* are allowed) yourself,
# and adopt the more specific (longer) rule. The Any rule is the shortest, so it is chosen only when no other rule matches
# Namespace is a set of strings (displayed as Namespace : {.corp.example.com}), so expand the elements of each rule for matching and order by the length of the matched namespace
# For an absolute name with a trailing dot (app01.corp.example.com.), strip the dot only for matching. Pass the original $name to Resolve-DnsName
$matchName = $name.TrimEnd('.')
$label = $matchName.Split('.')[0]
$matched = foreach ($policy in @(Get-DnsClientNrptPolicy -Effective)) {
    foreach ($ns in @($policy.Namespace)) {
        if (-not $ns) { continue }
        $hit = if ($ns -eq '.') { $true }
               elseif ($ns.StartsWith('.')) { $matchName.Equals($ns.TrimStart('.'), [System.StringComparison]::OrdinalIgnoreCase) -or $matchName.EndsWith($ns, [System.StringComparison]::OrdinalIgnoreCase) }
               elseif ($ns.Contains('.')) { $matchName.Equals($ns, [System.StringComparison]::OrdinalIgnoreCase) }
               else { $label -like $ns }
        if ($hit) { [pscustomobject]@{ Namespace = $ns; Policy = $policy } }
    }
}
$rule = $matched | Sort-Object { $_.Namespace.Length } -Descending | Select-Object -First 1
$policyServers = @()
if ($rule) { $policyServers = @(@($rule.Policy.NameServers) + @($rule.Policy.DirectAccessDnsServers) | Where-Object { $_ }) }
if ($policyServers.Count -gt 0) {
    # If the NRPT specifies servers for this namespace, the query in Step 3 goes to those servers. The adapter's servers are outside the path, so replace them
    $servers = $policyServers
}
$servers = $servers | Where-Object { $_ } | Select-Object -Unique
foreach ($server in $servers) {
    $sw = [System.Diagnostics.Stopwatch]::StartNew()
    try {
        $r = Resolve-DnsName -Name $name -Server $server -DnsOnly -ErrorAction Stop
        $status = 'OK'
        # Multiple records can come back in a different order per response, so sort before comparing
        $answer = ($r.IPAddress | Sort-Object) -join ','
    } catch {
        # Negative responses (name does not exist), SERVFAIL, and timeouts land here. Keep the reason instead of discarding it
        $status = $_.Exception.Message
        $answer = ''
    }
    [pscustomobject]@{ Server = $server; Status = $status; Answer = $answer; Milliseconds = [int]$sw.ElapsedMilliseconds }
}

First, Line Up the Servers to Compare

The NRPT’s NameServers and DirectAccessDnsServers may not appear in the adapter’s DNS settings. If Step 3 asked the NRPT’s servers but Step 4 examines only the adapter’s servers, you end up comparing different paths.

The NRPT has rule types such as suffix, FQDN, prefix, and Any (.), and more specific rules take precedence.⁴⁰ -Namespace only filters on the rule’s attribute; it does not match against the host name. That is why the code above expands the namespaces of the rules and matches them against the target name.²³

On a split-DNS VPN, it is normal for the home-side resolver to return a negative response for an internal name while only the NRPT side returns a positive one. If you also compare servers outside the path, record them separately as a “control” and do not mix them into the judgment of zone mismatches. Timeouts against servers left on disconnected adapters are likewise separate from delays on the current resolution path.

Next, Read the Results Apart

If they differ as sets as well, check the zone contents and serial numbers. Also, this is a measurement with the destination pinned by -Server. The delay caused by list position, “4 seconds until the fourth and later servers are reached” from Section 4.2, is checked in Step 3 or in its capture.

Step 5: Check the Link-Local Layer

Resolve-DnsName -Name 'app01' -LlmnrOnly          # LLMNR only
Resolve-DnsName -Name 'app01' -LlmnrNetbiosOnly   # LLMNR or NetBIOS only (no DNS)
nbtstat -c                                        # NetBIOS name cache

This check targets single-label names. -NetbiosFallback falls back to NetBIOS only when DNS fails, so for a name that DNS can resolve it is not a NetBIOS check.⁸

Read the results as follows.

Which protocol answered is told apart in a capture by UDP 5355 (LLMNR) versus UDP 137 (NetBT). To confirm the everyday resolution path, also compare with the address returned by Resolve-DnsName without switches, and if they disagree, check the adopted response in the capture, because by default DNS is queried in parallel too.

Step 6: Diff the Settings Dumps

In an “only some PCs” investigation, run the same script on a working PC and a failing PC and compare.

# name-resolution-dump.ps1 -- run with administrator rights and compare the output files of the two machines side by side
$out = "$env:COMPUTERNAME-name-resolution.txt"
$sections = [ordered]@{
    'Get-DnsClientServerAddress' = { Get-DnsClientServerAddress | Format-Table -AutoSize | Out-String -Width 200 }
    'Get-DnsClientGlobalSetting' = { Get-DnsClientGlobalSetting | Format-List | Out-String }
    'Get-DnsClient'              = { Get-DnsClient | Format-Table InterfaceAlias, ConnectionSpecificSuffix, UseSuffixWhenRegistering -AutoSize | Out-String -Width 200 }
    'Get-DnsClientNrptPolicy'    = { Get-DnsClientNrptPolicy -Effective | Format-List | Out-String }
    'Get-DnsClientDohServerAddress' = { Get-DnsClientDohServerAddress | Format-Table -AutoSize | Out-String -Width 200 }
    'netsh dnsclient show state' = { netsh dnsclient show state 2>&1 | Out-String }
    'Get-NetIPInterface'         = { Get-NetIPInterface | Sort-Object AddressFamily, InterfaceMetric | Format-Table InterfaceAlias, AddressFamily, InterfaceMetric, ConnectionState, Dhcp -AutoSize | Out-String -Width 200 }
    'DNSClient policy registry'  = { Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient' -ErrorAction SilentlyContinue | Format-List | Out-String }
    'ipconfig /all'              = { ipconfig /all | Out-String }
}
$sections.GetEnumerator() | ForEach-Object {
    "===== $($_.Key) ====="
    try { & $_.Value } catch { "ERROR: $($_.Exception.Message)" }  # Leave missing items (such as DoH on Windows 10) recorded as errors
} | Set-Content -Path $out -Encoding UTF8
Write-Host "wrote $out"

What to compare are the order of DNS servers, the search list, connection-specific suffixes, the NRPT, DoH, interface metrics, and policy values.

HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient holds EnableMulticast for “Turn off multicast name resolution”, DisableSmartNameResolution for “Turn off smart multi-homed name resolution”, the search list, the primary suffix, and so on.⁴ Check the diff against the workings of each layer organized so far.

Step 7: Back It Up With a Packet Capture

Microsoft’s data collection procedure starts netsh trace start capture=yes on both the client and the server, discards the cache with ipconfig /flushdns, reproduces the problem, and stops with netsh trace stop.⁴¹

In Wireshark, filter with dns.qry.name == "app01.corp.example.com" or dns.qry.name contains "app01" to see which server was asked what, and what came back.

If the sending side’s firewall blocks UDP 53, Resolve-DnsName times out and no DNS query appears in the capture either. Isolate not only the case where name resolution succeeds and no traffic goes out, but also the case where it fails and no traffic goes out.³

Beyond DNS, check 5355 for LLMNR, UDP 5353 for mDNS, and UDP 137 for the NetBT name service. DoH is 443 and DoT is 853. How to capture and read captures is collected in the packet capture article.

9. Design on the Business App Side — Making It Robust Against Name Resolution

To make investigations lighter, it matters that the app side can record “which name, resolved to what, and where it failed”. Matching the app’s log against the settings dumps and captures that IT staff collect makes it easier to decide where in Chapter 8 to start.

Hold Destinations as FQDNs and Do Not Depend on hosts

Make the defaults in configuration files, shortcuts, and UNC paths FQDNs. This removes the dependency on suffix completion of single-label names and on LLMNR and NetBT. The cautions from Section 5.4, however, remain: mDNS alongside DNS for .local names, and the policy that appends suffixes to names without a trailing dot.

hosts is convenient for a temporary override during development, but it requires administrator rights and manual work. Distribution and change history are hard to manage, and some resolvers do not consult it at all (nslookup does not¹²). Switch destinations through configuration files.

Record the Result, Time, and Failure Reason of Name Resolution

At startup and similar points, record the IPv4 and IPv6 addresses and the elapsed time for the main destinations. Because Dns.GetHostAddresses returns the same result as getaddrinfo, you can trace “on which PC, since when, what it was resolved to”.¹¹

// Record the name resolution results of the main destinations at startup (.NET 6 or later)
static async Task LogNameResolutionAsync(ILogger logger, string host)
{
    var sw = System.Diagnostics.Stopwatch.StartNew();
    try
    {
        var addresses = await System.Net.Dns.GetHostAddressesAsync(host);
        logger.LogInformation("Name resolution {Host} -> {Addresses} ({Elapsed} ms)",
            host, string.Join(",", addresses.Select(a => a.ToString())), sw.ElapsedMilliseconds);
    }
    catch (System.Net.Sockets.SocketException ex)
    {
        logger.LogError(ex, "Name resolution failed {Host} error {Code} ({Elapsed} ms)",
            host, ex.SocketErrorCode, sw.ElapsedMilliseconds);
        throw;
    }
}

Log failures and rethrow. Silently switching to a different name or a fixed IP makes the actual path unknowable during an investigation. With the error code and the elapsed time, IT staff can decide where in Steps 2 to 4 to begin.

Allow for Timeouts and IPv6 Answers

The DNS client spends up to 10 seconds per candidate queried against unresponsive servers.²¹ If suffix search produces several candidates, the total can exceed 10 seconds.

If the connection timeout is squeezed to 2 or 3 seconds, name resolution does not finish before the deadline in configurations such as one where the server that can answer is fourth or later. The second server, however, is queried after 1 second and the third after 2 seconds, so a single failed server does not necessarily mean failure. Design with the retransmission timing in Section 4.2 in mind.

Also, when an AAAA answer comes back and an IPv6 source address and route exist, Windows prefers IPv6 by default.³⁸ Connection code that assumes IPv4 only may fail to connect even though name resolution succeeded. Separate the success of name resolution from the success of the connection, and handle both kinds of address.

10. Summary

The first things to separate in Windows name resolution are the shape of the name, the layer that returns the answer, and the path the app takes.

The cache and hosts answer first, and for single-label names DNS and LLMNR/NetBT run in parallel by default. For .local, mDNS joins in. Once resolution moves on to DNS, suffixes, retransmission timing, multiple NICs, and the NRPT change the result. DoH is a feature that switches that transport, and it is considered separately from the browser’s built-in resolver.

The investigation restricts the path in the order -CacheOnly, then -NoHostsFile -DnsOnly, then -Server, then -LlmnrOnly, and confirms with a settings diff and a capture. What matters is not to overlook the negative cache, the difference between no response and a negative response, and the client-side policies.

When “only this PC cannot connect”, first check these two things.

In what shape is the name being passed? On that PC, which path is answering?

With these two established, you can narrow down where to look.

Related Articles

• Packet Capture on Windows in Practice — Choosing Among pktmon, netsh trace, and Wireshark
• Corporate Proxies and Windows Apps — Sorting Out Proxy Resolution in WinINET, WinHTTP, and .NET
• Don’t Wrap HttpClient in a using Block — Practical HTTP Communication in C# Business Apps (Creation Patterns, Timeouts, Retries)
• The Windows Firewall and Business Applications — Register Inbound Rules From the Installer
• Pitfalls of Network Drives and UNC Paths — Working With File Servers (Shared Folders) From a Business Application
• NTLM and Kerberos Explained with Diagrams — Why Authentication Falls Back to NTLM
• Practical PowerShell Command Recipes — Growing the Small Tools You Use Every Day

Related Consulting Areas

KomuraSoft LLC handles root-cause investigations of name-resolution-related communication trouble such as “the business app cannot reach the internal server on only some PCs” and “it opens in the browser but the app fails at name resolution”, design reviews of whether a business app can withstand environment changes such as disabling LLMNR, DoH, and VPN, and implementation of a communication layer that records name resolution results and timeouts. If you attach settings dumps from a working PC and a failing PC when you contact us, the starting point of the investigation is settled quickly.

• Bug Investigation & Root-Cause Analysis
• Technical Consulting & Design Review
• Windows Application Development
• Contact Us

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

I edited the hosts file but the change does not take effect. Why?

On Windows, the contents of the hosts file are loaded into the cache when the DNS Client service starts, and name resolution proceeds in the order cache, hosts, DNS server. When a change does not take effect, first check the entry for that name with ipconfig /displaydns, and if an old answer is still there, discard it with ipconfig /flushdns. Next, question whether the tool you are testing with goes through the Windows resolver at all. nslookup does not use the OS resolver; it bypasses the cache, hosts, and the NRPT and queries the DNS server directly, so nothing in hosts is reflected in its output. To see the actual resolution result including hosts, use Resolve-DnsName or ping. If it still does not take effect, check whether the app, like a browser, has its own resolver or DoH.

The site opens in the browser, but only the business app fails at name resolution.

Most likely the browser and the app resolve the name over different paths. By default Microsoft Edge talks to the DNS server with its built-in DNS client rather than the OS DNS client, and if a different provider is chosen under Secure DNS (DoH), it queries an external resolver. On the other hand, .NET's Dns.GetHostAddresses, and an HttpClient that connects directly to the destination, go through the OS getaddrinfo, so they are subject to hosts, the DNS cache, the NRPT, and the DNS suffix search list (for requests that go through an HTTP proxy, the destination name is resolved on the proxy side). When the two return different answers, the fastest route is to match up which path asked which DNS server what, using Resolve-DnsName and a packet capture.

The settings should be identical, yet only some PCs cannot reach the internal server. What should I compare?

Compare the shape of the name and the layer at which each PC gets its answer. A single-label name (a name without a dot, such as server01) is completed with the PC's DNS suffix search list or the connection-specific suffix and sent to DNS, and by default it is also sent, in parallel, to same-subnet-only mechanisms such as LLMNR and NetBIOS broadcast (they are tried in sequence after DNS fails only when the optimization has been disabled; if WINS is configured, NetBIOS uses unicast and can cross subnets). A domain-joined PC may resolve the name because the suffix completes it to an FQDN, while a PC on VPN or on another subnet, or a PC with LLMNR and NetBIOS disabled, cannot resolve the same name. The reliable method is to collect the output of Get-DnsClientServerAddress, Get-DnsClientGlobalSetting, Get-DnsClient, and Get-DnsClientNrptPolicy -Effective on both a working PC and a failing PC and diff them. The root fix is to make the destinations in configuration files and shortcuts FQDNs.

Name resolution does not fail; it just takes several seconds before the connection finally goes through. What causes this?

This is the DNS client's timeout and retry mechanism showing through. Against a DNS server that does not respond, Windows retransmits at 1, 2, 4, and 8 seconds from the start and gives up at 10 seconds. Even with several DNS servers configured, if the one that responds is fourth or later in the list, Windows waits at least 4 seconds before it queries that server. A long DNS suffix search list also stacks up delay, because a single-label name is tried with each suffix in turn. Measure how long Resolve-DnsName takes with Measure-Command, and apply a dns.qry.name filter in Wireshark to see which server's queries go unanswered.

We disabled LLMNR and NetBIOS as a security measure, and now some devices can no longer be reached by name.

That is an expected side effect. LLMNR and NetBIOS over TCP/IP are secondary means of resolving the single-label names of devices that are not registered in DNS within the same subnet, and disabling them removes that path. Microsoft itself announced in 2022 a direction of aligning on mDNS and gradually ramping down NetBIOS name resolution and LLMNR, so the decision to disable them is itself the right one. The remedy is to consolidate name resolution on DNS: register the devices' A records in the internal DNS, or enable dynamic registration through DHCP, and rewrite the destinations of apps and shares to FQDNs. Devices that support mDNS can be resolved by their .local names, but that path, too, is limited to the range that multicast reaches.

What happens to internal name resolution when I enable DoH (DNS over HTTPS) on Windows 11?

DoH is a feature that switches the transport to HTTPS when the DNS client queries the configured DNS servers; the existing order of hosts, cache, and NRPT stays as it is. Unless DDR (Discovery of Designated Resolvers) is enabled, DoH can be used only when the server is in the list of known DoH servers, so if you want to use an internal DNS server, an administrator must register it with Add-DnsClientDohServerAddress. If the Group Policy setting "Configure DNS over HTTPS (DoH) name resolution" is set to "Require DoH", name resolution itself fails against servers that do not support DoH. Microsoft explicitly says not to enable this setting on domain-joined PCs, because the DNS Server service that ships with Windows Server, on which Active Directory depends, does not support DoH queries.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.