What Is DNS? How Domain Names Actually Work for Vibe Coders

Why AI Coders Need to Understand DNS

Here's a scene that plays out hundreds of times a day in the vibe coding community: You've spent a week building something real. You asked Claude to help you set up a Node.js server, got it running on a VPS, bought a domain name, and then… nothing. Just a browser error. ERR_NAME_NOT_RESOLVED.

You ask Claude, "why isn't my domain working?" and it gives you a generic answer about DNS propagation. You ask your Discord server. You dig through Stack Overflow. Two hours later you figure out you set the wrong record type. Another hour after that you realize there's a 48-hour wait. It's maddening — and completely avoidable once you understand what DNS actually does.

DNS is part of the invisible infrastructure layer that every developer relies on daily but rarely learns until something breaks. For AI-enabled coders specifically, this knowledge is critical because AI assistants are great at generating application code but routinely underexplain the infrastructure setup required to make that code accessible on the public internet.

This article fixes that. Once you understand how DNS resolution works, you'll be able to configure it correctly the first time, debug it confidently when something goes wrong, and know exactly what to ask AI for when you need help.

What DNS Actually Is (The Phone Book Analogy)

Before phone contact lists, people used physical phone books. You looked up a name, got the number, and made the call. The phone book existed because humans are good at remembering names ("call Bob") but terrible at remembering arbitrary sequences of digits ("call 208-555-7342").

The internet has exactly the same problem. Computers communicate using IP addresses — sequences of numbers like 104.21.7.235. Humans navigate the internet using domain names like github.com. DNS is the system that bridges that gap: it's the internet's phone book, converting names into numbers on demand.

Every time your browser visits a website, it first asks the DNS system: "What's the IP address for this domain?" Only after getting that answer does it actually connect to the server. This lookup happens in milliseconds, invisibly, thousands of times per day as you browse the web.

How DNS Resolution Works (Step-by-Step)

When you type myapp.com into your browser, a multi-step lookup process happens in under 100 milliseconds. Understanding this chain helps you know where problems originate and how long changes take to reflect.

1. Browser Cache Your browser checks if it has recently looked up this domain. Browsers cache DNS results for a short time (usually the TTL of the record). If found, the lookup ends here — no further steps needed.
2. OS Cache If the browser doesn't have it, the operating system checks its own DNS cache. On macOS and Windows, a system-level cache stores recent lookups. This is why you sometimes need to "flush DNS" when troubleshooting — you're clearing this cache.
3. Recursive Resolver If the OS doesn't know, it asks your recursive resolver — usually your ISP's DNS server or a public one like Cloudflare (1.1.1.1) or Google (8.8.8.8). This resolver does the heavy lifting of tracking down the answer. It may have the answer cached; if not, it starts asking authoritative servers.
4. Root Nameserver The resolver asks one of 13 root nameserver clusters (managed by ICANN and various operators). The root server doesn't know the IP for myapp.com, but it knows where to find the .com nameservers. It hands back a referral.
5. TLD Nameserver The .com TLD (Top-Level Domain) nameserver knows which nameservers are authoritative for myapp.com. It returns those nameserver addresses (your NS records).
6. Authoritative Nameserver This is the final answer. Your DNS provider (like Cloudflare) runs these authoritative nameservers. They hold the actual records you've configured — A records, CNAMEs, MX records, etc. The resolver gets the IP, caches it, and returns it to your browser.

Your browser finally has the IP address. It opens a TCP connection to port 80 or 443, sends an HTTP request, and your app responds. The whole chain took about 50–200ms for an uncached lookup — cached lookups are near-instant.

DNS Record Types You Actually Need to Know

DNS has many record types, but as an AI-enabled builder you'll regularly deal with five of them. Here's what each does in plain English:

