So I treated a DNS lookup like a game: three levels and a boss, with dig as my tool. If you read part 1 and want to see what happens underneath, this post is for you.

Quick recap: what is DNS?

DNS is the phonebook of the internet. People remember names like google.com, but computers need numbers (IP addresses). DNS turns one into the other, and that is why name resolution exists.

The game map

There is no single giant phonebook for the whole internet. DNS is split into layers, and each layer only knows who to ask next. Level 1 is the root servers, Level 2 is the .com servers, and Level 3 is google.com's own name servers. The boss at the end is the real answer: the IP address.

Your tool: dig

dig is a terminal tool that asks DNS a question and shows you the raw answer. You use it when you want to see what DNS is really saying, for example when a site isn't opening or a record change hasn't shown up yet.

Real-life comparison: Think of dig as a magnifying glass for DNS. Your browser hides the lookup from you, and dig lets you see it.

dig -v

DiG 9.20.24-1ubuntu0.3-Ubuntu

One honest note: by default, dig doesn't ask the root servers directly. It asks my resolver, which here is Google's public one at 8.8.8.8 (you can see SERVER: 8.8.8.8 in every output). So Levels 1 to 3 show what each layer looks like. The bonus section after the boss shows the real walk.

Level 1: Ask the root with dig . NS

Every search has to start somewhere. For DNS, it starts at the very top, called the root.

Real-life comparison: Think of a directory for the whole country. It doesn't list every house, it only tells you which city directory to open next.

dig . NS

;; ANSWER SECTION:
.  87203  IN  NS  m.root-servers.net.
.  87203  IN  NS  j.root-servers.net.
.  87203  IN  NS  f.root-servers.net.
.  87203  IN  NS  d.root-servers.net.
.  87203  IN  NS  i.root-servers.net.
.  87203  IN  NS  h.root-servers.net.
.  87203  IN  NS  l.root-servers.net.
.  87203  IN  NS  a.root-servers.net.
.  87203  IN  NS  g.root-servers.net.
.  87203  IN  NS  k.root-servers.net.
.  87203  IN  NS  e.root-servers.net.
.  87203  IN  NS  c.root-servers.net.
.  87203  IN  NS  b.root-servers.net.

;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)

What I found: I got 13 root servers, named a.root-servers.net. to m.root-servers.net., one letter each. The lone dot in dig . NS is the root itself, the level above .com. The number 87203 is the TTL, in seconds: how long a resolver may remember this answer. I ran the command again a minute later and it still said 87203, so this number does not always tick down on every resolver.

Level 2: Ask the TLD with dig com NS

The root doesn't know where google.com is, but it knows who handles .com. So the next question goes to the .com servers, also called TLD servers (TLD means top-level domain).

Real-life comparison: Now we're at the city directory. It doesn't list individual houses either, only which street to go to.

dig com NS

;; ANSWER SECTION:
com.  21600  IN  NS  m.gtld-servers.net.
com.  21600  IN  NS  j.gtld-servers.net.
com.  21600  IN  NS  i.gtld-servers.net.
com.  21600  IN  NS  h.gtld-servers.net.
com.  21600  IN  NS  c.gtld-servers.net.
com.  21600  IN  NS  a.gtld-servers.net.
com.  21600  IN  NS  k.gtld-servers.net.
com.  21600  IN  NS  b.gtld-servers.net.
com.  21600  IN  NS  g.gtld-servers.net.
com.  21600  IN  NS  f.gtld-servers.net.
com.  21600  IN  NS  l.gtld-servers.net.
com.  21600  IN  NS  d.gtld-servers.net.
com.  21600  IN  NS  e.gtld-servers.net.

;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)

What I found: I got 13 .com servers, a.gtld-servers.net. to m.gtld-servers.net., with a TTL of 21600 (6 hours). They know who is responsible for every .com domain, but not what's inside any of them.

In the trace below, the same .com servers show a TTL of 172800. When I asked 1.1.1.1 instead, it showed 164710, so Google's resolver (8.8.8.8) seems to report a shorter TTL than the real servers. Numbers from a resolver can differ from what the real servers say.

Level 3: Ask the owner with dig google.com NS

Now we reach the owner. The authoritative name servers hold the real records for a domain, so they have the final word.

