DNS is the address book of the internet. It translates names like example.com into IP addresses, and carries the records that quietly govern mail routing, ownership proofs, and which certificate authorities may issue for your domain.

Almost every web request begins with a DNS lookup, so a misconfigured record translates directly into an outage, a slow first byte, broken email, or a failed certificate renewal. This page covers every record type that matters and what specifically breaks when each is wrong.

How DNS resolution works

A resolver starts at the root zone and follows a delegation chain down to your domain's authoritative nameservers, then asks those servers for the record it needs. Each step can be cached, and how long it stays cached is governed by TTL.

The practical consequence: you are never changing DNS globally, you are changing it at the authoritative source and waiting for caches to expire. Almost every "DNS isn't working" problem is really a caching problem or a delegation problem.

A and AAAA records

An A record maps a hostname to an IPv4 address. An AAAA record does the same for IPv6 — same role, different address space, and the name reflects that an IPv6 address is four times longer.

When a hostname publishes both, dual-stack clients usually prefer IPv6 and fall back to IPv4 only if the connection fails.

If an A record points at a stale IP, traffic goes to a dead server, the wrong tenant, or a parking page. A growing share of mobile networks route over IPv6 by default, and without an AAAA record those clients get pushed through carrier-grade NAT, adding latency and connection failures.

Run dig +short example.com A and confirm every returned IP is one you operate.
Publish an AAAA alongside, but only after confirming your host, load balancer, and firewall all accept IPv6 — a published AAAA pointing at a server that silently drops IPv6 is worse than no record at all.
Keep A and AAAA aligned to the same logical service, with the same TTL, so failover behaves predictably.
Multiple A records give crude redundancy, but they are not a load balancer: clients keep using whatever IP they cached.

CNAME records

A CNAME maps one hostname to another hostname, never to an IP. The resolver follows the alias and uses whatever A/AAAA records it finds at the target.

This is how most platform integrations work — you point app.example.com at a vendor hostname and they manage the IPs, CDN edges, and certificates behind it.

Two constraints trip people up constantly:

A hostname with a CNAME cannot carry any other record type. This is why you cannot put a CNAME on a domain that also needs MX.
An apex domain (example.com, no subdomain) usually cannot use CNAME at all, unless your provider offers ALIAS or ANAME flattening.

Avoid chains — each extra CNAME adds a lookup and another failure surface.

MX records

An MX (mail exchange) record names the servers that receive email for a domain. Each carries a priority — lower numbers are preferred — and a hostname that must resolve via A or AAAA.

Missing, wrong, or stale MX records make inbound mail fail silently or bounce with cryptic SMTP errors. Receivers also use MX data when scoring spam: a domain whose mail should flow through a known provider but suddenly resolves elsewhere is a fraud signal.

Run dig MX example.com and confirm each hostname is a mail server you actually use.
Use multiple MX records, or a provider with built-in failover, so one outage does not bounce mail.
An MX target must be a plain hostname with its own A record. Pointing MX at a CNAME is invalid per RFC 2181, and some receivers reject it outright.

NS records

NS records specify which nameservers are authoritative for a domain. They are special: they define where the rest of the zone lives.

If NS records are wrong, the domain is simply unreachable — web, email, APIs, and certificate renewal all stop, because no resolver can find the right server to ask. Misconfiguration also produces the maddening case where some regions see a working site and others get SERVFAIL. Because NS controls the entire zone, it is also a high-value hijacking target.

List the parent-side delegation with dig +trace example.com NS and confirm it matches the records inside the zone. A mismatch between parent and child delegation is the classic cause of intermittent resolution.
Keep at least two nameservers, on different networks.
Each NS value must be a hostname with a working A record — not an IP.
Allow up to 48 hours after a change for caches to expire.

TXT records

A TXT record stores arbitrary text under a hostname. Originally free-form notes, it is now the carrier for most domain-level metadata: ownership verification, email authentication policy, and service-specific tokens. One hostname can hold many.

TXT records are how the wider internet decides whether to trust your domain. SPF lists which servers may send mail for you, DKIM keys let receivers verify signatures, and DMARC tells inboxes what to do when those fail — all covered in email authentication.

Inventory every TXT at the apex and on _dmarc, _domainkey, and provider subdomains with dig TXT.
Use exactly one SPF record per domain. Multiple SPF strings are an automatic permerror, and it is the most common email-auth mistake there is.
Keep SPF under the 10 DNS lookup limit in RFC 7208. Exceeding it causes SPF to fail, and because each include: can nest, large organisations blow through this without noticing.
Publish a separate DKIM selector per provider and rotate keys when vendors change.

CAA records

A CAA (Certification Authority Authorization) record lists which certificate authorities may issue TLS certificates for your domain (RFC 8659). Public CAs are required to check it at issuance. If no CAA record exists, any compliant CA may issue for your name.

CAA reduces the blast radius of a compromised or rogue CA. Without it, an attacker who tricks any trusted authority can mint a valid certificate for your domain and intercept traffic — even with HSTS enabled.

Add a record per allowed issuer: 0 issue "letsencrypt.org".
Control wildcards separately with issuewild — 0 issuewild ";" disallows them entirely.
Set 0 iodef "mailto:security@example.com" to get reports of blocked issuance attempts. This is a genuinely useful early warning that someone is trying to impersonate you.
Apply at the apex; subdomains inherit unless they publish their own.

TTL and propagation

TTL (Time To Live) is a per-record value in seconds telling caching resolvers how long they may keep a record before asking again.

TTL governs how quickly the internet sees your change. If the TTL was 86400, some clients will still resolve the old IP a full day after you switch. This is what people mean by "waiting for DNS to propagate" — nothing is propagating, caches are just expiring.

Lower TTL to 300 seconds at least 24–48 hours before a planned migration. Lowering it at the same time as the change accomplishes nothing, because resolvers are still holding the old long-TTL copy.
Raise it back to 3600 or 86400 once stable.
Avoid TTLs below 30 seconds unless you genuinely need failover at that resolution — most resolvers cap or ignore them anyway.
Resolvers do not always honour TTL strictly. ISP and corporate caches may extend it.

DNSSEC

DNSSEC adds cryptographic signatures to DNS records (RRSIG), publishes signing keys (DNSKEY), and anchors trust to the parent zone (DS). A validating resolver can then prove a response came from the authoritative nameserver unmodified.

DNSSEC does not encrypt DNS traffic. It provides authenticity and integrity, not confidentiality.

Plain DNS is easy to spoof on hostile networks, and has been abused for cache poisoning, hijacked banking sessions, and silent redirection. Without DNSSEC a malicious resolver can return any IP for your domain and the user cannot tell.

Enable DNSSEC at your DNS provider, then publish the resulting DS record at your registrar. Skipping that second step is the usual reason DNSSEC appears enabled but validates nothing — trust never reaches the root.
Verify with dig +dnssec example.com and look for the ad flag.
Test against a validating resolver; many ISP resolvers strip DNSSEC data.
Plan KSK/ZSK rollovers in advance and confirm your registrar accepts updated DS records — a botched rollover takes the whole domain offline, not just one record.

DNS records explained: A, AAAA, CNAME, MX, NS, TXT, CAA