DNS for Developers: Everything You Should Know

Last month, I pushed a DNS change for BirJob's domain and then stared at my screen for 45 minutes wondering why the site was still resolving to the old IP. I knew about DNS propagation, I knew about TTLs, and I still made the same mistake every developer makes: I didn't lower the TTL before making the change.

DNS is one of those systems that every developer uses but few truly understand. We treat it as magic: type a domain name, get an IP address. But when something goes wrong — a misconfigured CNAME, a forgotten MX record, a propagation delay — the debugging experience is miserable if you don't understand the underlying mechanics.

This guide covers everything a developer needs to know about DNS: how it works, every record type that matters, common pitfalls, and real-world debugging techniques. No networking degree required.

Chapter 1: How DNS Actually Works

When you type www.birjob.com into your browser, here's what happens — in roughly 50-200 milliseconds:

The Resolution Chain

1. Browser cache: "Do I already know the IP for www.birjob.com?"
   → Yes: Use cached IP. Done.
   → No: Continue.

2. OS cache: "Does the operating system know?"
   → Check /etc/hosts (or Windows hosts file)
   → Check OS DNS cache (systemd-resolved, mDNSResponder)
   → Found: Use it. Done.
   → Not found: Continue.

3. Recursive resolver (your ISP or 8.8.8.8 or 1.1.1.1):
   → Check its cache: Found → return it
   → Not cached: Start the recursive lookup

4. Root servers: "Who handles .com?"
   → Returns: "Ask the .com TLD servers at a.gtld-servers.net"

5. TLD servers (.com): "Who handles birjob.com?"
   → Returns: "Ask the authoritative nameservers at ns1.vercel-dns.com"

6. Authoritative nameserver: "What's the A record for www.birjob.com?"
   → Returns: "76.76.21.21, TTL 300"

7. Answer flows back through the chain, each server caching it.

This hierarchical, distributed design is what makes DNS incredibly resilient. According to Cloudflare's DNS documentation, the root DNS system has survived every major internet outage since its creation, and the 13 root server clusters actually represent over 1,500 physical servers worldwide.

The Key Insight: Caching Everywhere

DNS is aggressively cached at every level. The TTL (Time To Live) on each record tells caches how long to keep it. A record with TTL 3600 (1 hour) means that after a resolver fetches it, it won't ask again for 1 hour — even if you change the record.

This is why DNS changes aren't instant. It's not "propagation" in the traditional sense — it's cache expiry. Different resolvers cached your old record at different times, so they'll expire at different times. The original DNS specification (RFC 1035) defines this caching behavior.

Chapter 2: Record Types That Matter

A Record

Maps a domain name to an IPv4 address. The most basic and common record type.

birjob.com.    300    IN    A    76.76.21.21

You can have multiple A records for the same domain (round-robin load balancing):

birjob.com.    300    IN    A    76.76.21.21
birjob.com.    300    IN    A    76.76.21.22
birjob.com.    300    IN    A    76.76.21.23

AAAA Record

Maps a domain name to an IPv6 address. Same as A record but for IPv6.

birjob.com.    300    IN    AAAA    2606:4700::6810:84e5

CNAME Record

An alias from one domain to another. The browser resolves the CNAME target to get the final IP.

www.birjob.com.    300    IN    CNAME    cname.vercel-dns.com.

Critical rule: A CNAME cannot coexist with any other record type for the same name. You can't have a CNAME and an MX record for the same subdomain. And you can never use a CNAME at the zone apex (bare domain like birjob.com) — only on subdomains.

MX Record

Specifies the mail server for a domain. Essential for receiving email.

birjob.com.    3600    IN    MX    10    mx1.emailprovider.com.
birjob.com.    3600    IN    MX    20    mx2.emailprovider.com.

The number (10, 20) is the priority — lower numbers are tried first. If mx1 is down, mail goes to mx2.

TXT Record

Free-form text, used for verification, SPF, DKIM, and DMARC. This is the Swiss Army knife of DNS records.

# SPF (who can send email on behalf of your domain)
birjob.com.    3600    IN    TXT    "v=spf1 include:_spf.google.com ~all"

# DKIM (email signature verification)
google._domainkey.birjob.com.    3600    IN    TXT    "v=DKIM1; k=rsa; p=MIIBIjAN..."

