# DNS Record Types Explained ## **What DNS is actually?** DNS, which stands for Domain Name System, is what allows humans to use simple and readable website names instead of remembering numeric IP addresses. When you type a website name like [`google.com`](http://google.com/) into your browser, your computer cannot understand that name by itself. Computers communicate using IP addresses, which are long numbers. DNS acts as a translator between these two worlds. It takes the name you type and finds the correct IP address that points to the server where the website is hosted. Without DNS, the internet would still exist, but using it would be extremely difficult because everyone would have to remember numerical addresses instead of names. ## **Why DNS records are needed** DNS records are needed because a domain does much more than just show a website. A single domain can host a website, receive emails, prove ownership to services, and apply security rules. DNS records are the instructions that tell the internet how each of these things should work. When a browser wants to load a website, it relies on DNS records to know which server to connect to. When an email is sent to a domain, mail servers use DNS records to decide where that email should be delivered. Security systems also read DNS records to verify whether emails are legitimate and whether a domain is properly configured. Let us understand some of the important records one by one. ## **1\. NS Record** An NS record (Name Server Record) tells the internet which DNS servers are responsible for a domain or DNS zone. In simple words it tells, If you want DNS information about this domain, ask this servers. So NS record contains only the name of a DNS server, not its IP address any it typically looks like below. ```plaintext google.com. 71030 IN NS ns4.google.com. google.com. 71030 IN NS ns1.google.com. google.com. 71030 IN NS ns2.google.com. google.com. 71030 IN NS ns3.google.com. ``` Now question might comes in your mind that why don’t we return just an IP of the server rather then giving another domain. Right? This because to keep DNS flexible, maintainable, and scalable. Let say if NS records stored only IP addresses Then also some more problems can come like, Every time a DNS server’s IP changes every parent zone (root, TLD, authoritative) would need to update it and cached data across the internet would break. so because of this implemented pattern if IP changes then nothing would break as domain remains same. As single DNS server name often maps to many IPs, AnyCast clusters worldwide. Now there is one big question might arise in your mind like if [**google.com**](http://google.com/) have NS record like IN NS [**ns4.google.com**](http://ns4.google.com/). does it not create infinite loop as we again going to get same NS record while resolving NS [**ns4.google.com**](http://ns4.google.com/) to get IP of it. So this problem never caused issue because when parent zone delegates to child name servers inside the same domain, it also provides glue records like below to not to get in loop. ```plaintext ns1.google.com → ns2.google.com → ns3.google.com → ns4.google.com → ``` Thing to understand is that glue records are not always given in scenarios like, where DNS domain and domain to resolve are not have same parent. ```plaintext google.com. 71030 IN NS ns3.cloudflare.com. ``` ## **2\. A Record** This is the Record for the you may be started thinking about DNS. Basically this A Record is responsible for having the IP of the actual domain. Means if you are finding IP of [**google.com**](http://google.com/) then A record will going to have IP of [**google.com**](http://google.com/). A record act as a the final step in DNS resolution, converting a name into a usable network address. They always answer simple questions that is where is this service hosted? A records are always stored on authoritative DNS servers for a domain. Means .com TLD does not store A records for [**google.com**](http://google.com/) but google’s authoritative DNS servers do. Now there one similar record to A is AAAA Record which is nothing but IPv6 address of domain. One thing to understand is that a domain can have multiple A records for the load balancing purposes. ```plaintext example.com A 192.0.2.1 example.com A 192.0.2.2 ``` So here when resolver reach authoritative servers they will return all the A records means multiple IP then your resolver return to browser all of this IP often its shuffled and then your browser try to connect one by one to each IP. If it connects to first IP and connection was successful then it will not try another IPs. Also there TTL (TTL = N seconds) attached to every A record that means the TTL (time to leave) will decide for how much time you can cache the IP or may be recheck after TTL expires. ## **3\. AAAA Record** Now there one similar record to A is AAAA Record which is nothing but IPv6 address of domain. An AAAA record maps a domain name to an IPv6 address, enabling IPv6 connectivity on the internet. ```plaintext example.com AAAA 2001:db8::1 example.com AAAA 2001:db8::2 ``` ## **4\. CNAME Record** The CNAME Record (canonical name record) makes one domain name an alias of another domain names. Means, This name is just another name for that name like, ```plaintext www.google.com CNAME google.com ``` Here real(canonical) name is [**google.com**](http://google.com/). The flow goes like resolver asks for [**www.google.com**](http://www.google.com/) and DNS replies [**www.google.com**](http://www.google.com/) CNAME [**google.com**](http://google.com/) and then resolver start resolving [**google.com**](http://google.com/) and get final A / AAAA record of an [**google.com**](http://google.com/). Now you might think why there is need of an CNAME record why don’t we just point every domain’s which are pointing to same domain then use IP of that domain. Like why do [**www.google.com**](http://www.google.com/) CNAME [**google.com**](http://google.com/) not [**www.google.com**](http://www.google.com/) A 192.192.1.1. It will solve the problem right? Here we are partially correct. Because the real reason why CNAME record exist is because let say we have 10 different domain have same A record and if change our IP which we referenced in every domain’s A record then we need to change at every domain. But if we only pointed CNAME record then we just change IP of that domain to whom we are applying in CNAME record of another domains. And one thing we need to keep in mind that the root level domain like ([**google.com**](http://google.com/), [**example.com**](http://example.com/)) cannot have CNAME record as it is DNS rule that you cannot have CNAME record for those domain who have any another records. And every root level domain always have NS record and some other record and there is no bypass from this condition. You might also come across some record like ALIAS/ANAME but this are not real DNS record but just a tricked by DNS provider. Let say when you do something like, ```plaintext google.com ALIAS cdn.provider.net ``` Here the DNS provider itself resolves [**cdn.provider.net**](http://cdn.provider.net/) and get its A/AAAA Its and return to the world like, ```plaintext google.com A ``` ## **5\. MX Record** Now this record is very important record not in terms of your websites domain but rather then for your email service. An MX record (mail exchange record) tell the internet which mail server should receive email for a domain. In simple words, Email for this domain must be delivered to these mail servers. ```plaintext google.com. MX 10 mail1.google.com. google.com. MX 20 mail2.google.com. ``` This above records tells sender server that email should be sent to this above mail servers. Let say you own email [**support@zodiya.net**](mailto:support@zodiya.net) and someone writes an email to you so if you haven’t configured your MX records then that email would not be delivered to you at all as you not specified the mail server to be delivered. Just one thing we need to understand is that MX records answer the question: “Which server accepts mail for this domain?” The number attached to MX record is indicated the priority to be get email, the lower number the highest it get priority. MX records always point to domain names, not IP address and the reason same as NS records: flexibility and IP changes. Always remember that you need MX records to receiving emails not for sending emails without configured it you still able to send email but won’t be able to receive it. Now Lets see some of the important records that are linked to your email services which you need to configured for smooth flow. ### **A. SPF (Sender Policy Framework)** Now before SPF existed, any server on the internet could pretend to send email from your domain. ([**support@zodiya.net**](mailto:support@zodiya.net)) but the email was might be send from the attackers server. At that time email servers had no way to verify if that server was allowed to send mail from [**zodiya.net**](http://zodiya.net/). So SPF solved the this problem. Now you think what SPF actually is? SPF is a public list of servers that are allowed to send email for your domain and that list published in DNS. SPF is stored as TXT Records (will look into this later) in your domain’s DNS. ```plaintext zodiya.net TXT "v=spf1 include:_spf.google.com ~all" ``` This is not random text but it is a policy. So now when email arrives and claiming to be from [**support@zodiya.net**](mailto:support@zodiya.net) then receiver mail server look at the IP address of the server from the email came and extract the domain from the MAIL FROM/RETURN-PATH and query DNS like ```plaintext TXT zodiya.net ``` And then reads the SPF rules and check if the sender’s IP is allowed. That’s it. You need to understand that what we think in mind that if I have login of email server of [**support@zodiya.net**](mailto:support@zodiya.net) then I am the only person can send email from [**support@zodiya.net**](mailto:support@zodiya.net). Actually the email address to be we are thinking as secure or authentic source is nothing but just an header. Like any email server can send email with header like from: [**support@zodiya.net**](mailto:support@zodiya.net) using SMTP. And there is only SPF record which can make this transaction trust worthy as if that server is not allowed in the of SPF then the mail will land in spam. ### **B. DKIM** Even if SPF passes, there still big problem: 1. How do we know the email was not modified while traveling across the internet? 2. How do we know the sender is really who they claim to be? As email can pass through multiple servers, Filters, Forwarders, Gateways and any of these can modify header, modify content or may be resend the message. So DKIM solves authenticity and integrity. So DKIM is a digital signature added to an email that proves two things: 1. The email was send by an authorised server for the domain 2. The email content was not altered after it was signed. Actually DKIM has parts: 1. Private key: Stored on the sending mail server and used to sign outgoing emails 2. Public Key (Published in DNS): Stored as TXT record and used by receivers to verify the signature ### **C. DMARC (Domain-based Message Authentication, Reporting & Conformance)** Even with **SPF** and **DKIM**, email servers still had one unanswered question: **What should I do if these checks fail? And how do I know the visible “From” address is trustworthy?** This is where **DMARC** comes in. ### **What DMARC actually does** **DMARC ties SPF and DKIM together and enforces a policy.** It tells receiving mail servers: * Whether SPF or DKIM **must pass** * Whether they must be **aligned** with the visible `From` domain * What action to take if checks fail * Where to send reports about failures DMARC is also published as a **DNS TXT record**. ### **Example DMARC record** ```plaintext _dmarc.zodiya.net TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@zodiya.net" ``` Meaning: * `v=DMARC1` → DMARC version * `p=quarantine` → Put failed emails into spam * `rua` → Send aggregate reports to this email ### **Why DMARC is important** Without DMARC: * SPF or DKIM could fail silently * Receivers decide randomly what to do * Your domain can still be spoofed With DMARC: * You control enforcement (`none`, `quarantine`, `reject`) * Spoofed emails are blocked * You get visibility into who is sending mail using your domain ### **How SPF, DKIM, and DMARC work together** | Mechanism | Purpose | | --- | --- | | SPF | Who is allowed to send email | | DKIM | Was the email altered in transit | | DMARC | What to do if checks fail + domain alignment | **DMARC is the policy layer that enforces SPF and DKIM and tells receiving servers how to handle unauthenticated emails.** ## **6\. TXT Record** A TXT record is a DNS record used to store arbitrary text information for a domain, mainly for verification, authentication and policy instructions. In simple words, A TXT record lets a domain publicly publish rules or proofs that others systems can read and verify. TXT records reuse DNS as public bulletin board where domain owners can publish machine-readable instructions. This TXT records are used in many way like authentication (SPF, DKIM, DMARC) and also for domain ownership verification like ([**zodiya.net**](http://zodiya.net/) TXT "google-site-verification=abcd1234”) like this proves I control DNS for this domain. You also might wonder that why not create a new DNS record type for everything? The reason is DNS record types require global standardisation and TXT is flexible and already supported. They are easy to deploy without breaking old systems. A domain can have multiple TXT records and order usually does not matter. Systems look for specific prefixes (v=spf1, v=dmarc1). ## **How all DNS records work together for one website** For a single website, **different DNS records serve different responsibilities**, and together they make the site reachable, reliable, and secure. * **A / AAAA records** tell browsers **where the website lives** by mapping the domain to IPv4 and IPv6 addresses. * **CNAME records** allow subdomains (like `www`) to **alias** another hostname, making infrastructure changes easier. * **NS records** define **which DNS servers are authoritative** for the domain and control who can answer DNS queries. * **SOA record** defines **ownership and timing rules** for the DNS zone (refresh, retry, TTL). * **MX records** route **incoming emails** to the correct mail servers. * **TXT records** publish **policies and proofs**, such as SPF, DKIM, and DMARC, to secure email and verify domain ownership. * **ALIAS / ANAME** (provider-specific) allow root domains to behave like CNAMEs without breaking DNS rules.