FoundationsBeginner2h

DNS & domains.

How a hostname resolves to the box your service runs on.

What is DNS?

DNS is the phone book of the internet. It turns a name people can remember, like api.example.com, into the IP address a machine can route to. When your service goes live, DNS is what connects its public name to the server actually running your code.

Why it matters

A huge share of "the site is down" incidents are really DNS or domain issues: an expired domain, a record pointing at an old server, or a TTL that hasn't expired yet. Knowing how resolution works lets you diagnose these in minutes instead of blaming the application. It is also the first thing you configure when shipping anything to a real URL.

What to learn

  • The resolution path: resolver, root, TLD, authoritative server
  • Record types you will actually set: A, AAAA, CNAME, TXT, MX
  • TTL and why DNS changes do not take effect instantly
  • The difference between a domain registrar and a DNS host
  • How a reverse proxy or load balancer sits behind the record
  • HTTPS certificates and domain validation
  • dig and nslookup for inspecting records

Common pitfall

Expecting a DNS change to be instant. Records are cached for their TTL across resolvers worldwide, so a change can take minutes to hours to propagate. Lower the TTL before a planned migration, not after, or you will be stuck waiting while half your users hit the old server.

Resources

Primary (free):

Practice

Run dig against a site you use and read the answer section: find its A record, then the TTL. Run it again against CNAME and TXT for the same domain. Explain what each record does. Done when you can predict which record type you would set to point a subdomain at a hosting provider.

Outcomes

  • Trace how a hostname resolves to an IP address.
  • Pick the right record type for an apex domain vs a subdomain.
  • Explain why a DNS change did not take effect yet using TTL.
  • Inspect live DNS records with dig or nslookup.
Back to Backend roadmap