DNS explained: records, resolution and common problems

DNS (Domain Name System) turns names like example.com into IP addresses that computers use. It also stores other information about a domain, such as where its email goes.

How a lookup works

When your browser needs www.example.com:

1. It checks its own cache and the operating system cache.
2. It asks a recursive resolver, usually run by your ISP, your company or a public service such as Cloudflare (1.1.1.1) or Google (8.8.8.8).
3. If the resolver does not have the answer cached, it asks the root servers, which point to the servers for the TLD (.com), which point to the domain's authoritative name servers.
4. The authoritative server returns the answer. The resolver caches it and passes it back.

Answers are cached to keep DNS fast, for a time set by the TTL.

The main record types

Record	Purpose	Example
A	Name to IPv4 address	example.com -> 203.0.113.10
AAAA	Name to IPv6 address	example.com -> 2001:db8::10
CNAME	Alias to another name	www -> example.com
MX	Mail servers for the domain	10 mail.example.com
TXT	Free text, used for SPF, DKIM, DMARC and verification	v=spf1 include:... ~all
NS	Which name servers are authoritative	ns1.provider.com
SRV, CAA	Service location, and which CAs may issue certificates

Rules worth knowing:

• A CNAME cannot sit at the root (example.com) next to other records. Some providers offer "ALIAS" or "CNAME flattening" for that.
• A name with a CNAME should not have other records of other types.
• The registrar is where you buy the domain; the DNS host is where records live. They can be different, and the NS records connect them.

TTL and propagation

TTL is how many seconds a resolver may cache an answer. A change is not instant: old answers can live in caches until their TTL ends. This is what people call "propagation".

Tip: lower the TTL a day before a planned change (for example a server move), then raise it again afterwards.

Debugging DNS

dig example.com            # full answer
dig +short example.com A   # just the IPs
dig example.com MX
dig @1.1.1.1 example.com   # ask a specific resolver
dig +trace example.com     # follow the delegation from the root
nslookup example.com       # simpler alternative

Check what the authoritative server says versus what a public resolver says. If they differ, you are probably waiting for a cache.

DNS and email

Email deliverability depends on DNS:

• MX says where mail is received.
• SPF (TXT) lists who may send mail for your domain.
• DKIM (TXT) publishes a key to verify message signatures.
• DMARC (TXT) tells receivers what to do when checks fail.

Security points

• Protect your registrar and DNS accounts with strong passwords and two-factor authentication. Taking over DNS means taking over the domain.
• Dangling DNS records pointing to deleted cloud resources can lead to subdomain takeover. Remove records you no longer use.
• DNSSEC adds signatures so answers can be verified, while DoH and DoT encrypt lookups between you and the resolver.
• Use a registrar lock to prevent unauthorised transfers.

Common problems

• Changed a record but still see the old one: caching and TTL.
• Site works on some networks only: different resolvers or caches.
• Email going to spam: missing SPF, DKIM or DMARC.
• A CNAME at the root: not allowed, use an A record or ALIAS.

Takeaway: DNS maps names to answers through a chain of resolvers and authoritative servers, caches by TTL, uses record types for different jobs, and deserves the same protection as any critical account.

---

Networking & Cloud series, Part 1 (how the internet works): 2 of 5. Previous: IP addresses, subnets and CIDR explained simply.