The name an application asks the operating system to resolve is not always the name that gets queried in DNS. In many environments, the client modifies that name first by appending one or more search domains. This process is usually called suffix expansion or search domain expansion.
This behavior is a frequent source of confusion. Engineers expect a single DNS query and instead see multiple queries, unexpected fully qualified domain names, or traffic to internal domains that were never typed explicitly.
What is a search domain
A search domain is a DNS suffix that the operating system may append to a name that is not already fully qualified. Search domains are configured per interface or per resolver and are typically learned from DHCP, VPN configuration, or manual settings.
Common examples include corporate domains like corp.example, site-specific domains such as office.localdomain, or multiple domains provided in an ordered list.
The presence of search domains tells the client resolver how to turn a short name into one or more fully qualified domain names.
Fully qualified versus relative names
The distinction that drives suffix expansion is whether a name is treated as fully qualified.
A fully qualified domain name, or FQDN, explicitly ends at the DNS root. In textual form this is represented by a trailing dot, such as www.example.com.. Most applications omit the trailing dot, but many resolvers still treat names containing at least one dot as potentially complete.
A relative name is one that does not clearly indicate the DNS root. Examples include printer, db01, or service.internal.
Relative names are candidates for suffix expansion.
How suffix expansion works
When an application submits a relative name, the stub resolver applies a simple algorithm.
- Start with the name exactly as provided.
- Append each configured search domain in order.
- Send a DNS query for each resulting name until an answer is received or the list is exhausted.
For example, with a search domain list of corp.example and example.com, a lookup for fileserver may result in queries for fileserver.corp.example followed by fileserver.example.com.
Depending on the resolver implementation, some clients will then try the bare name fileserver as an absolute query. Other resolvers change the order based on ndots or platform-specific rules.
This sequence explains why packet captures often show multiple DNS queries for what appears to be a single lookup.
How to bypass suffix expansion
There are a few common ways to force literal name resolution when suffix expansion is not desired.
A trailing dot explicitly marks a name as fully qualified. For example, example.com. tells the resolver to treat the name as absolute and skip search domain expansion entirely.
Search domain expansion can also be disabled by configuring an empty search list. On Unix-like systems this typically means omitting search and domain directives in resolver configuration. Other platforms provide equivalent controls, though they are not always exposed in the same way.
Some diagnostic tools and libraries also provide flags or options to bypass search domains. These options are tool-specific and do not change system-wide resolver behavior.
These mechanisms are commonly used in testing, troubleshooting, and automation where predictable DNS queries matter.
ndots and when expansion is skipped
Many operating systems implement an ndots threshold. This setting controls how many dots must appear in a name before the resolver tries it as absolute first.
For example, with ndots:1:
printeris expanded using search domainsservice.internalis tried as absolute before expansion
With ndots:5, even names with several dots may still undergo suffix expansion first.
The ndots setting is well documented on Unix-like systems that use resolv.conf, but equivalent behavior exists on other platforms even when the knob is not exposed directly.
OS-specific behavior
Suffix expansion is not implemented identically everywhere.
Linux and Unix-like systems
Most Linux distributions and BSD variants follow resolv.conf semantics, but the exact behavior is implementation defined. Libraries such as glibc and musl differ in how strictly they apply search lists, ndots handling, and fallback ordering. Search domains, domain order, and ndots are explicit and observable. The behavior is generally predictable, though container runtimes and systemd-resolved can introduce additional layers.
Windows
Windows uses a DNS suffix search list derived from interface settings, Active Directory policy, and VPN configuration. The expansion order is well defined but less visible. Windows may also combine suffix expansion with other name resolution mechanisms such as LLMNR, and in older or legacy configurations, NetBIOS name resolution may also be attempted.
macOS
macOS maintains per interface resolver scopes. Search domains can apply only to specific interfaces, which means the same query can expand differently depending on network state. This behavior is powerful but difficult to reason about without inspecting the active resolver configuration.
git differently depending on which interface the resolver selects. On Wi‑Fi, git.corp.example is tried first. On the VPN, git.vpn.example takes precedence, even though the application issued the same lookup.
Why this behavior matters
Suffix expansion affects more than query volume. It increases DNS traffic, can leak internal naming patterns to external resolvers, changes which domains appear in logs and telemetry, and can introduce delays when early expanded queries time out.
Key takeaways
Applications do not always send fully qualified names to DNS. Stub resolvers often modify names using search domains, and the exact expansion behavior depends on OS-specific resolver logic. As a result, seemingly simple lookups can generate multiple DNS queries before any response is returned.
Suffix expansion is not a protocol feature of DNS itself. It is client-side behavior, implemented long before any packet reaches a recursive resolver. Understanding that distinction helps explain many real-world DNS surprises.