Record	What It Does	Example
A	Maps a domain name to an IPv4 address. The most fundamental DNS record — this is how your domain points to your server.	myapp.com → 203.0.113.42
CNAME	Maps a domain name to another domain name (an alias). Use this for subdomains — not for root domains.	www.myapp.com → myapp.com
MX	Tells email servers where to deliver email for your domain. Without MX records, nobody can email you at your domain.	myapp.com → mail.fastmail.com
TXT	Stores text data for verification purposes — used by Google, Stripe, and others to prove domain ownership. Also holds SPF and DKIM records for email security.	v=spf1 include:mailgun.org ~all
NS	Declares which nameservers are authoritative for your domain. When you switch to Cloudflare DNS, you update these at your registrar.	ns1.cloudflare.com

TTL — Why DNS Changes Take Time

Every DNS record has a TTL — Time To Live — measured in seconds. This number tells every resolver, ISP, and cache in the world: "Hold onto this answer for X seconds before checking again."

A TTL of 86400 means 24 hours. If you change your A record right now, any resolver that already has the old answer cached will continue serving the old IP for up to 24 more hours — and there's nothing you can do about it.

Best practice: Before migrating a site to a new server, lower the TTL to 300 (5 minutes) at least 24 hours in advance. Once the migration is complete and working, raise it back to 3600 or higher. This minimizes the window where visitors see the old server after you've switched.

Real Scenario: Deploying to a VPS and Asking Claude for DNS Help

Here's exactly what happened when a vibe coder deployed their first Node.js app to a DigitalOcean VPS and asked for DNS configuration help. The server was running at IP 203.0.113.42, the domain was myapp.com, and nothing was connected yet.

Here's what Claude generated:

# DNS Records to Configure in Cloudflare

## Step 1: Switch Your Nameservers to Cloudflare
Go to Namecheap, find your domain, and change the nameservers to:
  ns1.cloudflare.com
  ns2.cloudflare.com

Wait 24 hours for this to propagate. Then add records in Cloudflare:

## Step 2: Add These Records in Cloudflare DNS

Type: A
Name: @         ← (the @ means your root domain: myapp.com)
Content: 203.0.113.42
TTL: Auto
Proxy: Enabled (orange cloud)

Type: CNAME
Name: www
Content: myapp.com
TTL: Auto
Proxy: Enabled (orange cloud)

