Domains & DNS cheat sheet

A scannable Domains & DNS reference: 31 short snippets across 13 topics, each linking back to the lesson it came from.

At a glance

Quick snippets

How name resolution works

The lookup path

# who answers here, and what did they say?
dig www.example.com +short

# walk the whole delegation chain yourself
dig +trace www.example.com

# ask a specific resolver, bypassing local cache
dig @1.1.1.1 www.example.com A +noall +answer

# what are the name servers for the zone?
dig example.com NS +short

Reading an answer

$ dig www.example.com A

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47112
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0

;; ANSWER SECTION:
www.example.com.  3600  IN  CNAME  example.com.
example.com.      300   IN  A      203.0.113.10

;; SERVER: 1.1.1.1#53(1.1.1.1)

Full lesson: How name resolution works →

TTL, propagation and common mistakes

TTL decides how long you are stuck

# before a migration, lower the TTL and wait at least one old TTL
dig example.com A +short            # confirm the new TTL is live everywhere
# ... cut over ...
# then raise it again once the change is proven

# how long is left on a cached answer?
dig example.com A | grep -E "^(example|www)"

Full lesson: TTL, propagation and common mistakes →

The DNS hierarchy, zones and delegation

Delegation and glue

; in the parent zone, delegating a subdomain
api     IN  NS  ns1.api.example.com.
api     IN  NS  ns2.api.example.com.

; glue: the parent publishes addresses for nameservers inside the delegated zone,
; otherwise resolving ns1.api.example.com would require resolving api.example.com
ns1.api  IN  A   203.0.113.21
ns2.api  IN  A   203.0.113.22

Delegation and glue

# who is actually answering, and where does the chain break?
dig +trace api.example.com
dig NS api.example.com @a.gtld-servers.net      # ask the parent directly
dig SOA example.com +short
dig +norecurse api.example.com @ns1.api.example.com   # ask the child directly

Full lesson: The DNS hierarchy, zones and delegation →

Registrars, registries and managing a domain

Who actually controls what

# the registrar side: which nameservers does the registry publish?
dig NS example.com @a.gtld-servers.net +norecurse

# the DNS provider side: what does one of those servers actually answer?
dig A www.example.com @ns1.example.com +norecurse

# registration data, subject to redaction
whois example.com | head -20

Transfers, locks and expiry

A sane domain policy

  all domains on auto-renew, payment method with an expiry reminder
  transfer lock on except during a planned move
  the registrant email is a shared mailbox, not one person's address
  renewal and expiry dates tracked in a calendar you actually read
  registrar account secured with hardware-key two-factor authentication
  one document naming who can approve a nameserver change

Full lesson: Registrars, registries and managing a domain →

Subdomains, wildcards and delegation strategies

Wildcards and their traps

; a wildcard matches any name at one level, and only if no exact record exists
*        IN  A     203.0.113.50
*.docs   IN  A     203.0.113.51

; these still beat the wildcard
mail     IN  A     203.0.113.60

; the apex is NOT covered by * - add it explicitly if you want it
@        IN  A     203.0.113.61

Wildcards and their traps

# does a name that should not exist resolve?
dig +short this-should-not-exist-12345.example.com
dig +short www.example.com

# and check whether the answer came from a wildcard
dig this-should-not-exist-12345.example.com | grep -E "ANSWER:|status:"

Naming that scales

Convention that survives growth

  www.example.com              canonical public site
  api.example.com              versioned API
  docs.example.com             documentation
  status.example.com           status page on separate infrastructure
  cdn.example.com              CNAME to the CDN edge
  mail.example.com             MX target (never a CNAME)

  Every other name is either a deliberate service or a bug.

Full lesson: Subdomains, wildcards and delegation strategies →

Email DNS: MX, SPF, DKIM and DMARC

MX records

; lower priority number wins; equal numbers are used randomly
@    IN  MX  10  mx1.mailprovider.example.
@    IN  MX  20  mx2.mailprovider.example.

; never a CNAME, and never behind a wildcard
mail IN  A   203.0.113.70

SPF

; one SPF record, and only one
@    IN  TXT  "v=spf1 ip4:203.0.113.0/24 include:_spf.mailprovider.example include:transactions.example -all"

; the -all at the end is a hard fail. ~all is a soft fail and is safer during rollout.
; ?all is no policy at all and should never ship.

SPF

# count the lookups before you publish
dig +short TXT example.com | grep spf1

