TTR Networks

Beginner · Linux Network Connectivity · section 8 of 11

DNS

✓ Lab-tested 17 October 2026 on Debian 12

Most "network problems" users report are really name resolution problems. On Linux, applications resolve names through the C library, which follows /etc/nsswitch.conf: usually /etc/hosts first, then DNS, using the resolvers in /etc/resolv.conf. On systemd-resolved systems that file points at a local stub (127.0.0.53), and resolvectl status shows the real upstream servers.

  • dig name queries DNS directly and shows everything: the status, flags, answer, TTL and which server replied.
  • dig +short name prints just the answer, which is handy in scripts.
  • dig @server name asks a specific server, to compare resolvers.
  • getent hosts name resolves exactly as applications do, /etc/hosts included. If dig works but getent doesn't (or vice versa), the problem is in local resolver configuration, not DNS itself.

Two statuses to recognise: NOERROR with an answer (good), and NXDOMAIN: the name doesn't exist. SERVFAIL means the resolver couldn't get an answer (upstream unreachable, DNSSEC failure); a timeout means the resolver itself didn't respond.

Resolving names (real output)
root@client:~# cat /etc/resolv.conf
nameserver 192.0.2.1
root@client:~# dig server.lab.example

; <<>> DiG 9.18.49-1~deb12u2-Debian <<>> server.lab.example
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42980
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;server.lab.example.		IN	A

;; ANSWER SECTION:
server.lab.example.	0	IN	A	198.51.100.20

;; Query time: 0 msec
;; SERVER: 192.0.2.1#53(192.0.2.1) (UDP)
;; WHEN: Fri Oct 16 18:27:37 UTC 2026
;; MSG SIZE  rcvd: 63

root@client:~# dig +short server.lab.example
198.51.100.20
root@client:~# dig nope.lab.example | grep status
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41449
root@client:~# getent hosts server.lab.example
198.51.100.20   server.lab.example
  • Lines 1–2: The resolver the C library will use: the router, running dnsmasq.
  • Line 8: status: NOERROR: the query succeeded.
  • Line 9: aa: an authoritative answer (dnsmasq owns lab.example). rd ra: recursion was requested and is available.
  • Line 17: The answer: name, TTL (0 here: don't cache), class, type and address.
  • Line 20: Which server actually answered. Check this when you suspect the wrong resolver.
  • Lines 26–27: NXDOMAIN: the name doesn't exist, which is a definite answer, not a failure to reach DNS.
  • Lines 28–29: Resolution the way applications do it, through nsswitch (including /etc/hosts).

Check your understanding

dig app.example.net returns the right address, but curl http://app.example.net connects to an old IP. What's the likely cause?

  • The DNS server is returning different answers at random
  • A stale entry in /etc/hosts, which applications check before DNS
  • curl doesn't use DNS
  • The TTL is too high