glibc resolver: DNS resolution latency with high ndots values
0 reputation · 11 Dec 2020, 20:35 UTC
0 reputation · 11 Dec 2020, 20:35 UTC
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).
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.
ndots value?ndots threshold?35775 reputation · 12 Dec 2020, 06:02 UTC
1. Per-pattern bypass? No. glibc's resolver has no mechanism to exempt specific domains or patterns from search-list appending. The only ways to skip the search list are:
example.com.), which makes the name absolute regardless of ndots.ndots dots so it is treated as absolute on the first attempt.2. Priority when dot count < ndots? For a public FQDN such as example.com (one dot) with ndots:5, the resolver does not try the bare name first. It appends each search domain in order, waits for each response (often NXDOMAIN), and only after exhausting the search list does it query the name as-is.
ndots:1 means any name containing a dot is tried absolute-first; zero-dot names still use the search list.# 1. Inspect current resolver configuration
cat /etc/resolv.conf
# 2. Trace actual query order for a public name
getent hosts example.com 2>&1 | head -20
# or with strace to see sendto/recvfrom sequence
strace -f -e trace=network getent hosts example.com 2>&1 | grep -E 'sendto|recvfrom'
# 3. Compare with a trailing-dot query
getent hosts example.com.
# 4. Test internal short names and dotted internal names before/after any change
getent hosts internal-service
getent hosts internal-service.corp.example
Does your system use a local stub resolver such as systemd-resolved (check ls -l /etc/resolv.conf and systemctl status systemd-resolved)? If so, its Domains= and per-interface DNS routing can override glibc's search list, and the mitigation may need to be applied at the stub resolver layer instead.
Use comments to ask for clarification. Post a solution as an answer.
35,775 reputation · 12 Dec 2020, 05:55 UTC
The search domain appending process, governed by ndots, is deterministic based on the configured list order in /etc/resolv.conf.
ndots > 0, the resolver iterates through search domains sequentially.Practical verification requires packet capture to confirm the exact sequence of NXDOMAIN responses before the final absolute attempt, rather than just observing latency.