# and check the whole authentication story from outside
dig +short TXT mail._domainkey.example.com       # DKIM key
dig +short TXT _dmarc.example.com                # DMARC policy

Full lesson: Email DNS: MX, SPF, DKIM and DMARC →

Troubleshooting DNS with dig and online tools

dig, properly

dig www.example.com                        # the default: A record via your resolver
dig www.example.com A AAAA +short          # both address families, short form
dig www.example.com @1.1.1.1              # ask a specific public resolver
dig www.example.com @ns1.example.com +norecurse   # authoritative, no caching help
dig ANY example.com @ns1.example.com       # discouraged: many servers refuse or minimise
dig +trace www.example.com                 # walk the delegation from the root
dig -x 203.0.113.10                        # reverse lookup
dig +tcp www.example.com                   # force TCP, useful when UDP is filtered
dig +dnssec example.com                    # request DNSSEC records
dig +noall +answer example.com TXT         # just the answer section

Diagnosing the usual failures

# a five-command triage that answers most tickets

dig +short ns.example.com                     # 1. what is delegated
dig +short a www.example.com @ns1.example.com # 2. what the authoritative server says
dig +short a www.example.com @1.1.1.1         # 3. what a public resolver says
dig +trace www.example.com                    # 4. where the chain breaks
dig +short txt _dmarc.example.com             # 5. verify email records survived the change

Multiple vantage points

# check several public resolvers at once and print only the answer
for r in 1.1.1.1 8.8.8.8 9.9.9.9 208.67.222.222; do
  printf '%-18s %s\n' "$r" "$(dig +short +time=2 +tries=1 www.example.com @$r | tr '\n' ' ')"
done

# and compare against the authoritative server
printf '%-18s %s\n' "authoritative" "$(dig +short www.example.com @ns1.example.com | tr '\n' ' ')"

Full lesson: Troubleshooting DNS with dig and online tools →

DNS as code: providers and Terraform

Importing an existing zone

# generate records from an exported zone file, then review the output
terraform import aws_route53_zone.main Z0123456789ABCDEF

# import one record at a time, checking the plan after every batch
terraform import 'aws_route53_record.app["www"]' Z0123456789ABCDEF_www_A

terraform plan    # must show no changes once the batch is complete

A safe change workflow

Every DNS change

  1. branch, edit, run plan in CI, paste the plan into the pull request
  2. reviewer checks the diff against the reason for the change
  3. merge, apply, and note the time
  4. verify from two public resolvers and one authoritative server
  5. if it is wrong, revert the commit and apply - never edit in the console

Rate limits worth knowing
  most providers throttle API writes; a loop over 500 records fails
  apply in batches with a short pause, and retry with backoff
  a partial apply leaves the zone in a mixed state - re-run until clean

Full lesson: DNS as code: providers and Terraform →

DNS and CDNs: apex CNAME, ALIAS and flattening

The apex problem

; this is invalid and every provider will reject it
example.com.   IN  CNAME  example.cdn-provider.net.

; these are the workarounds, all of them provider-specific
example.com.   IN  ALIAS  example.cdn-provider.net.     ; DNSimple, some others
example.com.   IN  ANAME  example.cdn-provider.net.     ; older name for the same idea
; Cloudflare and a few others call it CNAME flattening at the apex and
; publish the resolved addresses in the answer instead of the CNAME

Delegating to a CDN

Typical pattern with a provider that supports CNAME flattening

  apex      example.com      -> flattened to the CDN edge
  www       www.example.com  -> CNAME to example.com, or to the CDN directly
  cdn       cdn.example.com  -> CNAME to a provider edge name

  TLS: the CDN must be able to serve a certificate covering example.com
       and www.example.com, usually via a DNS-01 challenge it performs itself

  Redirect: pick one canonical hostname. If www is canonical, redirect the
            apex to www with a 301 served by the CDN, not by the origin.

Delegating to a CDN

dig +short example.com                      # expect A records, not a CNAME
dig +short www.example.com                  # expect a CNAME chain to the edge
curl -sI https://example.com | grep -iE "server|cf-cache-status|x-cache|via"

# and confirm the certificate actually covers the apex
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -ext subjectAltName

Full lesson: DNS and CDNs: apex CNAME, ALIAS and flattening →

IPv6 and dual-stack DNS

AAAA records and dual stack

; serve both families from the same name
www   IN  A     203.0.113.10
www   IN  AAAA  2001:db8:abcd::10

