DNS resolver
medium on-server
What it inspects
/etc/resolv.conf for lines starting with `nameserver`, and `getent hosts deb.debian.org`. No nameserver lines fails; nameservers present but the test lookup failing warns; both fine passes. If resolv.conf cannot be read, the check is skipped. The test name is a fixed public name, so a network that blocks it can warn even when your own names resolve.
Why it matters
Almost everything a server does starts with a name lookup: package updates, certificate renewal, API calls, mail delivery. A missing or unreachable resolver fails quietly at first and then breaks those jobs at the worst moment, often showing up as a slow or hanging command.
How to verify
cat /etc/resolv.conf; getent hosts deb.debian.orgHow to fix
Judgement step: find out how the server gets its DNS settings, then fix it at that source (systemd-resolved stub link, NetworkManager, or your provider's servers).
Diagnose and fix the resolver configuration needs your judgement
Any distro
# Which fix is right depends on how this server gets its DNS settings, so look first:
# cat /etc/resolv.conf
# ls -l /etc/resolv.conf
# systemctl is-active systemd-resolved
# resolvectl status (shows the servers systemd-resolved really uses)
# getent hosts deb.debian.org (the exact lookup this check performs)
# 0 nameserver lines (FAIL):
# - systemd-resolved is active: point resolv.conf at its stub
# ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
# - NetworkManager manages DNS: set servers on the connection, for example
# nmcli connection modify <connection> ipv4.dns "<server1> <server2>" && nmcli connection up <connection>
# - otherwise use the DNS servers your provider or network documents; do not copy a resolver from the internet blindly.
# Nameservers present but the lookup fails (WARN): the servers are unreachable, or outbound DNS (UDP/TCP 53) is filtered,
# or the network blocks that particular name. Test one server directly:
# resolvectl query example.com (tests name resolution through systemd-resolved, not one specific server)
# dig @<server> example.com (tests that one server; dig comes from dnsutils on Debian/Ubuntu, bind-utils on the RHEL family)
# and review your outbound firewall rules.