Real-life comparison: This is the exact house. The directories only told us the street, and here is the person who actually lives there.

dig google.com NS

;; ANSWER SECTION:
google.com.  21600  IN  NS  ns3.google.com.
google.com.  21600  IN  NS  ns1.google.com.
google.com.  21600  IN  NS  ns4.google.com.
google.com.  21600  IN  NS  ns2.google.com.

;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)

What I found: I got four servers, ns1.google.com. to ns4.google.com., with a TTL of 21600. These are the same four from part 1, where I found them with nslookup. Same answer, different tool.

Why NS records matter: An NS record says who answers for a domain. If nobody answered, nobody could find google.com's records, so the site and email would be unreachable even if the servers were fine. That's also why Google lists four, so one failing doesn't break it.

Boss level: the full answer with dig google.com

The final move: ask for the actual address of google.com, its A record.

dig google.com

;; ANSWER SECTION:
google.com.  251  IN  A  142.251.106.113
google.com.  251  IN  A  142.251.106.100
google.com.  251  IN  A  142.251.106.102
google.com.  251  IN  A  142.251.106.139
google.com.  251  IN  A  142.251.106.138
google.com.  251  IN  A  142.251.106.101

;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)

What I found: Six IPv4 addresses came back, so traffic can be shared across several servers. The TTL is 251 seconds. In the trace below, Google's own server says 300, so my resolver was probably giving me a saved copy. When I ran the command again, I saw 109, 200 and 281 on different tries, so the number did not tick down in a straight line. Google's public resolver is probably many servers behind one address, and each try may reach a different saved copy. The addresses also weren't the same in every command (142.251.106.x here, 192.178.173.x in the trace), so yours may differ.

From dig to your browser: Your browser takes one of these addresses, connects to that server, and the server sends back the page. That's step 3 from part 1, now with real numbers.

Bonus: the real walk with dig +trace

The earlier commands went through my resolver. dig +trace skips that shortcut and asks each layer itself, starting from the root, so you can see the real walk. I added +nodnssec to hide the long security signature lines.

dig +trace +nodnssec google.com

.  87203  IN  NS  m.root-servers.net.
.  87203  IN  NS  l.root-servers.net.
.  87203  IN  NS  g.root-servers.net.
(... 10 more root servers ...)
;; Received 239 bytes from 8.8.8.8#53(8.8.8.8) in 68 ms

com.  172800  IN  NS  b.gtld-servers.net.
com.  172800  IN  NS  f.gtld-servers.net.
com.  172800  IN  NS  h.gtld-servers.net.
(... 10 more .com servers ...)
;; Received 863 bytes from 192.112.36.4#53(g.root-servers.net) in 292 ms

google.com.  172800  IN  NS  ns2.google.com.
google.com.  172800  IN  NS  ns1.google.com.
google.com.  172800  IN  NS  ns3.google.com.
google.com.  172800  IN  NS  ns4.google.com.
;; Received 287 bytes from 192.55.83.30#53(m.gtld-servers.net) in 168 ms

google.com.  300  IN  A  192.178.173.138
google.com.  300  IN  A  192.178.173.100
google.com.  300  IN  A  192.178.173.102
google.com.  300  IN  A  192.178.173.113
google.com.  300  IN  A  192.178.173.139
google.com.  300  IN  A  192.178.173.101
;; Received 135 bytes from 216.239.32.10#53(ns1.google.com) in 100 ms

I trimmed the lines about IPv6 failing ("network unreachable"), because my setup has no IPv6 route. dig then used IPv4 and finished normally. I also shortened the long server lists and tightened the spacing between columns.

What I found: A different server answered at every step. My resolver (8.8.8.8) gave the list of root servers, g.root-servers.net pointed me to the .com servers, m.gtld-servers.net pointed me to Google's name servers, and finally ns1.google.com gave the A records. Each layer only knew who to ask next, and only the last one knew the answer. The TTLs change too: 172800 seconds (2 days) for the pointers, and 300 (5 minutes) for the final address.

I ran the same trace on github.com. It followed the same walk, but GitHub's name servers are spread across two providers (awsdns and nsone.net), and the final TTL was 60 seconds, not 300.

Your sidekick: the recursive resolver