# DMARC (policy for handling failed SPF/DKIM)
_dmarc.birjob.com.    3600    IN    TXT    "v=DMARC1; p=reject; rua=mailto:dmarc@birjob.com"

# Domain verification (Google, GitHub, etc.)
birjob.com.    3600    IN    TXT    "google-site-verification=abc123..."

NS Record

Delegates a domain to specific nameservers.

birjob.com.    86400    IN    NS    ns1.vercel-dns.com.
birjob.com.    86400    IN    NS    ns2.vercel-dns.com.

SRV Record

Specifies the location of a specific service (used by SIP, XMPP, Minecraft, etc.).

_sip._tcp.birjob.com.    3600    IN    SRV    10 60 5060 sip.birjob.com.

CAA Record

Specifies which Certificate Authorities can issue SSL certificates for your domain. Important for security.

birjob.com.    3600    IN    CAA    0 issue "letsencrypt.org"
birjob.com.    3600    IN    CAA    0 issuewild "letsencrypt.org"

All Record Types Summary

Chapter 3: DNS Debugging Toolkit

When DNS goes wrong, you need to know how to investigate. Here are the tools every developer should know.

dig — The Gold Standard

# Basic query
dig birjob.com

# Query specific record type
dig birjob.com A
dig birjob.com MX
dig birjob.com TXT
dig birjob.com NS

# Query a specific resolver
dig @8.8.8.8 birjob.com A
dig @1.1.1.1 birjob.com A

# Trace the full resolution path (most useful for debugging)
dig +trace birjob.com

# Short output (just the answer)
dig +short birjob.com A

# Show all records for a domain
dig birjob.com ANY  # Note: many servers block ANY queries now

# Check SOA (Start of Authority) — shows zone serial, refresh intervals
dig birjob.com SOA

nslookup — Cross-Platform

# Simple lookup
nslookup birjob.com

# Specific record type
nslookup -type=MX birjob.com

# Use a specific DNS server
nslookup birjob.com 8.8.8.8

Online Tools

• Google Admin Toolbox Dig — dig from Google's infrastructure
• DNS Checker — check propagation across global resolvers
• MXToolbox — comprehensive DNS, mail, and blacklist checking
• whatsmydns.net — real-time propagation checker

Common Debugging Scenarios

# "My site isn't resolving after a DNS change"
# Check if the old record is still cached:
dig +short birjob.com A
dig @8.8.8.8 +short birjob.com A   # Check Google's resolver
dig @1.1.1.1 +short birjob.com A   # Check Cloudflare's resolver

# "My emails are going to spam"
dig birjob.com TXT | grep spf       # Check SPF record
dig google._domainkey.birjob.com TXT # Check DKIM
dig _dmarc.birjob.com TXT           # Check DMARC

# "SSL certificate isn't working"
dig birjob.com CAA                   # Check CAA records
openssl s_client -connect birjob.com:443 -servername birjob.com

# "DNS changes aren't taking effect"
dig +trace birjob.com A              # Trace the full path
dig birjob.com SOA                   # Check authoritative server

Chapter 4: TTL Strategy

TTL management is the most practical DNS skill a developer can learn. Get it wrong, and a simple migration can turn into hours of downtime.

The Pre-Migration TTL Dance

Before making any significant DNS change (moving to a new server, changing CDN providers, etc.), follow this sequence. This approach is recommended by Cloudflare's TTL documentation:

Week before migration:
1. Lower TTL to 60 seconds (from your normal 3600)
2. Wait for old TTL to expire (if old TTL was 3600, wait 1 hour)
3. Verify the new TTL is being served:
   dig birjob.com A  # Check the TTL value in the answer

Day of migration:
4. Make the DNS change (point to new IP)
5. Within 60 seconds, all resolvers will pick up the new record
6. Verify with multiple resolvers:
   dig @8.8.8.8 birjob.com A
   dig @1.1.1.1 birjob.com A
   dig @208.67.222.222 birjob.com A  # OpenDNS

After migration is stable:
7. Raise TTL back to 3600 (saves resolver load)

Recommended TTLs

Chapter 5: Email DNS — SPF, DKIM, DMARC

If you send transactional emails (password resets, notifications, marketing) from your domain, email authentication DNS records are critical. Without them, your emails land in spam. With them configured incorrectly, your emails might not be delivered at all.

SPF (Sender Policy Framework)

SPF tells receiving mail servers which IP addresses are authorized to send email on behalf of your domain.

