DNS — Turning Names Into Addresses

What is it? #

DNS is the system that turns a name people can remember into an address computers can use.

Nothing on the internet routes by name. Every connection needs an IP address, and DNS is the lookup that provides it.

The lookup is cached at several levels — your operating system, your router, your internet provider, and the resolver. That caching is why DNS is fast, and also why changes appear to take time.

A handful of record types cover almost everything you will do: A, AAAA, CNAME, MX, TXT and NS.

Think of it like this #

A phone directory. You know the name of the business; you look up the number.

The directory is copied and cached in many places. Change your number today and some old copies will still be in circulation tomorrow. That delay is not a bug in the directory — it is the price of not having to ask the central office every single time.

Simple example #

Someone types your domain. Their computer asks a resolver, which works its way down from the root servers to the servers that hold your zone, gets an IP address, and caches the answer for the time you specified.

Code #

The lookup, step by step

browser cache   →  "do I already know shop.example.com?"
operating system→  "is it in /etc/hosts or the OS cache?"
resolver        →  usually your ISP, or 1.1.1.1 / 8.8.8.8
  root servers  →  "who handles .com?"
  .com servers  →  "who handles example.com?"
  example.com   →  "shop.example.com is 203.0.113.10"
  ◀── answer cached at every level for the TTL

Record types you will actually use

A      example.com        → 203.0.113.10        an IPv4 address
AAAA   example.com        → 2001:db8::1         an IPv6 address
CNAME  www.example.com    → example.com         an alias to another name
MX     example.com        → mail.provider.com   where email goes
TXT    example.com        → "v=spf1 ..."        verification, SPF, DKIM
NS     example.com        → ns1.registrar.com   who is authoritative
CAA    example.com        → letsencrypt.org     who may issue certificates

# What address does this name resolve to?
dig +short shop.example.com

# See the full answer including TTL
dig shop.example.com A

# Check a specific resolver, bypassing local caching
dig @1.1.1.1 shop.example.com

# Which nameservers are authoritative?
dig +short example.com NS

# Trace the whole resolution path
dig +trace example.com

# Reverse lookup: which name belongs to this IP?
dig -x 203.0.113.10

How it works #

A resolver walks down the hierarchy: root servers know who handles .com, those know who handles example.com, and your nameservers hold the actual records.

Each answer carries a TTL — time to live — in seconds. Everything that receives the answer may cache it for that long. A TTL of 3600 means caches may serve the old value for up to an hour after you change it.

That is what "DNS propagation" really means. Nothing is being pushed anywhere; old cached answers are simply expiring at different times.

The practical technique is to lower the TTL to 300 seconds a day before a planned change, make the change, confirm it, then raise the TTL again.

A records point at an IP address. CNAMEs point at another name, which is how you point www at your apex domain or at a CDN hostname. A CNAME cannot coexist with other records at the same name, which is why apex domains often need an A record or a provider-specific alias record.

dig +short gives the answer alone; dig +trace shows the whole path, which is invaluable when something is not resolving as expected.

Real-world use #

Every deployment involves DNS: pointing a domain at a server, moving to a new host, putting a CDN in front, or verifying ownership with a TXT record.

DNS is also a traffic control tool. Round-robin A records spread load crudely; managed DNS services can route by geography or health, sending users to the nearest healthy region.

Email depends on it entirely. MX records decide where mail goes, and SPF, DKIM and DMARC records in TXT form decide whether your mail is trusted or treated as spam.

DNS failures are also famous for looking like everything else. "The site is down" frequently turns out to be a missing record, an expired domain or a nameserver change that has not finished propagating. Checking with dig against an external resolver is usually the fastest diagnosis.

Common mistakes #

• Changing records with a long TTL still in place, then waiting hours for the change to appear.
• Trying to put a CNAME on the apex domain alongside other records.
• Forgetting the www record, so one form of the domain works and the other does not.
• Letting the domain registration itself expire, which no amount of DNS configuration fixes.
• Testing only from your own machine, where the old answer is still cached.

Practice #

For a domain you own or any public domain, use dig to find its A record and TTL, its nameservers, and its MX records. Then run dig +trace and follow the path from root to answer. Finally, explain in one sentence why lowering the TTL before a migration helps.