DNS Lookups: dig, Record Types and Propagation

Updated 2026-03-27 · By SPUNK13 · Back to spunk.bet

DNS problems feel mystical because the tooling hides what is happening. Once you can read a dig answer, almost every DNS incident becomes obvious in about ninety seconds.

dig, and the Flags Worth Knowing

dig example.com A +short          # just the answer
dig example.com MX                # full response with sections
dig @1.1.1.1 example.com A        # ask a specific resolver
dig @ns1.example.com example.com A # ask the authoritative server directly
dig example.com +trace            # walk from the root down
dig -x 93.184.216.34              # reverse lookup

+trace is the diagnostic that settles arguments. It queries a root server, then the TLD servers, then your authoritative nameservers, printing each delegation. If the answer is right at the authoritative server but wrong through @1.1.1.1, you have a caching issue and not a configuration issue — and that distinction determines whether you wait or keep editing.

Reading the Answer

Three things in the output matter. The status: field — NOERROR means the name resolved, NXDOMAIN means it does not exist, SERVFAIL usually means a broken delegation or a DNSSEC validation failure. The number before the record type is the remaining TTL in seconds; if it counts down each time you rerun the query, you are being served from cache. And the flags: line contains aa when you asked an authoritative server, which is how you confirm you are talking to the source of truth.

The Record Types That Come Up

• A / AAAA — IPv4 and IPv6 addresses. A hostname can have several; clients pick one, so this is crude round-robin load balancing with no health awareness.
• CNAME — an alias to another name. A CNAME record cannot coexist with any other record on the same name, which is why it is illegal at the zone apex where SOA and NS records must live.
• MX — mail servers, with a priority number where lower wins. Must point at a hostname, never an IP.
• TXT — arbitrary text; in practice SPF, DKIM, DMARC and domain-ownership verification. Only one SPF record is permitted per domain — two is a hard failure, not a merge.
• NS — delegation. These must match what the registrar has, which is a separate system people forget exists.
• CAA — which certificate authorities may issue for the domain. Cheap to add, and it blocks a whole class of misissuance.

The Apex CNAME Problem

You cannot put a CNAME on example.com itself, only on www.example.com. Since most modern hosts give you a hostname rather than a stable IP, providers invented workarounds: ALIAS or ANAME records (Route 53 calls it an alias record), or CNAME flattening as Cloudflare does. These resolve the target server-side and return A records, keeping the protocol legal. They are provider features, not DNS standards, so this is one place your DNS host genuinely matters.

Propagation Is a Myth; TTL Is Real

Nothing propagates. Resolvers cache an answer for the TTL and then ask again. A change with a 3,600-second TTL takes up to an hour to be seen by any given resolver, and no amount of waiting speeds up one that is only 10 minutes into its hour. The correct procedure before a planned migration: drop the TTL to 300 seconds at least one full old-TTL period in advance, make the change, verify, then raise the TTL back to something sane. Do this and a cutover takes five minutes instead of a day.

Negative answers cache too. The minimum TTL field in the SOA record controls how long NXDOMAIN is remembered, so creating a record after someone has already queried for it can appear not to work for that period. Keep the SOA minimum low, around 300 seconds.

Where Lookups Actually Come From

On Linux, dig queries a DNS server directly and ignores /etc/hosts, while your applications go through the system resolver and do not. That is why dig can succeed while curl fails; getent hosts example.com shows what applications actually see. Containers add another layer, injecting their own resolv.conf and search domains.

A Two-Minute Health Check

Confirm the registrar's nameservers match your NS records, confirm every authoritative nameserver returns identical answers, check SPF resolves within the 10 DNS-lookup limit (exceeding it is a permanent failure that silently degrades deliverability), and make sure a CAA record exists. Those four cover most of the DNS incidents that reach a postmortem.