The Address Book of the Web: Understanding DNS Records
Learning A, CNAME, MX, and TXT records by looking inside a real developer’s domain configuration.
How does a browser know where a website lives?
If you type himanshubalani.com into your browser and press Enter, your computer faces an immediate problem. It has no idea what or who "himanshubalani" is. Computers don’t understand words; they understand numbers. Specifically, they route traffic using IP addresses like 184.193.118.123.
To bridge this gap, we use the Domain Name System (DNS). You will often hear DNS described as the "phonebook of the internet." You look up a human-friendly name (a domain), and the phonebook gives you the machine-friendly number (the IP address).
Learn more about here - How the Internet Routes Your Requests with DNS
But a domain name isn't just a single destination. Modern domains act more like an entire office building. You might want your main website hosted on GitHub, your blog hosted on Hashnode, a side project hosted on Vercel, and your emails routed to Gmail.
To make all of this work simultaneously, the DNS "phonebook" doesn't just hold one number. It holds different types of records.
Let’s open up the actual DNS settings for my personal domain, himanshubalani.com, and use it to understand what each DNS record does and why it exists.
The NS Record: The Receptionist
NS stands for Name Server.
Before anyone can read your DNS records, they need to know who is storing them. When you buy a domain from a registrar (like Porkbun, Namecheap, or GoDaddy), an NS record is created. It essentially says: "If you want to know anything about himanshubalani.com, go ask Porkbun's servers. They have the master list."
What problem it solves: It delegates authority. It tells the global internet exactly which server holds your specific configuration.
The A Record: The Street Address
A stands for Address.
This is the most fundamental DNS record. It points a domain name directly to an IPv4 address (the classic format like 192.168.1.1).
When you visit my main portfolio, my DNS contains four A records:
Type Host Answer
A himanshubalani.com 185.149.118.161
A himanshubalani.com 185.149.119.161
A himanshubalani.com 185.149.111.161
A himanshubalani.com 185.149.112.161
Why four? My main site is hosted on GitHub Pages. GitHub gives me four different IP addresses for redundancy. If server 108.149 goes down, the browser simply tries 119.161.
What problem it solves: It tells the browser the exact server machine to connect to.
The AAAA Record: The Modern Street Address
AAAA (Quad-A) works exactly like an A record, but for IPv6 addresses.
We are running out of traditional IPv4 addresses, so the internet created IPv6 (which looks like 2001:0db8:85a3:0000:0000:8a2e:0370:7334). AAAA records exist simply to map a domain to these newer, longer addresses.
The CNAME Record: The Alias
CNAME stands for Canonical Name.
Instead of pointing to an IP address (a number), a CNAME points a domain to another domain name. Think of it as an alias or a forwarder.
I use subdomains to organize my projects. I don't want to manage the underlying IP addresses for all of these platforms, because if they change their server IPs, my websites would break. Instead, I use CNAMEs:
Type Host Answer
CNAME blog.himanshubalani.com hashnode.network
CNAME album.himanshubalani.com 238787b997276420.vercel-dns-017.com.
When you type blog.himanshubalani.com, DNS looks at the CNAME and says: "I don't have the IP address, but hashnode.network does. Go ask them." The browser seamlessly follows the path to Hashnode's servers.
A vs CNAME (The beginner confusion):
An A Record must point to an IP address (
185.149.118.161) .A CNAME Record must point to a Domain Name (
hashnode.network).You cannot put an IP address inside a CNAME.
The MX Record: The Mailroom
MX stands for Mail Exchange.
Web traffic (HTTP) and email traffic (SMTP) are two totally separate things. When you send an email to hello@himanshubalani.com, the sending email server doesn't care about my A records. It only looks for MX records.
Type Host Answer Priority
MX himanshubalani.com fwd1.porkbun.com 10
MX himanshubalani.com fwd2.porkbun.com 20
These records tell the world: "If you have an email for this domain, hand it over to Porkbun's mail servers." (The Priority number just tells it which server to try first).
NS vs MX (The beginner confusion):
NS tells the internet who manages your DNS settings.
MX tells the internet where to deliver your emails.
The TXT Record: The ID Badge and Sticky Notes
TXT stands for Text.
TXT records don't route traffic. They are simply sticky notes attached to your domain where you can write arbitrary text. Today, they are primarily used for verification and security.
When I set up Google Search Console, Google needed to know I actually owned the domain before giving me analytics. They asked me to add a TXT record with a secret code:
Type Host Answer
TXT himanshubalani.com google-site-verification=oc6RfofjIQEq-Lk...
TXT pl.himanshubalani.com peerlist-domain-verification=uh3a6a0z...
Google checks my DNS, sees the code, and says, "Okay, you definitely own this bro. my bad"
TXT records are also vital for email security. I have a TXT record starting with v=spf1. This is a security policy that tells other email providers (like Gmail) exactly which servers are legally allowed to send emails on my behalf, preventing spammers from spoofing my address.
Pulling It All Together
When you look at a DNS dashboard for the first time, it looks like a random spreadsheet. But once you understand the pieces, it reveals a beautifully modular system.
With one single $10 domain (himanshubalani.com), I am simultaneously:
Hosting my portfolio on GitHub (A Records)
Running a blog on Hashnode (CNAME)
Receiving custom emails through Porkbun (MX)
Proving my identity to Google and Peerlist for custom domain integration and SEO optimzation (TXT)
DNS is not magic. It is just a public spreadsheet. Your browser asks a question, the spreadsheet provides the answer, and the internet connects the dots.