I typed one question, but several servers were involved. Who did the walking? A recursive resolver. It takes your question, asks the root, then .com, then the owner, and brings back the answer. It also remembers answers for a while (that's the TTL), so the next person who asks gets it faster.

Real-life comparison: Think of a sidekick in a game. You say "find the key", and they run through every level for you and come back with it.

When you press Enter in a browser, the same thing happens: the browser asks a resolver, the resolver walks through the levels, and the browser gets an IP address and connects.

Why this matters when you build things

• Google has four name servers, so one can fail and the domain still works.

• TTL decides roughly how fast changes spread. With a TTL of 5 minutes, most people see a change soon. With 2 days, some keep seeing the old answer for a long time.

• If DNS fails, your app is unreachable even when your server is fine.

Cheat sheet: which command is which level?

Play it yourself

Pick any domain and run the same commands. Look at how many answers you get, the TTL numbers, and the Received ... from ... lines in the trace. For a .org domain, ask dig org NS for Level 2.

dig . NS
dig com NS
dig google.com NS
dig google.com
dig +trace +nodnssec google.com

Quest complete: recap

Final thoughts

What surprised me most is how little each layer knows. In my first four commands I only talked to a resolver, and with dig +trace I finally talked to the real servers. The root, .com and Google's servers each pointed me to the next one, and only the last one knew the answer. Once I saw that, DNS stopped feeling like magic.

In the next post, I'll explore cURL: how to make HTTP requests, inspect responses, and test APIs directly from the terminal.

Which level surprised you the most? Tell me in the comments.

I'm learning full-stack development, and I recently started learning DNS. In this post, I'll share what I learned about DNS and its records (NS, A, AAAA, CNAME, MX, and TXT). I'll use simple language and real-life examples, so if you're a beginner, this is for you.

What is DNS?

Without DNS, you would have to type a number like 142.250.195.46 in your browser instead of a name. This number is called an IP address, and computers use it as a unique identity to communicate with each other. But people can't remember these numbers. Imagine memorizing a different number for every website you visit.

Now think about calling your best friend. You don't type "their number", you just search "their name" in your phonebook and call. DNS works the same way: it is the phonebook of the internet. You type the name, and DNS finds the number for you.

1. You type google.com and press Enter. Your browser asks DNS where this website lives.

2. DNS converts the domain name into an IP address and gives it back to your browser.

3. Your browser uses that IP address to reach the server, and the server sends the website's files to your screen.

There are a few more steps behind the scenes, which I'll cover in part 2.

Why do we need DNS records?

A domain like google.com has to answer more than one question. Where is the website? Where should emails go? Who manages this domain? Is it really owned by the person who claims it?

One answer can't cover all of these, so each answer is stored separately in the domain's DNS settings. Each entry is called a DNS record. A DNS record is one instruction that tells the internet one specific thing about your domain.

Think of a contact card on your phone. It holds a home address, a mobile number, and an email, each as its own entry. A domain works the same way, and each DNS record is one entry on its card.

Let's go through the records one at a time.

NS Record

Before anyone can ask where your website lives, they need to know who to ask. That is what the NS (Name Server) record does. It tells the internet which servers are responsible for answering questions about your domain.

Most domains have two or more NS records, so if one server is down, another can still answer.

Real-life comparison: Think of the local post office in charge of your area. When a letter needs to reach your neighborhood, everyone knows which post office handles it. An NS record points to the "post office" for your domain.

Here is the real output I got by running nslookup -type=NS google.com in my terminal:

google.com      nameserver = ns1.google.com
google.com      nameserver = ns2.google.com
google.com      nameserver = ns3.google.com
google.com      nameserver = ns4.google.com

Root servers and .com servers are the first steps DNS takes to find a domain's name servers. I'll explain how that works in part 2.

A Record

An A record solves the problem of connecting a domain name like google.com to an IPv4 address that computers use to communicate.

Real-life comparison: An A record is like a house address. You know the house by its name, but you need its address to find it.

Here is the real output I got by running nslookup -type=A google.com in my terminal:

google.com      142.250.122.102
google.com      142.250.122.101
google.com      142.250.122.138
google.com      142.250.122.100
google.com      142.250.122.139
google.com      142.250.122.113

Big sites like Google have many IPv4 addresses, so traffic can be shared across several servers.

AAAA Record

IPv4 addresses like 142.250.122.102 worked well for a long time, but there are only about 4 billion of them. With phones, laptops, smartwatches, and smart TVs all online, the world started running out.

The fix is IPv6, a newer address format with a practically unlimited supply. An IPv6 address is much longer, something like 2404:6800:4013:802::71. The AAAA record (say "quad-A") does the same job as the A record, but for IPv6: it connects a domain name to an IPv6 address.

Real-life comparison: Think of a contact on your phone who now has two numbers, an old short one and a new longer one. It's the same person, and you can reach them on either. The A record is the old number, and the AAAA record is the new one.

Here is the real output I got by running nslookup -type=AAAA google.com in my terminal:

Name:    google.com
Addresses:  2404:6800:4013:802::71
          2404:6800:4013:802::8a
          2404:6800:4013:802::8b
          2404:6800:4013:802::65

Notice how much longer the address is compared to the IPv4 ones above. Most websites keep both an A and an AAAA record, so visitors on either type of network can reach them.

CNAME Record

Sometimes you don't want to point a name at a number. You want to point it at another name. For example, www.example.com and example.com should open the same website. Instead of repeating the IP address in two places, a CNAME (Canonical Name) record says: "this name is just another name for that one."

Real-life comparison: Think of a nickname. Friends call someone "Bunty", but their real name is Rahul. If you ask for Bunty's number, you end up looking up Rahul's contact. A CNAME works the same way: it sends you to the real name, and the real name gives the answer.

Here is how a CNAME record looks (this is an example, not real output):

www.example.com.   CNAME   example.com.

This says: "www.example.com is another name for example.com. Wherever that goes, I go too."

Why use a name instead of an IP?

If your server's IP address changes, you update one A record, and every CNAME pointing to that name follows automatically. It's also how many services work. Platforms like Hashnode or GitHub Pages often give you a name to point your subdomain (like www) to, not a fixed IP.

A vs CNAME

Rule of thumb: if you have an IP address, use A. If you have a name, use CNAME.

One catch: a CNAME usually can't be used on the bare domain (example.com), only on names like www.

MX Record

Your website and your email are two separate things, and they often live on different servers. So when someone sends an email to hello@example.com, how does their email system know where to deliver it? That's what the MX (Mail Exchange) record is for. It tells the world which mail server receives email for your domain.

Real-life comparison: Think of an apartment building. Visitors use the main gate (the A record), but couriers and letters go straight to the mailroom. The MX record tells everyone where the mailroom is.

Here is the real output I got by running nslookup -type=MX google.com in my terminal:

google.com      MX preference = 10, mail exchanger = smtp.google.com

This line has a priority number (10) and a mail server name (smtp.google.com). The lower number is tried first. Many domains list two or more mail servers with different numbers, so if the first one is down, email falls back to the next one. Google uses just one here, but it is a big setup behind that single name.

The diagram uses a typical setup with two mail servers. Google's real output above has one.

NS vs MX

At first, these two looked the same to me, because both are "server records". Here is how I separate them:

• NS answers: "Who manages the DNS records for this domain?" It's the post office in charge of the area.

• MX answers: "Where should this domain's email be delivered?" It's the mailroom for your letters.

NS tells you who to ask. MX is one of the answers they give.

TXT Record

The TXT (Text) record is a notes field. It doesn't send visitors or emails anywhere. It just says something about your domain, and other services read it. You'll mostly see it in two places:

• Domain verification. Services like Google ask you to add a specific text value to prove you own the domain.

• Email security. Records like SPF list which servers are allowed to send email on behalf of your domain, which helps stop people from faking emails from it.

Real-life comparison: Think of a notice on the gate of a housing society. It doesn't change where anyone goes, but it tells you something about the place. An SPF record is like a guest list at that gate: only the names on the list are allowed in.

Here is the real output I got by running nslookup -type=TXT google.com in my terminal. Google has 17 TXT records, so I'm showing just four:

google.com      text =

        "v=spf1 include:_spf.google.com ~all"
google.com      text =

        "google-site-verification=TV9-DBe4R80X4v0M4U_bd_J9cpOJM0nikft0jAgjmsQ"
google.com      text =

        "facebook-domain-verification=22rm551cu4k0ab0bxsw536tlds4h95"
google.com      text =

        "apple-domain-verification=30afIBcvSuDV2PLX"

The first line is an SPF record. It says only Google's own mail servers (_spf.google.com) are allowed to send email for google.com. The other three are verification records: Google, Facebook, and Apple each asked for a specific text value to confirm that this domain belongs to the same owner.

A domain can have many TXT records, because every service you connect adds its own note. That's why the full output looked so messy to me at first.

How all records work together

Remember the contact card from earlier? Here is the full card for a small website, example.com. Each row is one entry, and each entry answers one question.

Here is what happens in real life, using the same records:

1. A visitor opens your site. The NS records tell DNS who to ask. The A or AAAA record gives the server's address. If the visitor typed www.example.com, the CNAME sends the lookup to the main name first. Then the browser connects to the server and loads the page.

2. Someone emails you. Their mail system looks up your MX record and delivers the message to your mail provider.

3. Gmail receives a message that claims to be from you. It checks your TXT record (SPF) to see if the sender is allowed.

Same domain, different questions, different records. Once I saw it this way, the DNS settings page stopped looking scary.

Try it yourself

You can look up all of these records yourself. Open your terminal and run:

nslookup -type=NS google.com
nslookup -type=A google.com
nslookup -type=AAAA google.com
nslookup -type=MX google.com
nslookup -type=TXT google.com

On Mac or Linux you can also use dig google.com MX. Try it on your own domain or a site you like.

Here is what I found for google.com:

You can spot each record by one keyword in the output:

Recap

Final thoughts

So, how does a browser know where a website lives? It asks DNS. DNS finds the right name servers (NS), then reads the answer from the right record: A, AAAA or CNAME for the website, MX for email, and TXT for verification.

DNS looked scary to me at first, with all those acronyms. But each record is just one small answer to one small question. Once you know the question, the record makes sense.

I'm learning full-stack development, so my next post goes one level deeper: how DNS resolution works, from root servers to the final answer, using dig.

Which record confused you the most? Tell me in the comments, and I'll try to explain it better.

When I started building backend APIs, I didn’t think much about HTTP status codes. If the API worked, I returned 200 OK. If something failed, I returned 500. That was my entire system. And honestly, I thought it was fine. But while working on my workspace project, I started noticing something—my APIs were working, but they didn’t feel right. That’s when I went deeper into HTTP status codes… and realized I was doing it wrong.

🔹The “200 for Everything” Phase

At the beginning, every response looked like this:

res.status(200).json({ message: "Something happened" });

Delete? → 200
Error? → 200
Not found? → 200

It worked… but it had no meaning.

I wasn’t communicating with the frontend properly—I was just sending responses.

---

🔹 The First Realization

The first time things clicked was when I learned about 404 Not Found.

Instead of sending a success response for everything, I started thinking:

“What if the resource actually doesn’t exist?”

if (!workspace) { 
 return res.status(404).json({message: "Workspace not found"});
}

That small change made my API feel more “real”.

🔹 The 204 Moment

Then came the biggest shift—DELETE APIs.

Earlier, I used to write:

res.status(200).json({ message: "Deleted successfully" });

But then I learned about 204 No Content.

It made me think:

“If the resource is deleted… why am I sending anything back?”

res.status(204).send();

That moment changed how I think about APIs.

It wasn’t just about making things work anymore—it was about making them correct.

🔹 Confusion: 401 vs 403

Another thing that confused me a lot was 401 vs 403.

I used them randomly at first.

Then realization:

But later I understood:

• 401 → User is not logged in

• 403 → User is logged in but not allowed

That distinction helped me design better authentication logic.

🔹 My Current Approach

Now, whenever I write an API, I don’t just think:

“Does it work?”

I think:

“Is this the correct response?”

”

👉 mindset shift:

• 200 → Data returned

• 201 → Resource created

• 204 → No content needed

• 4xx → Client mistake

• 5xx → My mistake

🔹 What I Learned

This journey taught me something important:

Backend development is not just about logic—it’s about communication.

HTTP status codes are the language your API uses to talk to the client.

🔹 Final Thoughts

I’m still learning, still making mistakes.

But small improvements like using the right status codes make a huge difference.

From “just making APIs work” → to “building clean and meaningful APIs”

That’s been my real progress.

📢 CTA

If you’re learning backend like me, don’t ignore these small details—they matter more than you think.

Let’s keep improving 🚀