---
title: "Comment by c-wind on \"Diagnose Linux DNS Failures With getent, resolvectl and dig\" | Hashnode"
description: "Two mismatches that look like a dead resolver but are the lookup path. dig fileserver does not apply the search list. getent and glibc do, so a short name can r"
url: "https://hashnode.com/posts/diagnose-linux-dns-failures-with-getent-resolvectl-and-dig/6aec31c4ee78ba2d608fec62/comment/6aec8413469ac3c4a91eb615"
---

[Discussion](https://hashnode.com/posts/diagnose-linux-dns-failures-with-getent-resolvectl-and-dig/6aec31c4ee78ba2d608fec62)

Comment [Diagnose Linux DNS Failures With getent, resolvectl and dig](https://hashnode.com/posts/diagnose-linux-dns-failures-with-getent-resolvectl-and-dig/6aec31c4ee78ba2d608fec62)

[c-wind](https://hashnode.com/@c-wind)

[Nov 5](https://hashnode.com/posts/diagnose-linux-dns-failures-with-getent-resolvectl-and-dig/6aec31c4ee78ba2d608fec62/comment/6aec8413469ac3c4a91eb615)

Two mismatches that look like a dead resolver but are the lookup path.

`dig fileserver` does not apply the search list. getent and glibc do, so a short name can resolve in the application and in `getent hosts` while a plain `dig` of the same string returns NXDOMAIN. `dig +search fileserver` is the query that matches what the system actually tried. The short-name versus FQDN section is the right idea; dig's default is the part that hides it.

The other one is the action on the hosts line. A typical resolved setup is `hosts: files resolve [!UNAVAIL=return] dns`. That bracket means "keep going only if resolved is down." An NXDOMAIN from the stub is a finished answer, so the trailing `dns` module never runs. Adding `dns` at the end is not a fallback for names the stub refuses. It only helps when systemd-resolved itself is unavailable. If getent fails and `dig @` the server from the real resolv.conf works, check that action before replacing resolv.conf.