The Developer's Handbook to DNS Records

How to Read This Article

This guide explains DNS records from a developer's perspective. You're not becoming a network engineer here - you're learning what you need to deploy applications, debug issues, and answer interview questions confidently.

What's covered:

• The essential DNS record types you'll actually use (A, AAAA, CNAME, MX, TXT, NS)

• How to think about what each record does and when to use it

• Real scenarios: deploying apps, setting up custom domains, configuring email

• How multiple records work together for one domain

• Common points of confusion (A vs CNAME, NS delegation, etc.)

What's not covered:

• Deep protocol internals or packet analysis

• Obscure record types you'll rarely encounter

• Advanced DNS security implementation details

• Anything that doesn't help you actually use DNS in production

Each record type is broken into three parts:

1. What problem does it solve? - The "why" before the "what"

2. How it works - Simple explanation and examples

3. When you'll use it - Real production scenarios

Let's start with the fundamental question DNS answers.

---

The Core Question: "Where Should This Request Go?"

When someone types yourapp.com into their browser, the internet needs to figure out which server to talk to. DNS is the system that answers this question.

Think of it like a phone book, but instead of mapping names to phone numbers, it maps domain names to various destinations and instructions. Different record types handle different kinds of "where should this go?" questions.

User types: myapp.com
DNS answers: "Send requests to 192.0.2.1"

User sends email to: hello@myapp.com  
DNS answers: "Mail goes to mail.provider.com"

User visits: blog.myapp.com
DNS answers: "That's just an alias for myapp.com"

If you want to deep dive into what DNS is and How it works then must visit my article: HOW DNS WORKS ?

Now let's look at how different record types make this happen.

---

A Record: The Foundation

What problem does it solve?

Your domain name needs to point to an actual server IP address. When someone visits your website, their browser needs to know which machine to connect to.

How it works

An A record maps a domain name to an IPv4 address (the familiar 192.168.1.12 format).

Example:

myapp.com.        A    192.0.2.1
api.myapp.com.    A    192.0.2.2
www.myapp.com.    A    192.0.2.1

This says:

• myapp.com → goes to server at 192.0.2.1

• api.myapp.com → goes to different server at 192.0.2.2

• www.myapp.com → also goes to 192.0.2.1 (same as root domain)

Visual flow:

User types "myapp.com"
        ↓
DNS lookup for A record
        ↓
Returns: 192.0.2.1
        ↓
Browser connects to 192.0.2.1
        ↓
Your server responds

When you'll use it

• Pointing your domain to your web server

• Setting up subdomains for different services (api, admin, dashboard)

• Any time you have a server with a static IP you want to reach by name

Multiple A records: You can have multiple A records for the same domain. DNS will rotate through them (round-robin load balancing, though not the most reliable method).

myapp.com.    A    192.0.2.1
myapp.com.    A    192.0.2.2
myapp.com.    A    192.0.2.3

---

AAAA Record: A Record's IPv6 Sibling

What problem does it solve?

Same as A records, but for IPv6 addresses (the newer, longer format like 2001:0db8:85a3::8a2e:0370:7334).

How it works

Identical to A records, just different address format.

Example:

myapp.com.    AAAA    2001:0db8:85a3::8a2e:0370:7334

When you'll use it

• When your hosting provider gives you an IPv6 address

• Modern deployments often have both A and AAAA records

• Increasing importance as IPv4 addresses run out

You'll often see them paired:

myapp.com.    A       192.0.2.1
myapp.com.    AAAA    2001:0db8::1

Browsers try IPv6 first if available, fall back to IPv4 if not.

---

CNAME Record: The Alias

What problem does it solve?

You want multiple domain names to point to the same place, without duplicating configuration. When the destination changes, you only update one record.

How it works

A CNAME creates an alias. It says "this name is actually just another name for that other name - go look that up instead."

Example:

myapp.com.        A         192.0.2.1
www.myapp.com.    CNAME     myapp.com.
blog.myapp.com.   CNAME     myapp.com.

When someone visits www.myapp.com:

Lookup www.myapp.com
        ↓
Found CNAME → points to myapp.com
        ↓
Lookup myapp.com
        ↓
Found A record → 192.0.2.1
        ↓
Connect to 192.0.2.1

When you'll use it

• Pointing www.myapp.com to myapp.com

• Connecting custom domains to platforms (Vercel, Heroku, Shopify give you a CNAME target)

• Setting up CDN subdomains

Common CDN pattern:

