DNS Record Types Every Developer Should Know

Imagine this: it is the year 2047, and you want to shop online for shoes. You run to your laptop, scratching your head to recall the IP address of amazon.com. Somehow, you remember it, but when you enter it, the browser throws an error “ERR_NAME_NOT_RESOLVED.” You try once more, entering the correct IP from your 1000-page IP directory you maintained. And Eureka, this time the browser takes you to Amazon.

In this case every time you visit a website or web app on the internet, you have to manually input the correct IP addresses. Frightening, right?

But why worry when DNS is the query?

In simple terms, if the Internet is a building, then DNS is the elevator inside the building, taking you to different parts of the building based on the your input. If the Internet is a phone, DNS is its phonebook.

But what is this DNS ? Let’s Find out!!

---

WHAT IS DNS?

DNS is a tour guide in the wonderland of INTERNET. DNS or Domain Name Server is that critical part of the Internet that takes human-readable domain names, such as www.chaicode.com, and maps them to numeric IP addresses that are readable by machines. It is a great problem solver , isn’t it.

DNS is nothing less than a phonebook of the internet. Just as we save contacts in our telephone directory , similarly DNS maps the website domains to their respective IP addresses. Factually speaking there around 10 billion phone numbers in the world for 7 billion of humanity and more than 4 billion IP addresses present currently around the globe. Taking inspiration from phone book to create DNS mapping system was just incredible.

DNS always tells you “Whom to talk to next?”

We will see that in detail in the working of DNS Resolution.

Some main features of DNS are

• Recursive in nature

• Distributed or Decentralized (no single central database)

• Hierarchical or Delegated (structured in levels)

• Loosely Coupled ( system components unaware of each others internal working)

• Fault-tolerant (multiple servers, redundancy)

• Extremely fast (most lookups take milliseconds)

WHAT ARE DNS RECORDS AND WHY WE NEED THEM?

DNS Records are the set of instructions that live inside the authoritative name server , which determines the type of response of the DNS servers for a specific domain name to be resolved. These records consist of a series of text files written in a format of DNS syntax. DNS syntax is just a string of characters used as commands that tell the DNS server what to do.

But why do we need them?

Along with the IP address, every domain name has additional information associated with it. This information helps users access resources on that domain effectively.

One Domain Can Have Many Services

A single domain can be used for:

• A website

• Email

• APIs

• Chat or internal services

DNS records clearly define:

• Where the website is hosted —> IP address given by A record

• Which server receives emails —> MX Record and MTA

• Which services run on which servers

Without DNS records, all these services would conflict with each other.

A domain name by itself (like chaicode.com) doesn’t do anything.
DNS records tell the internet what that name means and what services are connected to it.

For example, the “MX” record helps mail servers understand where to deliver mail. A “TXT” record can provide additional information about the domain, such as ownership. As organizations scale, managing domain names, migrations and mail servers becomes crucial for maintaining key business functions.

---

DIFFERENT TYPES OF DNS RECORDS

1. A RECORD :

A stands for address . This is the most basic DNS Record . As the name suggest A record maps the domain name to its IP address . Precisely, IPV4 address. The ultimate goal of DNS is to find the A record of the domain to be queried. If we assume all the records in a hierarchical structure then A and AAAA record comes at the bottom.

When you enter chaicode.com into Google inside your browser, the DNS server returns an A record, i.e., the IP address associated with chaicode.com.

A records only hold IPv4 addresses. If a website has an IPv6 address, it will instead use an "AAAA" record.

Here is an example of an A record:

The "@" symbol in this example indicates that this is a record for the root domain, and the "14400" value is the TTL (time to live), listed in seconds. So TTL is the time interval value in DNS records that tells the computers how long they should remember (cache) a DNS record before asking again.

The default TTL for A records is 14,400 seconds. This means that if an A record gets updated, it takes 240 minutes (14,400 seconds) to take effect. The vast majority of websites only have one A record, but it is possible to have several. Some higher profile websites will have several different A records as part of a technique called round robin load balancing, which can distribute request traffic to one of several IP addresses, each hosting identical content.

---

2. AAAA RECORD:

The AAAA /Quad A Record is same as the A record. The only difference is that

• A Record maps IPv4 Addresses

• AAAA Record maps IPv6 Addresses

IPv6 is the latest version of the Internet Protocol. One of the important differences is that IPv6 addresses are longer than IPv4 addresses. The Internet is running out of IPv4 addresses (consist if only 32 bit ) , but IPv6 addresses (128 bit) offer exponentially more permutations and thus far more possible IP addresses.

