dig / host

# 1) dig — the surgical query tool
dig example.com                 # A record from default resolver
dig example.com AAAA            # IPv6
dig example.com MX              # mail servers
dig example.com TXT             # TXT records (SPF, verification, etc.)
dig example.com NS              # authoritative name servers
dig example.com ANY             # everything (often blocked nowadays)

# Query a specific resolver (bypass system)
dig @1.1.1.1 example.com
dig @8.8.8.8 example.com AAAA

# Short / brief output
dig +short example.com
dig +short MX example.com

# Trace the full delegation from the root
dig +trace example.com

# Query the AUTHORITATIVE answer (skip caches)
dig +trace +nodnssec example.com

# Reverse DNS
dig -x 1.1.1.1                  # PTR record
dig -x 203.0.113.5 +short

# ===== 2) getent hosts — what the SYSTEM RESOLVER would do
getent hosts example.com        # uses nsswitch.conf order (files, dns, etc.)
getent ahosts example.com       # full info including AAAA

# Difference matters: dig hits DNS only. getent honours /etc/hosts overrides,
# nscd cache, mDNS, /etc/nsswitch.conf order. If 'dig works but the app
# cant resolve', the resolver chain is the problem.

# ===== 3) systemd-resolved — the modern resolver
resolvectl status               # which DNS servers, per interface
resolvectl query example.com    # query via resolved (uses configured servers)
resolvectl statistics
resolvectl flush-caches         # clear DNS cache

# Set DNS servers for an interface (NetworkManager / networkd)
sudo resolvectl dns wlan0 1.1.1.1 9.9.9.9
sudo resolvectl domain wlan0 internal.example

# ===== 4) /etc/resolv.conf — usually a symlink in 2026
ls -l /etc/resolv.conf
# -> /run/systemd/resolve/stub-resolv.conf
# Manual edits get overwritten on reboot if systemd-resolved owns it.

# ===== 5) Reverse-engineer the resolver chain
cat /etc/nsswitch.conf | grep '^hosts'
# hosts: files dns
# Means: /etc/hosts FIRST, then DNS.

# ===== 6) Common questions + the right tool

# 'Why can the laptop reach foo.example but the server can't?'
# Different resolvers / different /etc/hosts / different VPN routes.
ssh server 'getent hosts foo.example'        # what the server sees
ssh server 'resolvectl status'

# 'Did the DNS change actually propagate?'
dig +trace +nodnssec example.com
dig @ns1.example.com example.com             # ask the authoritative directly
dig @1.1.1.1 example.com                     # ask a fresh recursive

# 'Is mail set up?'
dig example.com MX +short
dig example.com TXT +short | grep -i spf
dig _dmarc.example.com TXT +short

# 'How long until my cache forgets this name?'
dig example.com               # check the ANSWER TTL field

# 'Is DNS over the wire encrypted?'
resolvectl status              # 'DNSOverTLS' / 'DNSSEC' columns
# OR install dnscrypt-proxy / Unbound and front-end / 853

# ===== 7) Quick troubleshooting flowchart =====
# 1. dig +short name      -> empty?      -> dig @1.1.1.1 name
# 2. dig @1.1.1.1 empty   -> upstream    -> check delegations (dig +trace)
# 3. dig @1.1.1.1 works   -> resolver    -> resolvectl status / restart resolved
# 4. dig works but app    -> resolver    -> getent hosts name; check nsswitch
#                              chain         and /etc/hosts overrides

# ===== 8) Performance + reliability =====
# Run a local caching resolver (Unbound, systemd-resolved, dnsmasq) on each
# host. Latency drops, upstream load drops, and an upstream blip becomes
# 'cached for 5 minutes' instead of 'app cant resolve anything'.

# Set sensible TTLs at the authoritative side:
# - Mail records (MX, TXT/SPF/DMARC): 1 hour to 1 day
# - Public-facing A/AAAA: 5 minutes to 1 hour (faster failover)
# - Internal infra records: 1 day (rarely changes)

dig example.com +short
host example.com