myapp.com.        A       192.0.2.1
cdn.myap.com.    CNAME   xyz123.cloudfront.net.

The Big Confusion: A vs CNAME

When to use A:

• You have an IP address

• It's your root domain (some DNS providers restrict CNAME at root)

• You need multiple records of different types at the same name

When to use CNAME:

• You're pointing to another domain name (not an IP)

• You want changes to propagate automatically

• Platform tells you to use CNAME (like yoursite.vercel.app)

Critical rule: You CANNOT have a CNAME and any other record type for the same name.

This is INVALID:

blog.myapp.com.    CNAME    myapp.com.
blog.myapp.com.    MX       mail.provider.com.    <--- WRONG

This is why root domains often use A records instead of CNAME - they need MX records for email.

---

MX Record: Mail Routing

What problem does it solve?

Email sent to user@myapp.com needs to know which mail server to deliver to. MX records specify where mail goes.

How it works

MX records point to mail servers and include a priority number. Lower numbers = higher priority.

Example:

myapp.com.    MX    10    mail1.provider.com.
myapp.com.    MX    20    mail2.provider.com.

When someone sends email to hello@myapp.com:

Mail server looks up MX records for myapp.com
        ↓
Finds: mail1.provider.com (priority 10)
       mail2.provider.com (priority 20)
        ↓
Tries mail1.provider.com first
        ↓
If that fails, tries mail2.provider.com
        ↓
Email delivered

When you'll use it

• Setting up Google Workspace / Microsoft 365 for your domain

• Configuring any custom email for your domain

• Email services give you specific MX records to add

Real example (Google Workspace):

myapp.com.    MX    1     aspmx.l.google.com.
myapp.com.    MX    5     alt1.aspmx.l.google.com.
myapp.com.    MX    5     alt2.aspmx.l.google.com.
myapp.com.    MX    10    alt3.aspmx.l.google.com.
myapp.com.    MX    10    alt4.aspmx.l.google.com.

Important: MX records point to domain names, not IP addresses. Those domain names then have their own A records.

---

TXT Record: The Utility Player

What problem does it solve?

You need to store arbitrary text information about your domain - usually for verification or configuration.

How it works

TXT records hold text strings. They're used for all sorts of things that don't fit other record types.

Example:

myapp.com.    TXT    "v=spf1 include:_spf.google.com ~all"
myapp.com.    TXT    "google-site-verification=abc123xyz"

When you'll use it

1. Domain verification: When you add your domain to a service, they ask you to add a TXT record to prove you own it.

myapp.com.    TXT    "google-site-verification=XYZ123"

2. Email authentication (SPF, DKIM, DMARC): These prevent email spoofing. Mail servers check these records.

myapp.com.    TXT    "v=spf1 include:_spf.google.com ~all"
_dmarc.myapp.com.    TXT    "v=DMARC1; p=quarantine; rua=mailto:admin@myapp.com"

3. Site ownership verification: For services like Google Search Console, Facebook domain verification, etc.

You can have multiple TXT records for one domain - each serves a different purpose.

---

NS Record: Delegation Control

What problem does it solve?

NS (nameserver) records specify which DNS servers are authoritative for your domain. They delegate control of your domain's DNS.

How it works

NS records point to the DNS servers that hold your domain's actual records.

Example:

myapp.com.    NS    ns1.cloudflare.com.
myapp.com.    NS    ns2.cloudflare.com.

This says "if you want to know anything about myapp.com, ask these nameservers."

The DNS hierarchy

Root DNS Servers
        ↓
