DNS Management: A Complete Guide for Website Owners
A 2025 Catchpoint survey of 1,200 IT professionals found that DNS misconfigurations account for 22% of all website outages. Not server crashes. Not code bugs. Misconfigured DNS records — the quiet layer of infrastructure that most website owners never touch until something breaks.
DNS (Domain Name System) translates human-readable domain names into IP addresses that servers understand. Every time someone types your domain into a browser, a DNS lookup happens in 20-80 milliseconds before the page starts loading. Get DNS right and it's invisible. Get it wrong and your website, email, and SSL certificates all stop working at once.
How DNS Works (The Short Version)
When a visitor types yourdomain.com into their browser, the request follows a chain of lookups:
| Step | What Happens |
|---|---|
| 1 | Browser checks its local cache — if valid, skips the rest |
| 2 | Query goes to a recursive resolver (ISP or public resolver like Cloudflare 1.1.1.1 or Google 8.8.8.8) |
| 3 | Resolver asks root nameservers, which point to the correct TLD nameserver (.com, .dk, .io) |
| 4 | TLD nameserver directs to the authoritative nameservers for your domain (set at your registrar) |
| 5 | Authoritative nameserver returns the IP address from your A record |
| 6 | Resolver caches the result for the duration of your TTL value, sends the IP to the browser |
A cold lookup takes 20-120 milliseconds. Cached lookups are instant.
DNS Record Types Explained
Every domain has a DNS zone containing multiple record types. Here's what each one does.
| Record Type | Purpose | Example Value | When You'd Use It |
|---|---|---|---|
| A | Points domain to IPv4 address | 185.28.100.42 | Connecting domain to hosting server |
| AAAA | Points domain to IPv6 address | 2001:0db8:85a3::8a2e:0370:7334 | Same as A, for IPv6-enabled servers |
| CNAME | Aliases one domain to another | www -> yourdomain.com | Pointing www to root, or subdomains to external services |
| MX | Directs email to mail server | mail.yourdomain.com (priority 10) | Email hosting or Google Workspace / Microsoft 365 |
| TXT | Stores text data for verification | v=spf1 include:_spf.google.com ~all | SPF, DKIM, DMARC, domain ownership verification |
| NS | Identifies authoritative nameservers | ns1.duelhost.io | Delegating DNS to a hosting provider |
| SRV | Specifies host and port for services | sip.tcp.yourdomain.com 5060 | VoIP, Microsoft Teams, game servers |
| CAA | Controls which CAs can issue SSL | 0 issue "letsencrypt.org" | Restricting SSL issuance for security |
A and AAAA Records
The A record maps your domain to the IPv4 address of your hosting server. When you sign up with a host, creating or updating the A record is the first step.
Most sites need two A records: one for the bare domain (yourdomain.com) and one for www.yourdomain.com — or a CNAME pointing www to the root domain. AAAA records do the same for IPv6, which now carries 42% of global internet traffic according to Google's IPv6 statistics page.
CNAME Records
A CNAME (Canonical Name) aliases one hostname to another. The most common use is pointing www.yourdomain.com to yourdomain.com, so both resolve to the same server.
CNAME records can't coexist with other record types on the same hostname. This is why the root domain almost always uses an A record, not a CNAME.
MX Records
MX (Mail Exchange) records tell other mail servers where to deliver email for your domain. Each MX record has a priority value — lower numbers get tried first.
A typical setup for a hosting provider's built-in email:
yourdomain.com MX 10 mail.yourdomain.com
For Google Workspace:
yourdomain.com MX 1 aspmx.l.google.com
yourdomain.com MX 5 alt1.aspmx.l.google.com
yourdomain.com MX 5 alt2.aspmx.l.google.com
yourdomain.com MX 10 alt3.aspmx.l.google.com
yourdomain.com MX 10 alt4.aspmx.l.google.com
TXT Records for Email Authentication
TXT records store text data, and their most important use is email authentication. Three protocols work together:
| Protocol | Purpose | Example Record |
|---|---|---|
| SPF | Lists servers authorized to send email for your domain | v=spf1 ip4:185.28.100.0/24 include:_spf.mailchannels.net ~all |
| DKIM | Publishes a public key for verifying email signatures | default._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCS..." |
| DMARC | Sets policy for what happens when email fails authentication | _dmarc.yourdomain.com TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]" |
Hosting providers like DuelHost that include email hosting with SPF, DKIM, and DMARC support configure these records automatically when you add a domain. For providers that don't, you'll need to create them manually.
CAA Records and SSL
CAA (Certificate Authority Authorization) records specify which certificate authorities are allowed to issue SSL certificates for your domain. Without a CAA record, any CA can issue a certificate. With one, only the CAs you've listed can.
For a site using Let's Encrypt (common with free SSL hosting):
yourdomain.com CAA 0 issue "letsencrypt.org"
yourdomain.com CAA 0 issue "sectigo.com"
yourdomain.com CAA 0 iodef "mailto:[email protected]"
The iodef tag tells the CA where to send notifications if someone attempts an unauthorized certificate issuance.
TTL and DNS Propagation
TTL (Time to Live) controls how long DNS resolvers cache your records before checking for updates. It's measured in seconds.
| TTL Value | Duration | Best For |
|---|---|---|
| 300 | 5 minutes | Pre-migration, fast record changes needed |
| 3600 | 1 hour | Active development, frequent DNS updates |
| 14400 | 4 hours | Standard production setting |
| 86400 | 24 hours | Stable production, maximum caching performance |
"DNS propagation" isn't a single event — it's thousands of resolvers worldwide independently expiring their cached records. When you change an A record with a 14400-second TTL, some resolvers update within minutes while others take up to 4 hours.
A 2024 APNIC measurement study across 12 million DNS resolvers found that 90% respect the published TTL value, 8% impose a minimum TTL floor of 30-300 seconds regardless, and 2% cache records for up to 48 hours ignoring TTL entirely.
Practical Rule
Lower your TTL to 300 seconds at least 24 hours before any planned DNS change. This ensures that by the time you make the change, most resolvers have already started using the shorter cache window.
Setting Up DNS for a New Hosting Account
Here's the standard process:
| Step | Action |
|---|---|
| 1 | Log into your domain registrar |
| 2 | Find DNS management or nameserver settings |
| 3a | Option A: Change NS records to host's nameservers (e.g., ns1.duelhost.io, ns2.duelhost.io) — simplest, hands over full DNS control |
| 3b | Option B: Create A record pointing to host's IP, plus MX records — more control, common with Cloudflare |
| 4 | Wait for propagation (5 min to 24 hours depending on TTL) |
| 5 | Verify: run dig yourdomain.com +short to confirm new server IP |
DNS Troubleshooting: Common Problems and Fixes
| Problem | Symptom | Fix |
|---|---|---|
| Propagation delays | Changed a record but site shows old content | Flush local DNS cache. macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. Windows: ipconfig /flushdns. Or test from a different network. |
| NXDOMAIN errors | "This site can't be reached" | Verify A record exists, confirm nameservers are correct at registrar, check domain hasn't expired |
| Wrong record pointing | Domain loads a different website or default hosting page | Check A record value in DNS panel and correct it to your hosting server's IP |
| Email not delivering | Email bounces or lands in spam | Verify MX records point to mail server, confirm SPF/DKIM TXT records are present. Use dig yourdomain.com MX to check. |
Using dig and nslookup for DNS Diagnostics
Two command-line tools every website owner should know.
dig (Linux/macOS)
dig yourdomain.com A +short # Returns the A record IP
dig yourdomain.com MX # Shows MX records with priority
dig yourdomain.com TXT # Lists all TXT records
dig @8.8.8.8 yourdomain.com A # Query Google's resolver specifically
nslookup (Windows/Mac/Linux)
nslookup yourdomain.com # Basic A record lookup
nslookup -type=MX yourdomain.com # MX record query
nslookup -type=TXT yourdomain.com # TXT record query
If dig returns different results than your DNS panel shows, propagation hasn't completed. Query multiple resolvers for the full picture: @1.1.1.1 (Cloudflare), @8.8.8.8 (Google), and @9.9.9.9 (Quad9).
DNS Security: DNSSEC
DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS responses, preventing attackers from poisoning DNS caches with fake records. Without DNSSEC, a compromised resolver can redirect your domain's traffic to a malicious server without visitors detecting the redirect.
According to ICANN's 2025 DNSSEC Deployment Report, only 34% of .com domains and 52% of .dk domains have DNSSEC enabled, despite the protocol being available for over a decade.
Enabling DNSSEC requires support from both your domain registrar and your DNS host. The process involves generating a DS (Delegation Signer) record at your DNS host and adding it to the registrar's settings. Many registrars now offer one-click DNSSEC activation.
DNS During a Hosting Migration
Moving to a new host is where DNS mistakes cause the most damage. Four steps to get it right:
| Step | Timing | Action |
|---|---|---|
| 1 | 48 hours before | Lower TTL on all records to 300 seconds |
| 2 | During migration | Keep old server running while testing on the new one |
| 3 | At cutover | Update only the A record (and www CNAME) — don't touch MX unless also migrating email |
| 4 | After cutover | Monitor 48 hours, keep old server active for 30 days |
Hosting providers with domain registration services — DuelHost supports 15+ TLDs including .com, .dk, .io, and .eu — simplify this because DNS management and hosting live in the same control panel. When the registrar and host are separate, you're coordinating changes across two dashboards, which increases the risk of mistakes.
Frequently Asked Questions
How long does DNS propagation actually take?
With standard TTL values (3600-14400 seconds), expect 1-4 hours for 90% of global resolvers to update. With a low TTL of 300 seconds, most resolvers update in 5-30 minutes. Full global propagation can take up to 48 hours, though that tail affects a tiny percentage of visitors.
Can I use Cloudflare for DNS and still host with a different provider?
Yes. Point your domain's nameservers to Cloudflare, then create A records in Cloudflare's dashboard pointing to your host's IP. You get Cloudflare's DNS performance and DDoS protection while keeping your hosting elsewhere. The trade-off is that DNS changes require logging into Cloudflare instead of your hosting panel.
What happens if I delete a DNS record by accident?
Recreate it immediately. If you know the values, the fix takes 30 seconds. If you don't, contact your hosting provider for the correct A record IP, MX records, and nameserver addresses. This is why documenting your DNS records before making changes matters — screenshot your full DNS zone or export it as a zone file.
Do I need to create DNS records for subdomains?
Yes. Each subdomain (blog.yourdomain.com, shop.yourdomain.com) needs its own A record or CNAME. Subdomains don't inherit the parent domain's A record automatically. Some hosting panels create the DNS record when you add a subdomain, but if DNS is managed elsewhere, you'll add it manually.
Should I use my hosting provider's nameservers or a third-party DNS service?
For most websites, the hosting provider's nameservers are fine. Third-party DNS (Cloudflare, Route 53, deSEC) makes sense for geographic load balancing, failover routing, or keeping DNS management independent of your host. Changing hosts is also slightly easier with separate DNS — you update one A record instead of switching nameservers.
Your Next Step
Open your terminal and run dig yourdomain.com ANY right now. Compare the output against the records in your DNS panel. If you spot missing MX records, absent SPF/DKIM entries, or a stale A record pointing to an old server, fix them today — every day with bad DNS is a day where visitors, email, or certificates could fail silently.