$ Linux One Liners
Back to problems

problem hub

Read-only

DNS not resolving on Linux

Compare resolver answers, authoritative answers, TTL, direct HTTP checks, and server reachability before changing DNS again.

Safest first command

dig +short example.com A

Before you run this

Expected output: One or more IP addresses, or no answer if the resolver cannot resolve the name.

When not to use it: Do not keep changing DNS records before checking TTL and authoritative nameserver answers.

Expected output example

203.0.113.10

How to read the result

If the expected address appears, DNS may not be the current failure. If answers differ between resolvers or authoritative servers, check TTL and record source before changing more records.

What to check next

Public resolvers return different answers

Means: Propagation, resolver cache, or split authoritative data may still be in play.

Next step: Compare resolver answers and TTL before editing DNS again.

Compare DNS Answers Across Resolvers

Authoritative nameservers disagree

Means: The zone data itself may be inconsistent at the source.

Next step: Compare authoritative answers and fix the DNS provider source of truth.

Compare Authoritative Nameserver Answers

DNS returns the expected IP but the site still fails

Means: The current issue is likely TLS, virtual host, routing, or application behavior.

Next step: Force the hostname to the expected IP and inspect the HTTP response.

Your Site Is Not Down. DNS Might Be Lying.

Compare DNS and direct server response

A browser failure can be DNS, TLS, routing, Nginx, or the app. Compare resolver answers and force a direct HTTP check to the expected IP.

  1. dig +short example.com A
  2. dig @1.1.1.1 example.com A +short
  3. curl --resolve example.com:443:203.0.113.10 https://example.com/

Check TTL and authoritative servers

If public resolvers disagree, check whether propagation is still inside TTL or authoritative records differ.

Resolver vs authoritative decision tree

Separate local resolver behavior from authoritative DNS data. Compare the host resolver, a public resolver, and authoritative nameservers before changing records again.

  1. dig +short example.com A
  2. dig @1.1.1.1 example.com A +short
  3. dig +trace example.com A

Resolver comparison branch

Compare the local resolver with a direct public resolver before changing DNS files. A difference points toward local resolver, VPN, split-horizon, or systemd-resolved state rather than authoritative DNS.

  1. resolvectl status
  2. dig example.com
  3. dig @1.1.1.1 example.com

Bad fixes to avoid

Do not keep editing DNS records while TTL is active. Do not flush only the browser cache and call it fixed. Do not ignore IPv6 or split-horizon DNS if AAAA records or internal zones exist.

Common causes

  • Stale resolver cache or TTL delay
  • Wrong authoritative nameserver
  • A record and AAAA record disagree
  • Local resolv.conf or systemd-resolved issue
  • Server is reachable by IP but virtual host/TLS is wrong

What not to change yet

  • Do not keep editing DNS records while TTL is still active.
  • Do not flush only the browser cache and assume DNS changed globally.
  • Do not ignore IPv6 if AAAA records exist.

Stop and escalate if

  • The DNS change affects a live customer-facing domain or mail delivery.
  • Authoritative nameservers, registrar records, or split-horizon DNS ownership is unclear.
  • The output includes internal hostnames, private zones, or customer domain data.

platform notes

Distro and service notes

systemd-resolved

resolvectl can show which resolver the host actually uses.

macOS

Use macOS resolver tools and cache-flush guidance for Apple Terminal pages.

Web hosting

Use curl --resolve to separate DNS from the web server response.

supporting commands

Command path

Guides and drills