A Beginner-Friendly Guide to DNS and DNS Records: How Websites Are Found
When you type a website like:
www.example.com
into your browser, a surprisingly big question is hiding behind it:
How does the browser know where this website actually lives on the internet?
The answer to that question is DNS.
In this article, we’ll break DNS down slowly, simply, and clearly, without scary jargon. By the end, you’ll understand what DNS records are, why they exist, and how they all work together for a real website.
What Is DNS? (In Very Simple Terms)
DNS (Domain Name System) is the phonebook of the internet.
Humans like names:
google.com
youtube.com
hashnode.com
Computers like numbers:
142.250.207.206
DNS is the system that translates human-friendly domain names into computer-friendly IP addresses.
Analogy:
DNS is like saving contacts on your phone.
Instead of remembering:
+91 98xxxxxxx
You save:
Buddy
DNS does the same thing for websites.
Why Are DNS Records Needed?
A single domain doesn’t just do one job.
A domain may need to:
Show a website
Handle emails
Point one name to another
Prove ownership to services like Google, GitHub, Netlify, etc.
DNS records exist to solve different problems*, not just one.*
Each DNS record answers a specific question like:
“Where is the website hosted?”
“Where should emails go?”
“Who controls this domain?”
What Is an NS Record? (Who Is Responsible for a Domain)
NS = Name Server
An NS record tells the internet:
“These servers are responsible for answering all DNS questions for this domain.”
Think of NS records as:
The office that holds all official records for your house
If someone asks:
“Where does example.com live?”
The internet first checks:
“Which name server is in charge of example.com?”
Example:
example.com → NS → ns1.cloudflare.com
example.com → NS → ns2.cloudflare.com
This means:
Cloudflare is the authoritative DNS provider for this domain
Simple DNS hierarchy:
Root (.)
└── .com
└── example.com
└── Cloudflare Name Servers (NS)
What Is an A Record? (Domain → IPv4 Address)
A = Address
An A record maps a domain name to an IPv4 address.
Example:
example.com → A → 93.184.216.34
Analogy:
Your domain name is your house name,
Your IP address is your street address.
Without an A record, the browser wouldn’t know where to go.
Diagram:
Browser
↓
example.com
↓ (A Record)
93.184.216.34
↓
Web Server
What Is an AAAA Record? (Domain → IPv6 Address)
AAAA record is the same idea as an A record, but for IPv6.
Why IPv6?
Because we’re running out of IPv4 addresses.
Example:
example.com → AAAA → 2606:2800:220:1:248:1893:25c8:1946
Many websites have both A and AAAA records.
The browser picks the best one it supports.
What Is a CNAME Record? (One Name Pointing to Another)
CNAME = Canonical Name
A CNAME does not point to an IP.
It points to another domain name.
Example:
www.example.com → CNAME → example.com
This means:
“Wherever example.com goes, www.example.com goes too.”
Analogy:
A nickname that forwards to a real contact.
CNAME diagram:
www.example.com
↓
example.com
↓
A / AAAA Record
↓
IP Address
Common confusion :
A record vs CNAME
A record → points to an IP
CNAME → points to another name
You cannot have both on the same name.
What Is an MX Record? (How Emails Find Your Mail Server)
MX = Mail Exchange
MX records tell the internet:
“If someone sends email to this domain, send it here.”
Example:
example.com → MX → mail.google.com
Analogy:
Your house address is the same,
but letters go to a post office, not your living room.
Email flow:
Someone sends email to you@example.com
↓
Check MX record
↓
Mail server (Gmail, Outlook, etc.)
Common confusion:
NS vs MX
NS → who controls DNS
MX → who handles email
They solve completely different problems.
What Is a TXT Record? (Extra Info & Verification)
TXT records store text information about your domain.
They are commonly used for:
Domain ownership verification
Email security (SPF, DKIM, DMARC)
Service authentication (Google, GitHub, Netlify)
Example:
example.com → TXT → "google-site-verification=abc123"
Analogy:
A written note on your door saying:
“Yes, I own this house.”
TXT Record? (Verification, Security, and Policies)
A TXT (Text) record is a DNS record that stores plain text information for a domain.
At first, this sounds confusing because TXT records don’t point to an IP address or a server.
Instead, TXT records are mainly used to prove domain control and to publish rules or policies about how a domain should be used.
What does “verification” actually mean?
When services talk about verification, they simply mean:
Proving that you own or control a domain’s DNS settings.
TXT records are used for this because:
Only the real domain owner can add or change DNS records
So if you can add a specific TXT value, you’ve proven control
This is not about identity, encryption, or secrecy — it’s just proof of control.
A very simple real-life analogy
Think of your domain as a house:
Domain → the house
DNS → the lock and keys
TXT record → a secret note placed inside the house
If a service says:
“Put this exact note inside your house”
And you successfully do it,
The service knows:
You must own the house.
That’s how TXT verification works.
Example: Domain ownership verification (Google, GitHub, Netlify)
A service may ask you to add a TXT record like:
example.com TXT "service-verification=abc123"
What the service does:
Looks up the TXT records for
example.comChecks for its unique value
If it finds it → domain control verified
Nothing is encrypted or hidden — it’s just proof that you control DNS.
Example: SSL certificates (HTTPS)
Certificate authorities like Let’s Encrypt may ask for:
_acme-challenge.example.com TXT "random-token"
They check:
“Can I see my token in DNS?”
Yes → you control the domain → SSL certificate issued
No → certificate request denied
Example: Email security rules (SPF, DKIM, DMARC)
TXT records are also used to publish email policies.
For example, an SPF record:
v=spf1 include:_spf.google.com ~all
This tells receiving mail servers:
“Only these servers are allowed to send email for this domain.”
If an email comes from an unauthorized server, it may be marked as spam or rejected.
Important thing to remember
TXT records do not tell browsers where to go.
TXT records do not host websites.
They exist to:
Prove domain control
Publish security and usage rules
TXT verification = “Show me you control DNS.”
That’s why TXT records are trusted across the internet.
How All DNS Records Work Together (One Website Example)
Let’s imagine a small website using:
Cloudflare for DNS
Netlify for hosting
Google Workspace for email
Complete DNS setup:
example.com
NS:
ns1.cloudflare.com
ns2.cloudflare.com
A:
example.com → 75.2.60.5
CNAME:
www.example.com → example.com
MX:
example.com → aspmx.l.google.com
TXT:
"v=spf1 include:_spf.google.com ~all"
What happens when a browser loads the site?
Browser
↓
Find NS record
↓
Ask authoritative DNS server
↓
Get A / AAAA record
↓
Connect to server
↓
Website loads
DNS may look confusing at first, but it’s really just:
Names
Addresses
Responsibilities
Each DNS record answers one clear question:
NS: Who is in charge?
A / AAAA: Where is the website?
CNAME: Is this name pointing somewhere else?
MX: Where should emails go?
TXT: Extra proof and instructions
Once you see DNS as a system of responsibilities, not magic, it starts to feel very logical.
