# Records in DNS

## How DNS knows “Where to go“ ?

From my previous blog “How DNS works” one can easily understand how the DNS name server delegation takes place and how the whole DNS system works by giving one answer for every question at a time - “Where to go next”.  
So if you see in the DNS management section of the Authoritative Providers there you will find many different types of records. So this article is going to explain the usage of this different types records and their uses.

## Important Types of Records

1. **A Record:** This is the most common and important record which is used in every application out their on the internet. This stores the actual IP of the server where we want the domain to point to. This is the first thing a DNS tries to find when a request comes to a domain and this record ends the DNS look ups at the end.
    
2. **AAAA Record:** This record behaves same as the A record but it stores the IPV6 format which make the IPV6 look up in DNS system possible.
    
3. **CNAME Record:** This is a very interesting record to know. It stores another domain name which is used to resolve the underneath A record IP.  
    \- Lets take a case where we have a domain called example.com with IP 1.2.3.4 and we have another domain called blog.example.com. So here in our DNS management if we add the CNAME record with name blog and value as example.com then every traffic coming to blog.example.com will try to resolve the DNS of the CNAME record that example.com , doing this it will find A Record which will have the IP-1.2.3.4 and here the request end and the client receives this IP and most importantly both domains now resolve to the same IP address.  
    \- Now here lies a small catch where you might think if example.com has my portfolio website and I want blog.example.com to give the blog website of mine. So we need to see are the servers are same for the blog website and the portfolio website if yes then this can easily be solved using reverse proxy like Nginix which will proxy the request according to the request URL. If the blog is hosted on a **different server**, then there are two cases:
    
    * If you **own and control the blog server IP**, you can use an A record:
        
    * If the blog is hosted on a **third-party platform** (such as Vercel or Hashnode), you must use a CNAME record pointing to the provider’s domain, allowing them to manage IP changes internally.
        
4. **MX Record:** This record is mainly used to when others emails to your domain. For example you want to receive a email on @example.com so here our MX record comes into picture. It stores the the mail server’s domain name. So whenever someone send email to something@example.com then it will be handled by this record where the underlying mail server will receive the message.  
    **Remember:** MX records **must not point to a CNAME .**They **must point to a hostname that resolves to A/AAAA.**
    
5. **TXT Record:** This record is used to store the plain text about the domain. Main purpose of this record is to provide information like ownerships, rules, trust, etc. Most common use cases are:
    
    1. Email Authentication: Emails sent from our domain like @example.com to any user using @gmail.com are verified an authenticated using the following protocols:
        
        1. SPF: Defines which mail servers are allowed to send emails on behalf of your domain.
            
        2. DKIM: Ensures that an email was not modified in transit.
            
        3. DMARC: Tells receiving mail servers what to do if SPF or DKIM fails  
              
            In the end all these protocols simply tells the receiving mail servers that the mail comes from a genuine source.
            
    2. The information in this record is also used to check the domain ownership verifications.
        
6. **NS Record:** This record tells the internet which DNS servers are responsible for your domain. It actually tells where you will get the actual A, AAAA, MX and TXT records for this particular domain.  
    **NOTE:** It seems that we add the NS records in our DNS dashboard but actually this particular record is published to TLD servers where the mapping of your domain and name server lies. Name Servers are used **before** querying the authoritative DNS server.  
    

## How everything works together ?

Let’s understand this using **one domain**: example.com

## Step 1: NS Record — “Who is responsible for this domain?”

Before anything else, DNS must know **which DNS server holds the answers**.

### Question asked:

> “Who manages DNS records for [example.com](http://example.com)?”

### Answer (NS record):

```bash
example.com → ns1.cloudflare.com
example.com → ns2.cloudflare.com
```

This tells the internet:

> “Ask Cloudflare’s DNS servers for all further information.”

## Step 2: A / CNAME Record — “Where is the website hosted?”

Once the authoritative DNS server is known, the browser asks:

### Question asked:

> “What IP should I connect to for [example.com](http://example.com)?”

### Possible answers:

```bash
A example.com → 1.2.3.4
```

or

```bash
CNAME www.example.com → example.com
```

DNS resolves this until it finds an **IP address**, then the browser connects to that server.

## Step 3: MX Record — “Where should emails be delivered?”

Now consider email sent to:

```bash
contact@example.com
```

Mail servers ask:

### Question asked:

> “Which mail server receives emails for [example.com](http://example.com)?”

### Answer (MX record):

```bash
MX 10 mx1.mailprovider.com
MX 20 mx2.mailprovider.com
```

Emails are delivered to the mail server, **not the website server**.

## Step 4: TXT Records — “Can this domain be trusted?”

TXT records publish **rules and proof**, mainly for email and verification.

They answer questions like:

### SPF — Who can send emails?

```bash
v=spf1 include:_spf.google.com ~all
```

### DKIM — Was the email modified?

```bash
selector1._domainkey → public key
```

### DMARC — What if checks fail?

```bash
_dmarc → v=DMARC1; p=none
```

Receiving mail servers read these TXT records to decide:

* Inbox
    
* Spam
    
* Reject
    

## Step 5: All records working together (real flow)

### When someone opens your website

```bash
Browser
→ NS (find DNS server)
→ A / CNAME (get IP)
→ Website loads
```

### When someone emails you

```bash
Sender mail server
→ MX (find mail server)
→ Email delivered
```

### When you send an email

```bash
Receiver mail server
→ TXT (SPF, DKIM, DMARC)
→ Decide inbox or spam
```

Same domain.  
Different DNS questions.  
Different record types.

## Why records don’t conflict

A common misunderstanding is thinking **all records are used at once**.

That’s not true.

Each system:

* Asks **only one type of DNS question**
    
* Gets **only the record it understands**
    

| System | DNS record used |
| --- | --- |
| Browser | A / CNAME |
| Mail sender | MX |
| Mail receiver | TXT |
| DNS resolver | NS |