.com TLD Servers (know where myapp.com's NS records are)
        ↓
Your Nameservers (ns1.cloudflare.com)
        ↓
Your actual DNS records (A, CNAME, MX, etc.)

When you'll use it

1. When you register a domain: You point it to your DNS provider's nameservers (Cloudflare, Route53, etc.)

2. Delegating subdomains: You can delegate a subdomain to different nameservers.

myapp.com.          NS    ns1.cloudflare.com.
api.myapp.com.      NS    ns1.aws.com.

Now api.myapp.com and its subdomains are managed completely separately.

Common confusion: You usually set NS records at your domain registrar, not in your DNS provider's dashboard (though you can for subdomain delegation).

---

How Records Work Together: A Real Production Setup

Let's look at a typical web application with email and a CDN.

# Main website
myapp.com.              A         192.0.2.1
www.myapp.com.          CNAME     myapp.com.

# IPv6 support
myapp.com.              AAAA      2001:0db8::1

# API on separate server
api.myapp.com.          A         192.0.2.2

# CDN for static assets
cdn.myapp.com.          CNAME     xyz123.cloudfront.net.

# Email (Google Workspace)
myapp.com.              MX    1   aspmx.l.google.com.
myapp.com.              MX    5   alt1.aspmx.l.google.com.

# Email authentication
myapp.com.              TXT       "v=spf1 include:_spf.google.com ~all"
_dmarc.myapp.com.       TXT       "v=DMARC1; p=quarantine"

# Domain verification
myapp.com.              TXT       "google-site-verification=abc123"

# Nameservers (set at registrar)
myapp.com.              NS        ns1.cloudflare.com.
myapp.com.              NS        ns2.cloudflare.com.

What happens when a user visits www.myapp.com:

1. Browser asks: "What's the IP for www.myapp.com?"
2. DNS resolver asks root servers: "Who handles .com?"
3. Root servers: "Ask .com TLD servers"
4. TLD servers: "For myapp.com, ask ns1.cloudflare.com"
5. Cloudflare NS: "www.myapp.com is a CNAME to myapp.com"
6. Browser asks: "What's the IP for myapp.com?"
7. Cloudflare NS: "192.0.2.1 (and 2001:0db8::1 for IPv6)"
8. Browser connects to 192.0.2.1

What happens when someone sends email to hello@myapp.com:

1. Sending mail server asks: "What are the MX records for myapp.com?"
2. DNS returns: aspmx.l.google.com (priority 1), alt1... (priority 5)
3. Sending server looks up A record for aspmx.l.google.com
4. Connects to Google's mail server
5. Google's server delivers to your inbox

---

Common Scenarios and Solutions

Scenario 1: Moving to a new hosting provider

The safe way:

1. Set up everything on new server

2. Lower your TTL (time to live) values a day before (e.g., to 300 seconds)

3. Update A record to new IP

4. Wait for TTL to expire (old value cached for this duration)

5. Verify everything works

6. Raise TTL back up

Why lower TTL? If something breaks, you can switch back quickly. With high TTL (like 86400 = 24 hours), people might see the old IP for a full day.

Scenario 2: Setting up a custom domain on Vercel/Netlify

What they usually ask for:

# For root domain (myapp.com)
myapp.com.        A    76.76.21.21

# For www subdomain
www.myapp.com.    CNAME    cname.vercel-dns.com.

Why not CNAME for root? Some DNS providers don't allow it. Vercel gives you an A record instead (it's their load balancer IP that routes to your app).

Scenario 3: Subdomain for different app

You want app.myapp.com to point to a different server:

myapp.com.        A         192.0.2.1
app.myapp.com.    A         192.0.2.50

Completely independent - they can be different servers, different hosting providers, whatever.

Scenario 4: Redirect www to non-www (or vice versa)

This is NOT done in DNS. DNS only maps names to IPs. Redirects are HTTP-level.

What you actually do:

1. Point both to same server:

myapp.com.        A         192.0.2.1
www.myapp.com.    A         192.0.2.1

2. Server handles redirect:

# In your web server config
if ($host = 'www.myapp.com') {
    return 301 https://myapp.com$request_uri;
}

Or use your DNS provider's redirect feature if they offer it (Cloudflare Page Rules, etc.).

---

Quick Reference: When to Use What

---

Key Takeaways

1. DNS answers "where should this go?" - Different record types handle different kinds of routing.

2. A and AAAA are your foundation - They map names to IP addresses. Everything needs these eventually.

3. CNAME is for aliases - Use when pointing to another domain name, not an IP.

4. You can't mix CNAME with other records - This catches people constantly. CNAME must be alone.

5. MX is only for email - Your web server and mail server are usually completely different things.

6. TXT is the Swiss Army knife - Verification, email authentication, any random text data.

7. NS delegates control - Usually set at your registrar to point to your DNS provider.

8. Records work together - A production domain uses multiple record types simultaneously.

9. TTL matters when making changes - Lower it before migrations, raise it after for better performance.

10. DNS doesn't do redirects - That's your web server's job. DNS only does name→destination mapping.

---

What to Learn Next

Once you're comfortable with these basics:

• TTL and caching behavior - How long records are cached and why it matters

• DNS propagation - Why changes don't happen instantly everywhere

• CAA records - Controlling which Certificate Authorities can issue SSL certs for your domain

• SRV records - For services like VoIP, XMPP, or game servers

• DNS providers comparison - Route53 vs Cloudflare vs traditional registrars

But for 90% of development work, the records covered here are what we will use as a developer every day.