Why does a Linux application resolve a hostname differently from dig?
Many Linux applications use the operating system’s name-service configuration, which can consult local hosts entries and other sources before DNS. The dig command asks DNS directly. A successful dig answer therefore does not prove that an application on the same server will select the same address.
Before you start
- The exact hostname used by the affected application.
- The getent command and, for comparison, dig from the distribution’s DNS tools package.
Instructions
1. Check the application-facing result
Use the full hostname to avoid an unexpected search-domain suffix. The same address may appear more than once because getent reports different socket types.
getent ahosts app.example.comQueries the configured name-service stack rather than bypassing it for a direct DNS lookup.
2. Compare direct DNS
Check A and AAAA independently. Substitute a hostname you own or are authorised to diagnose. An empty AAAA answer can be normal for an IPv4-only service.
dig app.example.com A +short
dig app.example.com AAAA +shortLists returned IPv4 and IPv6 DNS records using the configured resolver.
3. Inspect local resolution policy
Look for a specific local override and the order of hosts sources. Do not publish the whole hosts file if it contains private infrastructure names.
grep '^hosts:' /etc/nsswitch.conf
grep -nF 'app.example.com' /etc/hostsDisplays the hosts lookup policy and matching local host-file lines.
Check the result
- The application and DNS answers match the intended environment, or the documented split-DNS/local override explains the difference.
Troubleshooting
- Only the application still uses an old address
- Check application or runtime caching and whether it runs in a container with its own resolver configuration. Repeatedly editing global DNS settings will not repair an application-specific cache.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.