; never point an AAAA at a family that cannot serve the traffic
; a broken IPv6 path is worse than no IPv6 at all

AAAA records and dual stack

dig AAAA www.example.com +short
dig A    www.example.com +short

# does the site actually serve over IPv6?
curl -6 -sIv https://www.example.com -o /dev/null
curl -4 -sIv https://www.example.com -o /dev/null

# which family did the client actually choose?
curl -6 -s https://www.example.com -o /dev/null -w 'ipv6 connect: %{time_connect}\n'

NAT64, DNS64 and IPv6-only networks

How an IPv6-only client reaches an IPv4-only site

  1. client asks for AAAA
  2. DNS64 resolver finds no AAAA, only an A
  3. resolver synthesises a AAAA from the well-known prefix 64:ff9b::/96
     plus the IPv4 address
  4. NAT64 gateway translates that address and forwards the connection

Consequences
  an IPv6 host must not publish a fake AAAA - it would win the lookup
  and then fail, because DNS64 only synthesises when no AAAA exists
  a service that is IPv6-only is invisible to IPv4 clients with no DNS64

Full lesson: IPv6 and dual-stack DNS →

Anycast, GeoDNS and traffic steering

Routing policies that earn their keep

A defensible steering setup

  health check     HTTPS against /healthz, 3 failures to mark down,
                   60 second interval, 3 regions of checkers
  failover         primary region, secondary region, no tertiary
  TTL              60 for steering records, 300 for static ones
  weight           start at 5 percent, not 50
  alarm            on health-check flapping, not just on "down"

  If the health check only tests TCP 443, a broken application
  behind a live load balancer keeps receiving traffic.

When steering does more harm than good

# watch which answers a resolver gives you over time
for i in $(seq 1 10); do
  dig +short www.example.com @1.1.1.1 | tr '\n' ' '
  echo
  sleep 3
done

# and confirm a specific region's answer by querying an authoritative server
dig +short www.example.com @ns1.example.com

Full lesson: Anycast, GeoDNS and traffic steering →

DNSSEC and DNS security

Signing and the chain of trust

The chain, from the root down

  the root zone  publishes a DS record for .com
  .com           publishes a DS record for example.com
  example.com    publishes DNSKEY records, and the parent's DS matches one of them
  answers        are signed with the zone's private key (RRSIG)

If any link is missing or mismatched, a validating resolver returns SERVFAIL
- not the unsigned answer. That is why DNSSEC mistakes break a zone hard.

Keys and rollover

dig +dnssec example.com @1.1.1.1 | grep -E "flags:|RRSIG|ad;"
dig DS example.com @a.gtld-servers.net +short
dig DNSKEY example.com @ns1.example.com +short

# a validating resolver sets the AD flag when it has verified the chain
dig +dnssec +short example.com @8.8.8.8

Full lesson: DNSSEC and DNS security →

Migrating DNS providers without downtime

Inventory first

# three ways to capture the current zone - use at least two
dig AXFR example.com @ns1.example.com > zone.txt      # if transfers are permitted
dig +short ns example.com                            # current delegation
dig SOA example.com @ns1.example.com                 # current serial and timers

# a full check of the record types that matter
for t in A AAAA CNAME MX TXT NS CAA SRV; do
  echo "== $t"
  dig +short $t example.com @ns1.example.com
done

The staged cutover

# confirm a resolver is now reaching the new servers
dig NS example.com @a.gtld-servers.net +norecurse

# compare answers from old and new authoritative servers before the switch
diff <(dig +short www.example.com @old-ns1) <(dig +short www.example.com @new-ns1)

# after the switch, verify from several vantage points
for r in 1.1.1.1 8.8.8.8 9.9.9.9; do
  printf '%-12s %s\n' "$r" "$(dig +short www.example.com @$r | tr '\n' ' ')"
done

The things that break quietly

# a compact post-migration checklist
dig +short NS    example.com @a.gtld-servers.net +norecurse
dig +short A     example.com
dig +short MX    example.com
dig +short TXT   example.com | grep -E "spf1|google-site-verification|_dmarc"
dig +short TXT   _dmarc.example.com
dig +short CAA   example.com
dig +dnssec      example.com @1.1.1.1 | grep -c "ad;"

Full lesson: Migrating DNS providers without downtime →

FAQ

Related cheat sheets

SEO Basics Web Hosting CDNs & Caching Accessibility

Last refreshed 2026-09-27.