Stop 02 · Networking Fundamentals for CloudTopics · 3/9

DNS

In short

When you launch an API, someone has to point api.yourapp.com at your server. That someone is you, and one wrong DNS record can take your whole app offline.

The Domain Name System translates human-readable domain names into IP addresses — understanding record types (A, CNAME, MX, TXT) and cloud-managed DNS services (Route 53, Cloud DNS) is essential for deploying any web-facing service.

The mascot watchman checks a register and points a delivery rider towards an apartment tower.

Think of it like this

The society watchman's register

A delivery rider asks for 'Sharma ji'. The watchman checks his register and says 'B wing, 404'. If Sharma ji just moved in, the watchman asks the secretary. DNS is that register: names go in, addresses come out, with someone higher up to ask.

Watch it happen

Where api.example.com is answered

. (root)

com

example.com

shop.in

api.example.com

www.example.com

1/5A resolver with nothing cached starts at the root servers. They only know who runs each top-level domain.

The big ideas

What you need to know

A and AAAA records

An A record maps a name to an IPv4 address. AAAA does the same for IPv6. This is how api.yourapp.com finds your server.

CNAME is an alias

A CNAME says 'this name is the same as that name'. Hosting platforms often ask you to add one.

TXT proves ownership

TXT records hold text. Services ask you to add one to prove you own a domain, and email uses them against spoofing.

TTL controls caching

TTL is how many seconds resolvers may cache an answer. Lower it before a migration so the switch spreads quickly.

How it works

Putting your API on its own domain

1
Get a server IP
Deploy your app and note the public IP or hostname your provider gives you.
2
Add the record
In your DNS dashboard, add an A record for api pointing to that IP.
3
Wait for the TTL
Old cached answers expire. With a new name this is usually quick.
4
Check with dig
Run dig api.yourapp.com +short and confirm it prints your server's IP.
5
Add HTTPS
Now that the name resolves, issue a certificate for it and redirect HTTP.

See it in code

Walk through the code

bash

1# What IP does my API name point to?2dig api.example.com A +short3 4# Follow the full chain from the root servers5dig +trace api.example.com6 7# See TXT records (domain verification, email rules)8dig example.com TXT +short9 10# Ask a specific public resolver, skipping your local cache11dig @1.1.1.1 api.example.com +short

1/4Look up the A record. This is the first check when a new domain 'isn't working'.

dig is the backend developer's DNS torch. +short prints just the answer, and +trace shows each step from the root down to the domain's name server.

Save yourself the pain

Common mistakes

Oops

Putting a CNAME on the bare domain (example.com) that also has MX records.

Do this instead

The DNS rules don't allow a CNAME next to other records. Use an A record, or your provider's ALIAS or flattening feature.

Oops

Moving to a new server while the A record still has a 24-hour TTL.

Do this instead

Lower the TTL to a few minutes a day before, switch the record, then raise it again once things are stable.

Your mission

Give your laptop a fake domain

~20 min

Quick check

You change api.example.com's A record to a new server. The old TTL was 3600. How long might some users still reach the old server?

Go deeper

1Run dig or nslookup on a domain to see DNS resolution in action.
2Explore a managed DNS service's console (Route 53 or equivalent) to see how records are configured.
3Understand DNS propagation delay and why DNS changes aren't instant everywhere.