DNS Record Types Explained
Introduction
In my previous blog post, I talked about DNS and how it works. Now I'm going to extend that by explaining what DNS record types are, how many there are, what functions they provide, and we'll use the dig command to find out the whole journey taken by DNS resolution.
List of DNS Records
Here are the mainly used DNS record types:
A
AAAA
NS
CNAME
MX
TXT
Let's understand each one.
A Record
A record means Address Record.
An A record is a type of record which holds the final IPv4 address of the domain name requested. This is the final step in DNS resolution where the DNS resolver stops.
Using dig to find A records
dig google.com A
Let's see what we get:
dev@DellOfDev:~$ dig google.com A
; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> google.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49974
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 6 IN A 64.233.176.102
google.com. 6 IN A 64.233.176.113
google.com. 6 IN A 64.233.176.101
google.com. 6 IN A 64.233.176.138
google.com. 6 IN A 64.233.176.139
google.com. 6 IN A 64.233.176.100
;; Query time: 49 msec
;; SERVER: 10.255.255.254#53(10.255.255.254) (UDP)
;; WHEN: Sat Jan 24 15:53:48 IST 2026
;; MSG SIZE rcvd: 135
Here you can see we get multiple IPv4 addresses for google.com, which is useful for load balancing. We can also see:
How much time it took to resolve the query (49 msec)
Which DNS server was used (10.255.255.254)
Which protocol was used (UDP)
AAAA Record
An AAAA record does the exact same thing as an A record, but for IPv6 addresses instead of IPv4.
Using dig to find AAAA records
dig google.com AAAA
Result:
;; ANSWER SECTION:
google.com. 185 IN AAAA 2404:6800:4009:810::200e
This returns the IPv6 address of the domain.
NS Record
NS record stands for Name Server record.
Name servers are the servers which hold information about other DNS servers who manage the domain name. NS records have all the records for CNAME, MX, and A records for other authoritative DNS servers.
All DNS queries are dependent on name servers. Name servers don't give the final answer/address—they give you another server's IP who is capable of giving the address.
Each DNS and domain management company has their own name servers, like Google and Cloudflare.
Using dig to find NS records
dig google.com NS
You will get something like this:
;; ANSWER SECTION:
google.com. 8355 IN NS ns1.google.com.
google.com. 8355 IN NS ns2.google.com.
google.com. 8355 IN NS ns3.google.com.
google.com. 8355 IN NS ns4.google.com.
This tells you that Google has 4 name servers managing their domain.
CNAME Record
CNAME stands for Canonical Name (like a nickname).
It is used to point a domain name or subdomain to another existing domain name, not to an IP address.
For example, let's say we already have www.example.com and we want to add a new subdomain blog.example.com to go to example.com. We can add a CNAME record.
You might be thinking: "blog.example.com is going to the same IP as example.com, so why can't we just add another A record for blog.example.com?" That is one way, but when your server's IP changes, you have to manage both A records yourself.
Also, if you're thinking example.com and blog.example.com both go to the main page like "/", but you want to show a different page for blog.example.com, you can do that using web servers like Nginx or Apache.
Using dig to find CNAME records
dig blog.piyushgarg.dev CNAME
Result:
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;blog.piyushgarg.dev. IN CNAME
;; ANSWER SECTION:
blog.piyushgarg.dev. 300 IN CNAME hashnode.network.
CNAME is also useful for cases where you already own a domain name and you want to point a subdomain to another third-party domain name which you don't own.
MX Record
MX stands for Mail Exchange.
It is used for receiving emails. When a user sends an email, the MX record is responsible for transferring it to the correct mail server of the receiver.
MX records answer the question: "Where should emails for the given domain be delivered?"
For example, if you want to send an email to someone@gmail.com, the MX record returns the mail server which handles SMTP and shows your mail.
Important: MX records return the domain name of the mail server, not the IP address.
Also, mail servers have a priority number before the domain. This is useful for load balancing. Whichever server has the lower priority number is used first.
Using dig to find MX records
dig gmail.com MX
Result:
;; ANSWER SECTION:
gmail.com. 2921 IN MX 5 gmail-smtp-in.l.google.com.
gmail.com. 2921 IN MX 10 alt1.gmail-smtp-in.l.google.com.
gmail.com. 2921 IN MX 20 alt2.gmail-smtp-in.l.google.com.
gmail.com. 2921 IN MX 30 alt3.gmail-smtp-in.l.google.com.
gmail.com. 2921 IN MX 40 alt4.gmail-smtp-in.l.google.com.
The server with priority 5 will be tried first, then 10, then 20, and so on.
TXT Record
TXT stands for Text Record.
TXT records are used to store arbitrary text information about a domain. These records are useful for:
Domain verification - Proving you own a domain to services like Google, Microsoft, etc.
Email security - Implementing SPF, DKIM, and DMARC to prevent email spoofing
General notes - Any text-based information you want to associate with your domain
Using dig to find TXT records
dig google.com TXT
Result:
;; ANSWER SECTION:
google.com. 300 IN TXT "v=spf1 include:_spf.google.com ~all"
google.com. 300 IN TXT "facebook-domain-verification=22rm551cu4k0ab0bxsw536tlds4h95"
google.com. 300 IN TXT "docusign=05958488-4752-4ef2-95eb-aa7ba8a3bd0e"
google.com. 300 IN TXT "google-site-verification=wD8N7i1JTNTkezJ49swvWW48f8_9xveREV4oB-0Hf5o"
As you can see, Google uses TXT records for:
SPF email authentication
Facebook domain verification
DocuSign verification
Google site verification
Tracing the Complete DNS Journey
Now let's see the complete journey a DNS query takes from start to finish using the +trace option with dig.
dig google.com +trace
This command shows you every step of the DNS resolution process:
; <<>> DiG 9.18.33 <<>> google.com +trace
;; global options: +cmd
. 86400 IN NS a.root-servers.net.
. 86400 IN NS b.root-servers.net.
. 86400 IN NS c.root-servers.net.
[... more root servers ...]
;; Received 239 bytes from 10.255.255.254#53(10.255.255.254) in 12 ms
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
[... more TLD servers ...]
;; Received 1173 bytes from 192.5.5.241#53(a.root-servers.net) in 145 ms
google.com. 172800 IN NS ns1.google.com.
google.com. 172800 IN NS ns2.google.com.
google.com. 172800 IN NS ns3.google.com.
google.com. 172800 IN NS ns4.google.com.
;; Received 844 bytes from 192.12.94.30#53(e.gtld-servers.net) in 234 ms
google.com. 300 IN A 142.250.193.206
;; Received 55 bytes from 216.239.36.10#53(ns2.google.com) in 45 ms
Understanding the Journey
Let's break down what happened:
Step 1: Root DNS Servers (.)
. 86400 IN NS a.root-servers.net.
Your DNS resolver first contacts one of the 13 root DNS servers. These are the top of the DNS hierarchy and know about all TLD (Top Level Domain) servers.
Step 2: TLD DNS Servers (com.)
com. 172800 IN NS a.gtld-servers.net.
The root server responds with the NS records for the .com TLD servers. Your resolver then queries one of these TLD servers.
Step 3: Authoritative Name Servers (google.com)
google.com. 172800 IN NS ns1.google.com.
The TLD server responds with the NS records for google.com's authoritative name servers. These are Google's own name servers that have the actual records.
Step 4: Final Answer (A Record)
google.com. 300 IN A 142.250.193.206
Finally, Google's name server responds with the actual IP address of google.com.
The Complete Flow
Computer / Browser
↓
Local DNS Resolver (10.255.255.254)
↓
Root DNS Server (a.root-servers.net) - "Ask the .com servers"
↓
TLD DNS Server (e.gtld-servers.net) - "Ask Google's name servers"
↓
Authoritative Name Server (ns2.google.com) - "Here's the IP: 142.250.193.206"
↓
Back to Your Computer - Connection established!
Each step took time:
Root server: 145 ms
TLD server: 234 ms
Authoritative server: 45 ms
This is why DNS caching is so important without it, every request would take this long!
Conclusion
DNS records are the backbone of how the internet works. Each record type serves a specific purpose:
A/AAAA records give you the final IP address (IPv4/IPv6)
NS records point you to authoritative name servers
CNAME records create aliases for easier management
MX records route emails to the right mail servers
TXT records provide verification and security information
The dig command is a powerful tool to explore and understand DNS. Using +trace, you can see the complete hierarchical journey from root servers to the final answer. This understanding helps you debug DNS issues, configure domains correctly, and appreciate the elegant system that makes the internet work seamlessly.
Next time you type a domain name and it just works, you'll know the incredible journey happening behind the scenes in milliseconds.