Client side DNS

Which source answers, and in what order

/etc/nsswitch.conf lists, for each database, the sources to consult and the order to consult them in. The line that matters here is the hosts one, whose usual sources are files — meaning /etc/hosts — and dns, with resolve appearing as well on a machine running systemd-resolved. The list is scanned left to right and the FIRST source that returns a match ends the scan. That is the whole mechanism, and it is the answer to the commonest complaint on this objective: with hosts: dns files, a name that exists in public DNS is answered before /etc/hosts is ever opened, so the local override does nothing. Reversing it to hosts: files dns is what makes local overrides work. /etc/host.conf is the older ordering file for programs that do not use the switch, and it holds no host entries of its own.

/etc/hosts itself is a flat table: an address, then the canonical host name, then any number of aliases, separated by whitespace, one entry per line. The address may be of either family, so a standard file carries both 127.0.0.1 localhost and ::1 localhost ip6-localhost. A comment runs from a # to the end of the line — the semicolon convention belongs to DNS zone files and not to this one. The file is read on demand during a lookup, so an edit applies to the next resolution with nothing to restart; a caching layer such as nscd or systemd-resolved may still be holding an older answer, but the file needs no reload for its own sake.

The servers, and how long the resolver waits for them

/etc/resolv.conf is where the DNS half is configured. Each nameserver line names one server by address, and they are tried in the order listed. The ceiling is worth knowing exactly: the glibc resolver compiles in a limit of three, so a fourth and fifth line are parsed and then silently disregarded. Listing five servers for redundancy does not give redundancy, and genuine failover belongs in a local caching resolver rather than in this file. The search line gives a list of domains used to complete UNQUALIFIED names, and domain is the older single-entry form of the same idea; neither has any bearing on which server is asked.

An options line tunes the waiting. options timeout:1 sets how many seconds the resolver waits on ONE server before giving up on that try, and the default of five is why a single dead first entry stalls every lookup for five seconds. options attempts:2 sets how many passes are made over the whole server list, which is a different number: lowering it reduces how OFTEN the wait is paid rather than how long each one is. Both are capped internally, timeout at thirty and attempts at five. options rotate round-robins over the servers between queries to spread load, which still starts some queries on the dead one, and options ndots:1 decides how many dots a name must contain before it is tried as absolute instead of being run through the search list. None of them is the real fix for an unreachable server, which is to take it out of the file.

The clients, and which layer each one proves

dig, host and nslookup are DNS clients: each builds a DNS query and sends it to a name server, reading /etc/resolv.conf only to find out which server to ask. None of them consults /etc/nsswitch.conf or /etc/hosts. An argument beginning with @ overrides even that — dig @192.0.2.53 db01.example.com sends the query to that one server, which is exactly what is wanted when testing a server the client is not yet configured to use. Keep it apart from the options that change what is ASKED rather than who is asked: -x makes it a reverse lookup, +trace walks the delegation down from the root servers, +nssearch finds the zone's authoritative servers, and +short merely trims the output.

The record type is given differently by each tool, and both spellings are examinable. dig takes it as a bare trailing argument, as in dig example.com MX. host takes it as an option: host -t MX example.com asks for that type alone, where host with no -t asks for A, AAAA and MX records and prints whatever comes back. Type names are matched without regard to case. dig -x 192.0.2.25 builds the reverse name for you — 25.2.0.192.in-addr.arpa — and sets the type to PTR; an IPv6 address would need nibble-reversed labels under ip6.arpa instead. A missing PTR is a server-side omission rather than a client fault, because forward and reverse zones are separate and one does not imply the other.

getent is the one that answers the other question. It takes a database name and a key and resolves the key through the switch, exactly as an application's library call does, so getent hosts licence.example.com shows the answer /etc/hosts or any other configured source supplies. That is the command for a name that works for every program on the machine while dig returns NXDOMAIN: more debug output from a DNS client cannot reveal a non-DNS source, and getent can. The database chosen also decides the address family. hosts returns one family, the IPv6 answer where there is one; ahostsv4 pins IPv4 and ahostsv6 pins IPv6; getent ahosts www.example.com leaves the family unspecified, so both come back with the socket type for each, which is the view to take before switching a service to dual-stack.

$ dig licence.example.com;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41822# DNS has never heard of it$ getent hosts licence.example.com10.0.0.9        licence.example.com# so the answer is coming from /etc/hosts$ host -t MX example.comexample.com mail is handled by 10 mx1.example.com.

systemd-resolved, and the stub on 127.0.0.53

On a host running systemd-resolved, /etc/resolv.conf is a symbolic link into /run — to /run/systemd/resolve/stub-resolv.conf — and contains one entry, nameserver 127.0.0.53. That address is a stub listener the daemon runs on the loopback interface, so every application on the machine sends its queries to the local stub and resolved does the real work. Hand-edited nameserver lines vanish because the file is GENERATED: resolved rewrites it, and there was never anything there to keep.

The upstream servers are set in DNS= in /etc/systemd/resolved.conf, or in a drop-in under /etc/systemd/resolved.conf.d/, with FallbackDNS= behind it, and the daemon is restarted to read them; per-link servers arriving from DHCP through networkd or NetworkManager are added to those. resolvectl dns eth0 192.0.2.1 does set the servers for one link, but only in the RUNNING daemon — it writes nothing to disk, so the setting is gone at the next restart, which is the distinction a question here is built on. resolvectl status prints which servers are actually in force, per link, and is the quickest way to see what the stub is really asking.