---

3. CNAME RECORD:

The Canonical Name (CNAME) record allows you to alias one domain name to another. For example, blogs.virajexplains.com is aliased to virajexplains.com. All CNAME records must point to a domain, never to an IP address.

Imagine a treasure hunt where each clue points to another clue, and the final clue points to the treasure. A domain with a CNAME record is like a clue that can point you to another clue (another domain with a CNAME record) or to the treasure (a domain with an A record).

ALAISING IN CNAME RECORD

• For example, suppose blog.virajexplains.com has a CNAME record with a value of "virajexplains.com" . So when the DNS server queries blog.virajexplains.com then the CNAME record again queries the virajexplains.com and returns its A record that is the IP address . This IP address is valid for blog.virajexplains.com too.

• In this case we would say that example.com is the canonical name (or true name) of blog.example.com.

• Oftentimes, when sites have subdomains such as blog.example.com or shop.example.com, those subdomains will have CNAME records that point to a root domain (example.com).

• This way if the IP address of the host changes, only the DNS A record for the root domain needs to be updated and all the CNAME records will follow along with whatever changes are made to the root.

But if we think logically, if both domains are pointing towards the same IP address, won’t it take the client to the same webpage? So is there absolutely no difference between them?

No this is how CNAME record works . A frequent misconception is that a CNAME record must always resolve to the same website as the domain it points to, but this is not the case. The CNAME record only points the client to the same IP address as the root domain. Once the client hits that IP address, the web server will still handle the URL accordingly. So for instance, blog.example.com might have a CNAME that points to example.com, directing the client to example.com’s IP address. But when the client actually connects to that IP address, the web server will look at the URL, see that it is blog.example.com, and deliver the blog page rather than the home page.

Example of a CNAME record:

From the above example you can see that blog.example.com points to example.com.

---

4. MX RECORD

   Here MX stands for Mail Exchanger. The function of this record in simple terms is

“ to direct emails to the correct mail server of the domain” .

Without MX records, your domain cannot receive emails

The 'mail exchange' (MX) record points to a server where email should be delivered for that domain name . The MX record indicates how email messages should be routed in accordance with the Simple Mail Transfer Protocol (SMTP, the standard protocol for all email).

Example of an MX record: PRIORITIZATION

mailhost1.example.com is an email server. Likewise mailhost2.example.com is second email server. Both the email server have priorities assigned to them . the lower 'priority' value is preferred. The server will always try mailhost1 first because 10 is lower than 20. In the result of a message send failure, the server will default to mailhost2.

The email service could also configure this MX record so that both servers have equal priority and receive an equal amount of mail:

HOW ARE EMAILS DIRECTED TO CORRECT MAIL SERVERS?

• There is a software called MTA (Message transfer agent)

• (MTA) software is responsible for querying MX records. When a user sends an email, the MTA sends a DNS query to identify the mail servers for the email recipients. The MTA establishes an SMTP connection with those mail servers , starting with the prioritized domains .

• Hence the email sent to Tom@example.com is routed to its correct DNS Server.

---

5. NS RECORD

• So NS Record is the Name Server Record. This record is the most important record that indicates which DNS server is authoritative for that domain (i.e. which server contains the actual DNS records).

• Basically NS records tells the address of the respective DNS server which contains its IP address.

• Here is an example of an NS record:

  | example.com | record type: | value: | TTL | | --- | --- | --- | --- | | @ | NS | ns1.exampleserver.com | 21600 |

But don’t NS records live in side the auth name servers ? How can they point to something in which they live? If the resolver arises at the auth name servers then why would it need to again find it?

Hmmm ,Valid point .

Remember TLD Servers. These servers direct the resolver to the Authoritative name servers using these NS Records.

NS records exist at TWO DIFFERENT LEVELS

1. At the parent zone (TLD) → for delegation

2. Inside the authoritative zone itself → for self-identification

The resolver does NOT use the domain’s own NS records to find the authoritative server.

That would be impossible (chicken-and-egg problem).

Instead, it uses NS records stored at the PARENT zone. When the resolver at the TLD is directed to the authoritative name servers using these NS records (at the parent zone).

For example.com:

• The .com TLD servers store:

example.com  NS  anna.ns.cloudflare.com
example.com  NS  tom.ns.cloudflare.com

THESE ARE CALLED DELEGATION NS RECORDS

How TLD knows these NS records

When you change nameservers at the registrar:

