glibc resolver: DNS resolution latency with high ndots values

Search Domain Appending Behavior

In Linux environments using the glibc resolver, the ndots configuration in /etc/resolv.conf defines the minimum number of dots a name must contain to be considered an absolute domain name. When a query name contains fewer dots than the ndots threshold, the resolver attempts to append the configured search domains before attempting the query as a fully qualified domain name (FQDN).

Configuration Uncertainty

For workloads requiring both the resolution of short-name internal services and frequent access to public APIs, setting a high ndots value (e.g., 5) can lead to a surge in DNS query volume. This occurs because the resolver may cycle through multiple search domain suffixes, generating several NXDOMAIN responses before finally attempting the absolute query.

It is unclear how to minimize this resolution latency for public domains without reducing the ndots value and potentially breaking the resolution of internal short-names.

• Does glibc provide a mechanism to bypass search domain appending for specific patterns without modifying the global ndots value?
• How does the resolver handle the priority between the search list and the absolute query when the target is a public FQDN but the dot count is below the ndots threshold?