Fix DNS_STATUS_DOTTED_NAME (0X00002556) in Windows DNS

Cause 1: Application Sending a Dotted Name to a Flat-Name Resolver

What's actually happening here is that your application is calling DnsQuery or getaddrinfo with a name like server.internal.company.com — that's a multilabel (dotted) name. The Windows DNS resolver, by default, treats a query as a flat (single-label) name if the application doesn't explicitly set the DNS_QUERY_BYPASS_CACHE or DNS_QUERY_TREAT_AS_FQDN flags. If the resolver is configured to only handle single-label names (like a NetBIOS name or a hostname without dots), it returns DNS_STATUS_DOTTED_NAME to tell the caller: I can't resolve this because it has dots and you didn't tell me to treat it as a fully qualified domain name.

The fix is straightforward: In your code, when calling DnsQuery, add the DNS_QUERY_TREAT_AS_FQDN flag. That tells the resolver, "Yes, this name is already fully qualified — resolve it as-is." Here's a C++ example:

DNS_STATUS status = DnsQuery(
    L"server.internal.company.com",
    DNS_TYPE_A,
    DNS_QUERY_TREAT_AS_FQDN,
    NULL,
    &ppQueryResultsSet,
    NULL
);

If you're using .NET's System.Net.Dns class, you don't get this flag directly — the underlying Win32 API call handles it differently. In that case, append a trailing dot to the hostname: "server.internal.company.com.". That trailing dot is the standard DNS notation for an absolute (FQDN) name. When the resolver sees a trailing dot, it skips the suffix appending logic and treats the name as fully qualified.

Real-world scenario: A network monitoring tool I worked on kept failing to resolve monitor.corp.contoso.com on Windows Server 2019. Adding the trailing dot to the hostname string in the config file fixed it instantly — no reboot needed.

If you can't change the application code (e.g., you're using a third-party tool), move to Cause 2 — you can sometimes work around this by adjusting the DNS suffix list.

Cause 2: Misconfigured DNS Suffix Search List

Windows can append DNS suffixes from its search list to a single-label name. But when you query a name that already has dots, the resolver may try to append another suffix, producing a name like server.internal.company.com.corp.domain.com. That fails, and the resolver returns DNS_STATUS_DOTTED_NAME because the original name already had dots and the suffix append produced an invalid query.

This often happens when your network adapter's DNS settings include a primary DNS suffix (e.g., corp.domain.com) and you're querying a name like printserver.internal. The resolver sees the dot in .internal, decides it's a dotted name, but then tries to suffix-append and breaks.

The fix: Check your DNS suffix configuration. Open Control Panel > Network and Sharing Center > Change adapter settings. Right-click your adapter, select Properties, then Internet Protocol Version 4 (TCP/IPv4) > Properties > Advanced > DNS tab.

Look at two things:

1. Append primary and connection specific DNS suffixes — if this is checked, the resolver appends the primary suffix to queries. Uncheck it if you're getting errors with multilabel names.
2. Append these DNS suffixes (in order) — if you have suffixes listed, remove any that are causing the duplicate suffix issue. You can also add a single trailing dot to the list (yes, that works) to force FQDN behavior.

If you need to keep a suffix list (e.g., for corporate AD resolution), reorder them so the most specific suffix is first. The resolver stops appending if the name matches a suffix in the list. This reduces the chance of hitting DNS_STATUS_DOTTED_NAME.

Another approach: set the registry key HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\SearchList to a single trailing dot (.). That effectively disables suffix appending entirely. This is a blunt instrument — use it only if you can't fix the app or the network adapter settings.

Real-world scenario: A colleague's laptop couldn't resolve gitlab.internal.company.io after joining a new domain. The primary DNS suffix was ad.company.com, and the resolver was appending that to all queries. Removing the primary suffix from the adapter's DNS tab fixed it.

Cause 3: Using an Incorrect DNS Query Type (e.g., PTR with a Hostname)

This one is less common but bites developers who mix up query types. The error DNS_STATUS_DOTTED_NAME can also appear if you send a PTR (pointer) query with a hostname instead of a reverse IP address. PTR queries expect an IP address in reverse notation (e.g., 1.0.168.192.in-addr.arpa). If you pass a name like server.internal.company.com, the resolver returns this error because the name is dotted (multilabel) but the resolver expects a single label (the reverse IP).

The fix: Validate your query type. If you're doing a reverse lookup, convert the IP address to the proper PTR format. Here's a PowerShell snippet that shows the right way:

$ip = "192.168.0.1"
$reverse = ($ip.Split('.')[-1..0] -join '.') + '.in-addr.arpa'
Resolve-DnsName -Name $reverse -Type PTR

If you're using the Windows DNS API directly, the DnsQuery function expects the pszName parameter to be the exact name for the query type. For PTR, that means the reverse IP as a hostname. For A or AAAA, it's the hostname. Mixing them up triggers the error.

Similarly, if you're querying SRV records, the name must be in the format _service._protocol.domain.com. That's a dotted name, but it's valid — the resolver won't return DNS_STATUS_DOTTED_NAME for that if you also set DNS_QUERY_TREAT_AS_FQDN. The error only fires when the resolver can't determine how to handle the dotted name based on the query type and flags.

Real-world scenario: A custom logging tool I built tried to do a reverse DNS lookup on a hostname instead of an IP. The logs showed DNS_STATUS_DOTTED_NAME every minute. Changing the query from PTR to A and using the hostname directly fixed it.

Quick-Reference Summary Table