• The registrar updates the TLD registry (.com)

• The registry stores NS records for your domain

• TLD servers now return those NS records to resolvers

Visual flow

ROOT (.)
 └── .com TLD
      └── example.com NS (delegation)
           ↓
     Cloudflare authoritative servers
           ├── A
           ├── MX
           ├── TXT
           ├── NS (authoritative copy)
           └── SOA

The NS Records present inside the auth name servers function is to declare, confirm, and validate authority once the resolver is already there.

For example. Think of an office building:

• Directory at the entrance (TLD NS) —> Delegation NS Records
  → Tells visitors which office to go to

• Sign on the office door (child NS) —> Authoritative NS records
  → Confirms you’re at the right office

Both are needed, but they do different jobs.

A domain often has multiple NS records which can indicate primary and secondary nameservers for that domain.

Note that NS records can never point to a canonical name (CNAME) record.

---

6. TXT Record

• TXT records as the name suggest stores text based information related to the domain.

• It is commonly used to verify domain ownership and to implement email security protocols like SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail).

• This text entered by the domain administrator is stored in the form of one or more strings within quotation marks.

• These records contain human as well as machine readable data.

• A single domain can have many TXT Records.

Example of a TXT record:

"v=spf1 include:_spf.google.com ~all"

The two main features of TXT Records are

• Email spam prevention

• Domain ownership verification

But how to these records help in solving these problems. Let prevent these email spammers now.

EMAIL SPAM PREVENTION

• Spammers often try to fake or forge the domains from which they send their email messages.

• TXT records are a key component of several different email authentication methods that help an email server determine if a message is from a trusted source.

• Common email authentication methods include

  • Domain Keys Identified Mail (DKIM) —> (email authentication)

  • Sender Policy Framework (SPF) —>(email sender validation)

  • Domain-based Message Authentication

  • Reporting & Conformance (DMARC)

• By configuring these records, domain operators can make it more difficult for spammers to spoof their domains and can track attempts to do so.

Now let us verify the identity of these domain owners

DOMAIN OWNERSHIP VERIFICATION

• TXT records verify domain ownership by acting as a cryptographic “proof of control” stored in authoritative DNS.

• By uploading a new TXT record with specific information included, or editing the current TXT record, an administrator can prove they control that domain.

• The tool or cloud provider can check the TXT record and see that it has been changed as requested. This is somewhat like when a user confirms their email address by opening and clicking a link sent to that email, proving they own the address.

• In-short the ability of the domain owner to create or edit a TXT record by adding a requested specific information verifies his ownership over that domain.

---

Difference between NS and MX record

---

How all DNS records work together for one website?

• Putting it all together

CASE 1: User visits https://www.example.com (Working of A/AAAA and CNAME records)

1. Browser asks DNS for www.example.com

2. Finds CNAME → example.com

3. Resolves A/AAAA → server IP (192.168.1.4)

4. Connects via HTTPS

5. Website loads

---

CASE 2: Someone sends email to info@example.com (Email Services)

1. Sender looks up MX record

2. Finds mail server

3. Checks SPF, DKIM, DMARC

4. Email is accepted or rejected by the mail server

---

Complete Example DNS Zone (Simplified)

example.com.        A       93.184.216.34
example.com.        AAAA    2606:2800::1
www.example.com.    CNAME   example.com.
mail.example.com.   A       93.184.216.50
example.com.        MX 10   mail.example.com.

example.com.        TXT     "v=spf1 ip4:93.184.216.50 ~all"
selector1._domainkey.example.com. TXT "v=DKIM1; p=..."
_dmarc.example.com. TXT     "v=DMARC1; p=none"

example.com.        CAA     0 issue "letsencrypt.org"

---

One-Sentence Summary

A single website uses multiple DNS records together to route web traffic, handle email, enforce security, enable HTTPS, and prove ownership — all coordinated through DNS.

TO CONCLUDE

Indeed DNS records are the invisible backbone of every website and email system on the internet. Although users only see a domain name, DNS quietly coordinates multiple records—such as A, AAAA, CNAME to ensure that websites load correctly, emails are delivered securely, and online identities remain protected.

As we’ve seen, a single domain like example.com relies on different DNS records working together for different purposes: web traffic resolution, email routing, authentication, and security. Each record has a specific role, but only when they are configured correctly as a whole does the system function reliably.

Whether you’re managing a small website or a large-scale platform, a well-structured DNS setup is essential for performance, trust, and long-term stability.