Hostname Resolution Time
Estimate hostname resolution latency across DNS, /etc/hosts and cache lookup layers.
Inputs
Avg Resolution Time (ms)
3.800
Best Case — Cache Hit (ms)
0.050
Worst Case — Cache Miss (ms)
25.050
Typical nsswitch.conf Lookup Order
files → dns (default /etc/nsswitch.conf 'hosts:' line; mdns/resolve may also appear depending on distro)
Step by step
Values used
Cache Check Time (ms) = 0.0500; Cache Miss Rate % = 15; DNS Query Time on Miss (ms) = 25
Average resolution time
time = cache_check + (miss_rate × dns_query_time)
Avg Resolution Time (ms)
= 3.800
Best Case — Cache Hit (ms)
= 0.050
Worst Case — Cache Miss (ms)
= 25.050
Typical nsswitch.conf Lookup Order
= files → dns (default /etc/nsswitch.conf 'hosts:' line; mdns/resolve may also appear depending on distro)
How it works
Hostname resolution on Linux is governed by /etc/nsswitch.conf's 'hosts:' line, which typically checks local sources (files, i.e. /etc/hosts) before falling back to dns, with a local resolver cache (systemd-resolved, nscd) short-circuiting repeated lookups. Average resolution time is dominated by the (usually tiny) cache check cost most of the time, plus the full DNS round-trip cost only on the fraction of lookups that miss the cache — meaning even a fast cache with a high miss rate can leave average latency close to full DNS query time.
Formula
Average resolution time
time = cache_check + (miss_rate × dns_query_time)
- T_{cache}
- cache check time
- m
- cache miss rate (0-1)
- T_{dns}
- DNS query time on a miss
Frequently Asked Questions
How do I see the actual nsswitch.conf lookup order on my system?
`cat /etc/nsswitch.conf | grep ^hosts` shows the configured order (e.g. 'hosts: files dns'), meaning /etc/hosts is checked before falling back to DNS. Some distros insert `mdns4_minimal` or `resolve` (for systemd-resolved) into this chain.
How can I measure real-world hostname resolution time?
`time getent hosts <hostname>` measures a single resolution round-trip end-to-end through the full nsswitch chain; running it twice in a row highlights the cache-hit speedup versus the first (likely cache-miss) lookup.
Why would cache miss rate be high even with a resolver cache running?
A high miss rate typically means the workload queries a large number of distinct, rarely-repeated hostnames (common in microservice service-discovery churn or short-TTL cloud DNS records) faster than entries can be reused before expiring — increasing cache capacity doesn't help if the working set of names genuinely exceeds what gets repeated.