You’ve bought a domain. You’ve got hosting. Now you need to connect the two. This sounds simple — and conceptually, it is — but the details matter. A misconfigured DNS setup leads to downtime, broken email, and hours of debugging “why isn’t my site loading?”
Let’s walk through the entire process, decision by decision.
Step 1: Understanding What You’re Connecting
Before touching any DNS settings, get clear on your architecture:
┌──────────────┐ ┌──────────────┐
│ Your Domain │ DNS │ Your Hosting │
│ example.com │ ──────> │ Server(s) │
│ │ │ 203.0.113.50 │
└──────────────┘ └──────────────┘
│ │
│ Registrar │ Hosting Provider
│ (Namecheap, │ (Vercel, Netlify,
│ GoDaddy, etc.) │ AWS, DigitalOcean)
└─────────────────────────┘
Your registrar is where you bought the domain. Your hosting provider is where your website files live. DNS bridges the gap. Sometimes these are the same company, sometimes not. The setup process is the same either way.
Step 2: Choosing Your Nameservers
Every domain needs authoritative nameservers — the servers that answer DNS queries for your domain. You have three options:
Option A: Registrar’s nameservers (simplest)
Your registrar provides default nameservers. Namecheap uses dns1.registrar-servers.com, GoDaddy uses ns1.domaincontrol.com, etc. Easy to start with, but often limited in features.
Option B: Hosting provider’s nameservers (common)
Many hosting providers want you to point your nameservers to them. Cloudflare, for example, requires this:
ns1.cloudflare.com
ns2.cloudflare.com
This gives the hosting provider full control over your DNS, which enables features like their CDN, DDoS protection, and edge caching.
Option C: Dedicated DNS provider (advanced)
Services like AWS Route 53, DNS Made Easy, or NS1 offer enterprise-grade DNS hosting. You’d set your nameservers to something like:
ns-1234.awsdns-56.org
ns-789.awsdns-01.co.uk
The decision: For most websites, Option B (using your hosting provider’s nameservers) is the sweet spot. It integrates tightly with your hosting and usually provides a good DNS management interface.
Changing Nameservers
At your registrar, find the nameserver settings and replace the defaults:
# Before (registrar defaults)
dns1.registrar-servers.com
dns2.registrar-servers.com
# After (pointing to Cloudflare)
ns1.cloudflare.com
ns2.cloudflare.com
Warning: Nameserver changes propagate globally, but they’re controlled by the parent zone’s TTL for your NS records. This typically takes 24–48 hours for full propagation, though most resolvers will pick up changes within a few hours.
Step 3: The A Record vs CNAME Decision
This is where most people get confused. You need to point your domain to your server, and you have two main record types to choose from.
A Records: Direct IP Mapping
An A record maps a name directly to an IPv4 address:
example.com. IN A 203.0.113.50
Use A records when:
- You have a static IP address for your server
- You’re pointing the root domain (also called the “apex” or “naked” domain)
- You’re using a traditional hosting setup (VPS, dedicated server)
CNAME Records: Aliasing to Another Name
A CNAME creates an alias from one name to another:
www.example.com. IN CNAME myapp.hosting-provider.com.
Use CNAME when:
- Your hosting provider gives you a hostname (not an IP)
- You’re using PaaS platforms like Heroku, Vercel, or Netlify
- You want your DNS to automatically follow IP changes on the target
The Root Domain Problem
Here’s the critical constraint: you cannot put a CNAME on the root domain. This is defined in RFC 1034 — a CNAME record means “this name is an alias for another name,” and if a name has a CNAME, it cannot have any other record types. But root domains need SOA and NS records, so a CNAME would create a conflict.
# ✅ This works
www.example.com. IN CNAME myapp.vercel.app.
# ❌ This violates RFC 1034
example.com. IN CNAME myapp.vercel.app.
Solutions for the root domain:
- Use an A record with the provider’s IP address
- ALIAS/ANAME records — Some DNS providers (Cloudflare, DNSimple, Route 53) offer proprietary record types that function like CNAMEs at the apex but resolve to A records at query time
- Cloudflare’s CNAME flattening — Cloudflare allows CNAME-like behavior at the root by resolving the CNAME chain internally
# Cloudflare CNAME flattening (entered as CNAME, served as A)
example.com. IN CNAME myapp.vercel.app.
# Cloudflare resolves this and returns the A record to clients
Step 4: www vs Naked Domain
Should users access your site at www.example.com or example.com? This is a long-running debate, and the right answer depends on your setup.
Option A: www as Primary
example.com. IN A 203.0.113.50 ; redirect to www
www.example.com. IN CNAME myapp.cdn.com. ; actual site
Advantages:
- CNAMEs work on
www(flexible hosting) - Cookies can be scoped to
www.example.com, keeping the root clean for cookieless asset domains - Some CDNs work better with
www
Option B: Naked Domain as Primary
example.com. IN A 203.0.113.50 ; actual site
www.example.com. IN CNAME example.com. ; redirect to naked
Advantages:
- Cleaner URLs
- Modern trend (most new sites use naked domains)
- Simpler for users to type and remember
The Redirect
Whichever you choose, set up a 301 redirect from the non-primary to the primary:
# Nginx: redirect www to naked
server {
listen 80;
server_name www.example.com;
return 301 https://example.com$request_uri;
}
# Apache .htaccess: redirect naked to www
RewriteEngine On
RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]
Critical: Always use a 301 (permanent) redirect, not a 302 (temporary). This tells search engines which version is canonical and consolidates SEO authority.
Step 5: Adding Essential Records
Beyond the basic website records, a production domain needs a few more:
; Root domain
example.com. IN A 203.0.113.50
example.com. IN AAAA 2001:db8::1
; WWW subdomain
www.example.com. IN CNAME example.com.
; Email (even if you don't send email — see Chapter 2)
example.com. IN MX 10 mail.example.com.
example.com. IN TXT "v=spf1 include:_spf.google.com ~all"
; Verification records (Google, Let's Encrypt, etc.)
example.com. IN TXT "google-site-verification=abc123..."
_acme-challenge.example.com. IN TXT "validation-token-here"
Don’t forget the AAAA record for IPv6. It’s no longer optional — IPv6 adoption is growing, and major networks (mobile carriers especially) use IPv6 extensively.
Step 6: DNS Propagation — Myth vs Reality
After making changes, you’ll be told to “wait for DNS propagation.” As we explained in DNS Caching and TTL, let’s demystify this.
What’s actually happening: DNS doesn’t “propagate” like a wave spreading across the internet. Each resolver independently caches records for the duration of the TTL. When the TTL expires, the resolver fetches fresh data.
You change A record at 2:00 PM
TTL was set to 3600 (1 hour)
Resolver A cached at 1:30 PM → expires 2:30 PM → sees new record at 2:30
Resolver B cached at 1:45 PM → expires 2:45 PM → sees new record at 2:45
Resolver C cached at 2:05 PM → already sees new record (cache miss)
How to make changes faster:
- Lower the TTL before making changes. Days before your migration, drop the TTL to 300 seconds (5 minutes). Let the old TTL expire across caches, then make your change. After it’s stable, raise the TTL back.
; 48 hours before migration
example.com. 300 IN A 203.0.113.50 ; TTL lowered to 5 min
; Make the change
example.com. 300 IN A 198.51.100.75 ; New IP
; After confirming stability (24-48 hours later)
example.com. 3600 IN A 198.51.100.75 ; TTL back to 1 hour
- Check propagation status with tools like
digagainst specific resolvers:
# Check against Google's resolver
dig example.com @8.8.8.8
# Check against Cloudflare's resolver
dig example.com @1.1.1.1
# Check against your authoritative nameserver directly
dig example.com @ns1.your-dns-provider.com
- Understand that “48 hours” is a worst case. With a 1-hour TTL, most users will see changes within 1–2 hours. The 48-hour figure dates from when TTLs of 86400 (24 hours) were common defaults.
Common Provider Setups
Here are quick-reference DNS configurations for popular hosting providers:
Vercel
example.com. IN A 76.76.21.21
www.example.com. IN CNAME cname.vercel-dns.com.
Netlify
example.com. IN A 75.2.60.5
www.example.com. IN CNAME your-site.netlify.app.
GitHub Pages
example.com. IN A 185.199.108.153
example.com. IN A 185.199.109.153
example.com. IN A 185.199.110.153
example.com. IN A 185.199.111.153
www.example.com. IN CNAME username.github.io.
AWS (CloudFront + S3)
example.com. IN A ALIAS d123abc.cloudfront.net.
www.example.com. IN CNAME d123abc.cloudfront.net.
Each provider has specific requirements — always check their documentation for the latest recommended configuration. IP addresses change; CNAME targets are more stable.
Key Takeaways
- Choose your nameservers deliberately — they determine where you manage DNS
- Use A records for root domains, CNAMEs for subdomains pointing to hostnames
- The CNAME-at-root restriction is real — use ALIAS/ANAME or CNAME flattening
- Pick www or naked domain, then 301 redirect the other
- “DNS propagation” is really just TTL expiration across distributed caches
- Lower TTLs before making changes, raise them after stability is confirmed