## Optional: Redirect www → root (or root → www)
In Cloudflare, go to Rules → Redirect Rules and add:
  If URL matches: www.myapp.com/*
  Then: Redirect to https://myapp.com/$1 (301)

## Why Cloudflare?
- Free DDoS protection
- Free SSL certificate via their proxy
- Free CDN (speeds up your site globally)
- Fast DNS propagation (usually under 5 minutes)

Understanding Each Part of This Configuration

Switching nameservers (NS records): This moves DNS authority from Namecheap's default nameservers to Cloudflare's. Once you do this, Cloudflare becomes the authoritative nameserver for your domain. All record changes happen in Cloudflare's dashboard — not in Namecheap. This NS change itself takes up to 24 hours to propagate globally.

The A record (@ → 203.0.113.42): The @ symbol represents the root/apex of your domain. This record makes myapp.com resolve to your server's IP. Cloudflare's proxy sits in between (the orange cloud) — meaning traffic actually goes to Cloudflare first, then to your server. This gives you DDoS protection and free SSL.

The CNAME record (www → myapp.com): Makes www.myapp.com an alias for myapp.com. When someone visits www, their browser first resolves myapp.com (using the A record above), then connects to that IP. This keeps everything in sync — if you ever change the A record's IP, the www CNAME automatically follows.

The redirect rule: Without this, www.myapp.com and myapp.com serve as separate addresses — Google sees them as duplicate content. The redirect ensures all traffic hits one canonical URL. Pick one (most builders prefer the non-www version) and redirect the other.

Why Cloudflare specifically: For beginners, Cloudflare is the best choice because it's free, offers the fastest propagation of any major DNS provider (often under 5 minutes for changes), provides automatic SSL, and has an excellent dashboard. Their free plan covers everything you need for personal projects and small SaaS apps.

What AI Gets Wrong About DNS (4 Common Mistakes)

1. Not Explaining TTL Wait Times

AI tools routinely tell you to "set the DNS record and wait for propagation" without explaining that propagation can take up to 48 hours with default TTL settings. If you changed your TTL from 86400 to a new value, you still have to wait up to 86400 seconds (24 hours) for that TTL change itself to propagate before the lower TTL takes effect. AI almost never explains this double-wait problem.

2. Confusing CNAME vs. A Record at the Apex

If you ask an AI "how do I point myapp.com to Vercel?" it will sometimes tell you to add a CNAME record for your root domain. This is technically invalid according to DNS specifications, and many DNS providers will either reject it or silently mishandle it. Always use an A record (or AAAA for IPv6) at your apex domain. Vercel, Netlify, and other platforms provide specific A record IP addresses for this reason.

3. Missing the www Redirect

Most AI-generated DNS configurations set up myapp.com and www.myapp.com as two separate records pointing to the same server — without adding a redirect. This means both URLs work but Google indexes them as separate pages, creating duplicate content issues that hurt SEO. Always add a redirect: either www → root or root → www, and be consistent across your entire site.

4. Not Explaining That Localhost DNS Is Different

When you develop locally with http://localhost:3000, you're bypassing the entire DNS system. Localhost resolves to 127.0.0.1 via your OS's /etc/hosts file — not via DNS servers at all. This is why an app that works perfectly on localhost can fail on a real domain. AI rarely explains this distinction, leading to confusion when developers test locally and then can't understand why the live deployment doesn't work the same way.

How to Debug DNS Problems with AI Tools

When your domain isn't resolving correctly, you need real diagnostic data before asking AI for help. Here are the tools and commands that give you that data:

Using dig (macOS / Linux)

# Check what IP your domain currently resolves to
dig myapp.com A

# Check a specific DNS server (bypasses local cache)
dig @1.1.1.1 myapp.com A

# Check if www is resolving
dig www.myapp.com

# Check nameservers
dig myapp.com NS

# Show full resolution chain (trace mode)
dig +trace myapp.com

Using nslookup (Windows / all platforms)

# Basic lookup
nslookup myapp.com

# Query against Cloudflare's resolver directly
nslookup myapp.com 1.1.1.1

# Check MX records for email
nslookup -type=MX myapp.com

Using whatsmydns.net

When you need to check propagation across multiple global resolvers (to see if Cloudflare in Tokyo has the update but your ISP in Chicago still has the old record), visit whatsmydns.net and enter your domain. It shows the current DNS response from servers in dozens of locations worldwide — invaluable for debugging propagation issues.

Common Errors and What They Mean

Cursor / Windsurf Tip

If you're building infrastructure-as-code and managing DNS programmatically (via Cloudflare's API for example), open your DNS configuration files in Cursor and add a comment at the top: // DNS config for myapp.com - using Cloudflare - TTL 300 during migration. This gives Cursor's AI context so it can help you avoid common record type mistakes automatically.

Using Cloudflare: The Best DNS Provider for Beginners

Cloudflare offers the fastest DNS propagation in the industry (sub-5-minutes for most changes), a free plan that covers everything an indie builder needs, and a dashboard that's significantly clearer than most registrar-provided DNS management tools. Here's the setup flow:

1. Create a free Cloudflare account at cloudflare.com
2. Add your site — enter your domain and Cloudflare will scan and import your existing DNS records automatically
3. Review imported records — verify they match what you expected
4. Update nameservers at your registrar — Cloudflare shows you exactly which NS values to enter at Namecheap, GoDaddy, Google Domains, etc.
5. Wait for nameserver propagation — Cloudflare emails you when it detects the NS change (usually within 24 hours)
6. Make record changes in Cloudflare — future DNS changes propagate in minutes

What to Learn Next

DNS is one piece of the infrastructure puzzle. Here's where to go from here:

FAQ