# 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 ```bash dig google.com A ``` Let's see what we get: ```bash 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 ```bash dig google.com AAAA ``` Result: ```bash ;; 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 ```bash dig google.com NS ``` You will get something like this: ```bash ;; 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](http://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 ```bash dig blog.piyushgarg.dev CNAME ``` Result: ```bash ;; 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](mailto: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 ```bash dig gmail.com MX ``` Result: ```bash ;; 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 ```bash dig google.com TXT ``` Result: ```bash ;; 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. ```bash dig google.com +trace ``` This command shows you every step of the DNS resolution process: ```bash ; <<>> 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 (.)** ```bash . 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.)** ```bash 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)** ```bash 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)** ```bash 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 ```bash 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.