# Basic SPF record
birjob.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net -all"

# Breakdown:
# v=spf1          → This is an SPF record
# include:...     → These services can send on our behalf
# -all            → Reject everything else (strict)
# ~all            → Soft fail (mark as suspicious but deliver)

# Common mistake: too many DNS lookups (max 10)
# Each "include" and "a" and "mx" mechanism counts as a lookup

DKIM (DomainKeys Identified Mail)

DKIM adds a digital signature to every email, allowing receivers to verify the email wasn't tampered with.

# DKIM record (your email provider gives you this)
selector1._domainkey.birjob.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3..."

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC ties SPF and DKIM together and tells receivers what to do when authentication fails.

# Start with monitoring mode
_dmarc.birjob.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@birjob.com"

# After confirming legitimate senders, move to quarantine
_dmarc.birjob.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@birjob.com"

# Finally, enforce reject
_dmarc.birjob.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@birjob.com"

Google and Yahoo announced in 2024 that bulk senders must have SPF, DKIM, and DMARC properly configured or face delivery failures. This is no longer optional.

Chapter 6: HTTPS and DNS — ALIAS, ANAME, and the Zone Apex Problem

One of the most confusing DNS issues is the zone apex problem. You want birjob.com (no www) to point to your hosting provider, but your provider gives you a CNAME target (like cname.vercel-dns.com). You can't use a CNAME at the zone apex. What do you do?

Solutions

1. ALIAS/ANAME record: Cloudflare, Route 53, and other providers offer a proprietary ALIAS or ANAME record that acts like a CNAME but resolves at the DNS level, returning A records to clients. This is the cleanest solution.
2. CNAME flattening: Cloudflare automatically flattens CNAME records at the apex into A records.
3. A record to known IPs: Some providers (like Vercel) publish stable IP addresses you can use for A records. Less flexible but universally supported.

Chapter 7: DNS Security

DNSSEC

DNSSEC adds cryptographic signatures to DNS responses, preventing man-in-the-middle attacks that could redirect your users to malicious servers. ICANN's DNSSEC documentation explains the protocol in detail.

DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT)

Traditional DNS queries are sent in plaintext — anyone on the network path can see what domains you're resolving. DoH and DoT encrypt DNS queries. All major browsers now support DoH, and resolvers like Cloudflare (1.1.1.1) and Google (8.8.8.8) offer both DoH and DoT endpoints.

Chapter 8: My Opinionated Take

After managing DNS for multiple production domains, here's what I'd tell every developer:

1. Use Cloudflare for DNS, even if you don't use their CDN. Their DNS is fast (often <3ms resolution), free for basic use, has an excellent API, and supports ALIAS records at the apex. The DNSPerf benchmarks consistently rank Cloudflare as one of the fastest authoritative DNS providers.

2. Set up email authentication from day one. SPF + DKIM + DMARC should be configured before you send your first email. Fixing deliverability problems after your domain has a bad reputation is much harder than preventing them.

3. Always lower TTLs before changes. I've seen developers change DNS records and then wait 24+ hours for propagation because they didn't lower the TTL first. This is entirely avoidable.

4. Document your DNS records. DNS records are infrastructure. They should be in version control, ideally managed through Terraform or a similar tool. "Who added this TXT record and why?" is a question you'll ask eventually, and the DNS provider's audit log might not have the answer.

Action Plan

This Week

1. Run dig yourdomain.com ANY and document every record
2. Check your email authentication: SPF, DKIM, DMARC (use MXToolbox)
3. Review your TTLs — are any still at default 86400?
4. Set up CAA records to restrict certificate issuance

This Month

1. Move DNS management to a provider with an API (Cloudflare, Route 53)
2. Export your records to a Terraform configuration or at least a spreadsheet
3. Set up monitoring for DNS resolution (UptimeRobot, Pingdom)
4. Practice a DNS migration in a test environment

Sources

• Cloudflare: What is DNS?
• RFC 1035: Domain Names - Implementation and Specification
• Cloudflare: DNS TTL Documentation
• ICANN: DNSSEC - What Is It and Why Is It Important?
• Google: Gmail Email Authentication Requirements
• DNSPerf: DNS Speed Benchmark
• MXToolbox: DNS and Email Testing

I'm Ismat, and I build BirJob — Azerbaijan's job aggregator scraping 80+ sources daily.