LinkedIn Hook

You bought a domain. You deployed your app. You pointed the DNS records. And then... nothing loads.

Sound familiar?

DNS is the layer most developers treat as a black box — until something breaks. Here is what you actually need to know to set it up, debug it, and never be stuck waiting 48 hours in the dark again:

Lower your TTL BEFORE making changes — not after. If you change records with a 24-hour TTL still active, you wait 24 hours. If you pre-lower to 300s, you wait 5 minutes.

dig +trace google.com shows you the entire resolution path — root → TLD → authoritative. Use it when things break.

"Works on my network but not yours" = different resolvers have different cached values. Check from multiple locations with whatsmydns.net.

DNS-based load balancing is simpler than you think: multiple A records for the same domain, resolver picks one.

CDNs use GeoDNS — the same domain returns a different IP depending on where your query originates. That's how cdn.example.com sends users in Tokyo to Tokyo edge servers and users in London to London edge servers.

This lesson covers: deploying with Vercel, dig command deep-dive, nslookup, propagation debugging, GeoDNS, CDN routing, and /etc/hosts for local dev.

Read the full lesson → [link]

#DNS #Networking #BackendEngineering #SystemDesign #InterviewPrep #DevTools

DNS in Practice thumbnail

What You'll Learn

How to set up DNS for a real domain, step by step, with a Vercel + Next.js example
Why DNS propagation takes up to 48 hours — and the TTL strategy to minimize it
How to check propagation from multiple locations with whatsmydns.net and dig
DNS-based load balancing: multiple A records, round-robin, weighted, and health-check routing
GeoDNS and latency-based routing — how CDNs use DNS to send you to the nearest edge server
The CDN routing pattern: your domain CNAME'd to a CDN hostname
The dig command: every flag you need, how to read the output sections, and status codes
nslookup as the Windows/cross-platform alternative
How to debug the four most common DNS issues developers encounter
Using /etc/hosts to override DNS for local development
DNS over HTTPS (DoH) and DNS over TLS (DoT) — why they exist and what they solve

Setting Up DNS for Your Domain

The Three Steps

Buy a domain from a registrar (Namecheap, Google Domains, Cloudflare, GoDaddy, etc.)
Point your NS (nameserver) records to your DNS provider. This tells the internet which nameservers are authoritative for your domain.
Add A, CNAME, MX, TXT records at your DNS provider for your actual services.

The registrar and DNS provider can be the same company (e.g., Cloudflare handles both), or different ones (Namecheap as registrar, AWS Route53 as DNS provider).

Real Example: Deploying a Next.js App to Vercel with a Custom Domain

Scenario: You own myapp.dev registered at Namecheap. You want to deploy a Next.js app to Vercel and serve it at myapp.dev and www.myapp.dev.

Step 1 — Add your domain in Vercel:

Go to Vercel Dashboard → Project → Settings → Domains → Add myapp.dev.

Vercel will show you what DNS records to add.

Step 2 — Point NS records to Vercel (option A — full delegation):

In Namecheap, update the nameservers to Vercel's nameservers:

ns1.vercel-dns.com
ns2.vercel-dns.com

Vercel then manages all DNS for you — it automatically adds the right A/CNAME records.

Step 2 — Or add A/CNAME records manually (option B — keep current NS):

If you want to keep your current nameservers (e.g., Cloudflare), add these records manually:

Type    Name    Value               TTL
A       @       76.76.21.21         Auto
CNAME   www     cname.vercel-dns.com  Auto

@ (apex/root) uses an A record pointing to Vercel's IP.
www uses a CNAME pointing to Vercel's CNAME hostname.

Why can't apex domains use CNAME? CNAME is forbidden at the apex (@) by the DNS standard because CNAMEs conflict with other records (like MX, SOA) that must exist at the apex. Vercel, Cloudflare, and Netlify work around this with proprietary A record IPs or flattened CNAMEs (ALIAS/ANAME records).

Step 3 — Wait for propagation.

Vercel will automatically issue an SSL certificate (via Let's Encrypt) once it can verify DNS resolution.

DNS Propagation — Why It Takes Time and How to Minimize It

Why Up to 48 Hours?

When you change a DNS record, the old record is still cached at resolvers across the internet based on its TTL (Time to Live). A resolver that cached your old A record with a TTL of 86400 (24 hours) will continue serving the old IP for up to 24 hours after your change, regardless of what your authoritative nameserver now says.

The "up to 48 hours" figure is a conservative upper bound — most default TTLs are 3600s (1 hour) or 86400s (24 hours). If every resolver in the chain has cached a 24-hour TTL, worst case is 24 hours (not 48). But ISP-level resolvers sometimes ignore TTLs and cache longer, hence the 48-hour industry rule of thumb.

The TTL Migration Strategy

The professional way to minimize propagation pain:

Day -2 (48h before change):  Lower TTL to 300s (5 minutes)
                              Wait for existing long-TTL caches to expire

Day 0  (change day):         Make your DNS change
                              Propagation now takes ~5 minutes instead of 24+ hours

Day +1 (after change):       Raise TTL back to 3600s or 86400s
                              High TTL = fewer DNS queries = less load on your nameserver

The key insight: you must lower the TTL before you make changes, then wait for the current TTL to expire. If you lower and immediately change, resolvers may have cached the old TTL value (e.g., 24 hours) and will ignore the new 300s TTL for 24 hours.

Checking DNS Propagation

whatsmydns.net

Go to whatsmydns.net → Enter your domain → Select record type (A, CNAME, MX, etc.)

It queries DNS resolvers in 20+ geographic locations simultaneously. You can see which regions have the new IP and which are still on the old one. Invaluable when you "can't reproduce the bug" — your local resolver has the new record but your user in Germany doesn't.

dig with a specific resolver

# Query Google's public resolver (bypasses your local/ISP resolver)
dig @8.8.8.8 myapp.dev

# Query Cloudflare's public resolver
dig @1.1.1.1 myapp.dev

# Query your ISP's resolver (implicit — whatever your system DNS is set to)
dig myapp.dev

Comparing the output of dig @8.8.8.8 vs dig @1.1.1.1 vs plain dig tells you exactly which resolvers have propagated and which haven't.

DNS-Based Load Balancing

Multiple A Records (Round-Robin)

You can add multiple A records for the same hostname:

example.com    A    203.0.113.10
example.com    A    203.0.113.11
example.com    A    203.0.113.12

The resolver returns all three IPs in the DNS response. The client (browser, HTTP client) typically tries the first one. Resolvers rotate the order of returned IPs on each query — this is DNS round-robin.

Limitation: DNS round-robin is a blunt instrument. It has no awareness of server health. If 203.0.113.10 goes down, clients that receive it as their first IP will fail until they retry the next one (or the cached answer expires).

Weighted Routing (AWS Route53)

AWS Route53 supports weighted records:

example.com    A    203.0.113.10    Weight: 80
example.com    A    203.0.113.11    Weight: 20

Route53 serves the first IP 80% of the time and the second 20% of the time. Useful for canary deployments — route 5% of traffic to a new version and 95% to the stable version.

Health-Check-Based Routing (AWS Route53)

Route53 can monitor endpoint health and automatically remove unhealthy records from DNS responses. If 203.0.113.10 fails its health check, Route53 stops returning it — zero manual intervention.

GeoDNS and Latency-Based Routing

How GeoDNS Works

With GeoDNS (also called geographic routing), the same domain name returns a different IP address depending on where the DNS query originates.

example.com query from Tokyo   → returns 103.21.244.10  (Tokyo server)
example.com query from London  → returns 195.85.23.5    (London server)
example.com query from New York → returns 23.45.67.89   (New York server)

The authoritative nameserver determines the geographic origin of the recursive resolver's IP address and returns the appropriate record.

AWS Route53 Geolocation Routing Example

In Route53, you configure multiple records for example.com, each tagged with a geographic scope:

example.com    A    103.21.244.10   → Continent: Asia
example.com    A    195.85.23.5     → Country: United Kingdom
example.com    A    23.45.67.89     → Default (everyone else)

Route53 uses GeoIP databases to categorize the resolver's origin and return the matching record.

Latency-based routing is similar but uses actual measured latency between AWS regions and the resolver's location — Route53 returns the IP of whichever AWS region has the lowest latency to the requesting resolver.

CDNs Use GeoDNS at Massive Scale

When you CNAME example.com → example.cloudfront.net, every DNS query for example.cloudfront.net hits CloudFront's authoritative nameservers, which return the IP of the nearest CloudFront edge server. This is how a CDN with 400+ edge locations globally ensures users always hit a nearby cache without any application logic.

CDN Routing Pattern

The standard CDN DNS setup:

# Your DNS records:
example.com    CNAME    example.cloudfront.net

# CloudFront's DNS (managed by AWS):
example.cloudfront.net → (GeoDNS) → 13.32.70.200  (nearest edge)

Your domain CNAME's to a CDN-controlled hostname. The CDN hostname uses GeoDNS to return the nearest edge server IP. The client connects to that edge, which serves cached content or fetches from your origin if it's a cache miss.

The dig Command — Deep Dive

dig (Domain Information Groper) is the essential DNS debugging tool for Linux/macOS. Here are the commands you need, with real sample output.

Basic A Record Lookup

$ dig google.com

; <<>> DiG 9.18.1 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37214
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             287     IN      A       142.250.80.46

;; Query time: 12 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)
;; WHEN: Tue Apr 22 10:00:00 UTC 2026
;; MSG SIZE  rcvd: 55

Reading the output:

Section	Meaning
`HEADER`	`status: NOERROR` = query succeeded. `NXDOMAIN` = domain doesn't exist. `SERVFAIL` = server error.
`QUESTION SECTION`	What was asked — `google.com IN A` means "A record for google.com in the Internet class"
`ANSWER SECTION`	The result — `287` is the TTL in seconds remaining, `A` is the record type, `142.250.80.46` is the IP
`Query time`	How long the lookup took (in milliseconds)
`SERVER`	Which DNS resolver answered the query (your local resolver at 192.168.1.1)

Query a Specific Record Type

# MX records (mail servers)
$ dig google.com MX

;; ANSWER SECTION:
google.com.             600     IN      MX      10 smtp.google.com.

# TXT records (SPF, DKIM, domain verification)
$ dig google.com TXT

;; ANSWER SECTION:
google.com.             3600    IN      TXT     "v=spf1 include:_spf.google.com ~all"
google.com.             3600    IN      TXT     "google-site-verification=wD8N7i1JTNTkezJ49swvWW48f8_9xveREV4oB-0Hf5o"

# NS records (nameservers)
$ dig google.com NS

;; ANSWER SECTION:
google.com.             21599   IN      NS      ns1.google.com.
google.com.             21599   IN      NS      ns2.google.com.
google.com.             21599   IN      NS      ns3.google.com.
google.com.             21599   IN      NS      ns4.google.com.

All Records

$ dig google.com ANY

Note: Many DNS providers block ANY queries or return minimal results due to DDoS abuse. Use specific record types when possible.

Short Output — IP Only

$ dig +short google.com
142.250.80.46

Useful in scripts when you just want the IP:

SERVER_IP=$(dig +short myapp.dev)
echo "Connecting to $SERVER_IP"

Trace the Full Resolution Path

This is the most powerful debugging flag. It shows every step from root to authoritative nameserver:

$ dig +trace google.com

; <<>> DiG 9.18.1 <<>> +trace google.com
;; global options: +cmd

.                       518400  IN      NS      a.root-servers.net.
.                       518400  IN      NS      b.root-servers.net.
.                       518400  IN      NS      m.root-servers.net.
;; Received 811 bytes from 192.168.1.1#53(192.168.1.1) in 5 ms

com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
com.                    172800  IN      NS      c.gtld-servers.net.
;; Received 1171 bytes from 198.41.0.4#53(a.root-servers.net) in 24 ms

google.com.             172800  IN      NS      ns1.google.com.
google.com.             172800  IN      NS      ns2.google.com.
google.com.             172800  IN      NS      ns3.google.com.
google.com.             172800  IN      NS      ns4.google.com.
;; Received 292 bytes from 192.5.6.30#53(a.gtld-servers.net) in 18 ms

google.com.             300     IN      A       142.250.80.46
;; Received 55 bytes from 216.239.32.10#53(ns1.google.com) in 11 ms

Reading +trace:

First block — Your local resolver asks the root nameservers (.). The root returns the TLD nameservers for .com.
Second block — Your resolver asks a .com TLD nameserver. It returns the authoritative nameservers for google.com.
Third block — Your resolver asks Google's authoritative nameserver (ns1.google.com). It returns the final A record.

This trace is invaluable when you suspect a misconfiguration at a specific level — a wrong NS delegation, missing glue records, etc.

Query a Specific Resolver

# Use Google's public resolver (8.8.8.8)
$ dig @8.8.8.8 google.com

# Use Cloudflare's public resolver (1.1.1.1)
$ dig @1.1.1.1 google.com

# Use your authoritative nameserver directly (bypass caching)
$ dig @ns1.google.com google.com

Querying the authoritative nameserver directly (@ns1.google.com) bypasses all caching and shows exactly what the authoritative server is configured to return. If this looks right but resolvers return wrong data, propagation is still in progress.

nslookup — Windows / Cross-Platform Alternative

nslookup ships on Windows, macOS, and Linux. It is less powerful than dig but widely available.

# Basic lookup
nslookup google.com

# Specific record type
nslookup -type=MX google.com
nslookup -type=TXT google.com
nslookup -type=NS google.com

# Query a specific resolver
nslookup google.com 8.8.8.8

# Interactive mode
nslookup
> set type=MX
> google.com
> exit

Sample output:

$ nslookup google.com

Server:         192.168.1.1
Address:        192.168.1.1#53

Non-authoritative answer:
Name:   google.com
Address: 142.250.80.46

Non-authoritative answer means the response came from a caching resolver, not the authoritative nameserver directly — expected behavior in most lookups.

DNS Status Codes — Know the Difference

Status	Meaning	What to do
`NOERROR`	Query succeeded	Check the ANSWER section. If it is empty, the record type doesn't exist for this domain.
`NXDOMAIN`	Domain doesn't exist	The domain is not registered, or your nameservers aren't authoritative. Check NS records.
`SERVFAIL`	Server failed to answer	The authoritative nameserver returned an error. Possible misconfiguration on the DNS provider's side.
`REFUSED`	Resolver refused the query	The resolver doesn't service queries from your IP.

Common DNS Issues — How to Debug Them

Issue 1: "Site not loading after DNS change"

Diagnosis:

# Check what Google's resolver sees
dig @8.8.8.8 myapp.dev +short

# Check what Cloudflare's resolver sees
dig @1.1.1.1 myapp.dev +short

# Check what your authoritative nameserver sees
dig @ns1.yourprovider.com myapp.dev +short

If the authoritative nameserver returns the new IP but public resolvers return the old one — propagation is still in progress. Wait.

If even the authoritative nameserver returns the old IP — your DNS change was not saved correctly.

Issue 2: "Works on some networks, not others"

Different resolvers cache independently. Your home ISP resolver may have the new IP while your office ISP resolver is still on the old one.

Verification: Use whatsmydns.net to check multiple geographic resolvers simultaneously. Tell the affected person on the "wrong" network to try:

# Temporarily use Google's resolver
nslookup myapp.dev 8.8.8.8

If 8.8.8.8 resolves correctly, their ISP's resolver just hasn't refreshed yet.

Issue 3: "Email not arriving"

Email delivery depends on MX records AND SPF/DKIM TXT records being correct.

# Check MX records — which mail servers receive email for this domain
dig MX yourdomain.com

# Check SPF record — which servers are authorized to send email from this domain
dig TXT yourdomain.com

# Expected SPF format:
# "v=spf1 include:_spf.google.com ~all"

# Check DKIM record (selector varies by provider — 'google' is the selector for Google Workspace)
dig TXT google._domainkey.yourdomain.com

If MX records are missing or wrong, email fails to deliver. If SPF/DKIM TXT records are missing or wrong, email delivers but lands in spam.

Issue 4: "NOERROR but the site doesn't load"

$ dig myapp.dev

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345

;; QUESTION SECTION:
;myapp.dev.     IN  A

;; ANSWER SECTION:
;; (empty)

NOERROR with an empty ANSWER section means the domain exists and DNS is working, but there is no A record for this hostname. The most common cause: you added a CNAME for www.myapp.dev but forgot the apex myapp.dev A record (or vice versa).

/etc/hosts for Local Development

/etc/hosts is a local file on your machine that overrides DNS for specific domains. Lookups for hostnames listed here never reach a DNS resolver — the OS returns the configured IP directly.

Location:

Linux/macOS: /etc/hosts
Windows: C:\Windows\System32\drivers\etc\hosts

Format:

# /etc/hosts
127.0.0.1    localhost
::1          localhost

# Local development overrides
127.0.0.1    myapp.local
127.0.0.1    api.myapp.local
127.0.0.1    staging.myapp.com    # Test staging config before DNS propagates

Use cases:

Testing before DNS propagates — point staging.myapp.com to your local or staging IP to test SSL certificates, routing, and app behavior before DNS is live for real users.
Local microservices — map service hostnames (auth.local, api.local) to 127.0.0.1 so your local services communicate using production-like hostnames.
Blocking domains — point ad/tracking domains to 0.0.0.0 (the null route).

Example workflow:

# You're about to migrate myapp.com from old server (203.0.113.10) to new server (203.0.113.20).
# Before changing DNS:

# 1. Add to /etc/hosts:
203.0.113.20    myapp.com

# 2. Test everything — your machine now hits the new server even though DNS still points to old.
# 3. Remove the /etc/hosts entry once you're confident.
# 4. Update DNS — everyone else now migrates as propagation completes.

Important: /etc/hosts only affects the machine it is on. It is not a DNS solution for teams or production.

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

Traditional DNS queries travel over UDP port 53 in plain text. Anyone on the network path — your ISP, router, anyone doing a man-in-the-middle — can see every DNS query you make. This is a privacy and security problem.

DNS over HTTPS (DoH)

DoH wraps DNS queries in HTTPS (TLS encrypted HTTP/2 or HTTP/3) traffic, typically on port 443. It is indistinguishable from regular web traffic.

Used by: Firefox (with Cloudflare by default), Chrome, Brave
Public DoH endpoints: https://dns.cloudflare.com/dns-query, https://dns.google/dns-query

DNS over TLS (DoT)

DoT encrypts DNS queries using TLS but uses a dedicated port 853. Easier for network administrators to identify and potentially block.

Used by: Android 9+ ("Private DNS" setting), some enterprise resolvers

What They Solve

Problem	Traditional DNS (port 53)	DoH / DoT
Query privacy	Queries visible to ISP and network	Queries encrypted end-to-end
DNS spoofing	Possible on network path	Much harder (TLS certificate validation)
ISP filtering	ISP can intercept and modify DNS	Bypasses ISP resolver (goes direct to DoH provider)

For backend engineers: DoH/DoT matters primarily for privacy-sensitive client-side applications and understanding why network-level DNS filtering/monitoring is increasingly difficult.

Common Mistakes

Making DNS changes without first lowering TTL — if your A record has a 86400s (24-hour) TTL and you change it, every resolver that has recently cached it will serve the old IP for up to 24 hours. The fix: lower TTL to 300s at least 24-48 hours before making your change. This gives time for the high-TTL caches to expire naturally, so by change time all resolvers will refresh within 5 minutes.
Testing DNS from only one location — your local resolver might already have the new IP cached from a fresh query, while a resolver in another region cached the old record 5 minutes before your change and won't refresh for another 55 minutes. Always verify with whatsmydns.net and dig @8.8.8.8 / dig @1.1.1.1 to get an objective multi-region view.
Forgetting to add both the apex record and the www record — a common mistake is adding www.example.com CNAME but forgetting the apex example.com A record (or vice versa). Users who type the URL without www get a browser error while www. works fine. Always configure both, and set up a redirect so one canonical form (www or apex) redirects to the other.

Interview Questions

Q1: How would you debug why your domain isn't resolving to the correct IP?

Work through the resolution chain from authoritative to recursive:

Query the authoritative nameserver directly (dig @ns1.yourprovider.com yourdomain.com) to verify the change is actually saved. If the authoritative nameserver returns the wrong IP, fix the DNS record — propagation is irrelevant until the source is correct.
If the authoritative server looks right, query public resolvers (dig @8.8.8.8 yourdomain.com, dig @1.1.1.1 yourdomain.com) to check propagation status.
Use whatsmydns.net to see which geographic regions have the new record and which are still on the old one.
Check the TTL — if the old record had a high TTL, resolvers may be caching it for hours. Nothing to do but wait (or, for next time: pre-lower TTL).
Use dig +trace yourdomain.com to see if there are delegation issues (NS records pointing to the wrong nameservers).

Q2: What is DNS propagation and why can it take up to 48 hours?

DNS propagation is the time it takes for a DNS change to be reflected across all resolvers globally. When you update a DNS record, only your authoritative nameserver has the new value immediately. Every resolver (ISP, public, enterprise) that has previously cached the old record will continue serving it until the TTL expires. TTL values range from 60 seconds to 86400 seconds (24 hours) or more. In the worst case, a resolver cached the old record with a 24-hour TTL seconds before your change — it won't expire for nearly 24 hours. Add ISPs that disrespect TTLs and cache longer, and you can approach 48 hours. To minimize: lower TTL to 300s well before the change.

Q3: How can you use DNS for load balancing?

Multiple strategies depending on requirements:

Multiple A records (DNS round-robin) — add multiple A records for the same hostname. The resolver returns all IPs; clients use the first. Resolvers rotate order on each query. Simple but no health-awareness — if a server is down, DNS still returns its IP.
Weighted routing (Route53) — assign weights to records; Route53 distributes queries proportionally. Good for canary deployments.
Health-check-based routing (Route53) — Route53 monitors endpoints and automatically removes unhealthy IPs from DNS responses.
GeoDNS / latency-based routing — return different IPs based on the geographic origin of the query. Users in Asia get the Asian server IP, users in Europe get the European IP. CDNs use this at scale.

Q4: What is the difference between dig and nslookup?

Both query DNS servers and display results. dig (Linux/macOS) is more powerful: it shows full response sections (QUESTION, ANSWER, AUTHORITY, ADDITIONAL), reports the querying server and response time, and has advanced flags like +trace (full resolution path), +short (IP only), and +nocmd (clean output for scripting). nslookup is available on Windows, macOS, and Linux. It has a simpler, more readable output format and an interactive mode, but lacks dig's trace capability and detailed section breakdown. For production DNS debugging, dig is the professional choice; nslookup is useful on Windows machines where dig isn't installed.

Q5: What is GeoDNS and how do CDNs use it?

GeoDNS is a DNS technique where the authoritative nameserver returns different IP addresses for the same hostname depending on the geographic origin of the DNS query. The nameserver identifies the resolver's location using GeoIP databases and returns the IP of the nearest or most appropriate server. CDNs implement this at scale: your domain CNAMEs to a CDN hostname (e.g., example.cloudfront.net). CloudFront's authoritative nameservers use GeoDNS to return the IP of the nearest edge location — so a user in Tokyo gets a Tokyo edge server IP and a user in London gets a London edge server IP. This routes users to the nearest cache without any application-level logic, reducing latency significantly. AWS Route53 supports both geolocation routing (by country/continent) and latency-based routing (by measured latency to AWS regions).

Quick Reference — Cheat Sheet

Essential dig Commands

Command	What it does
`dig example.com`	Basic A record lookup
`dig example.com MX`	Query MX records
`dig example.com TXT`	Query TXT records (SPF, DKIM)
`dig example.com NS`	Query nameserver records
`dig example.com CNAME`	Query CNAME records
`dig example.com ANY`	All available records
`dig +short example.com`	IP address only (scriptable)
`dig +trace example.com`	Full resolution path (root → TLD → auth)
`dig @8.8.8.8 example.com`	Query Google's public resolver
`dig @1.1.1.1 example.com`	Query Cloudflare's public resolver
`dig @ns1.yourprovider.com example.com`	Query authoritative nameserver directly
`dig +short example.com MX`	MX servers only, no noise

nslookup Equivalents

nslookup command	Equivalent dig
`nslookup example.com`	`dig example.com`
`nslookup -type=MX example.com`	`dig example.com MX`
`nslookup example.com 8.8.8.8`	`dig @8.8.8.8 example.com`

DNS Status Codes

Code	Meaning
`NOERROR`	Success (check ANSWER section)
`NXDOMAIN`	Domain does not exist
`SERVFAIL`	Server error / misconfiguration
`REFUSED`	Resolver refused the query

DNS Debugging Decision Tree

Domain not resolving correctly?
        |
        v
Query authoritative NS directly:
  dig @ns1.yourprovider.com yourdomain.com
        |
   +----+----+
   |         |
Wrong IP    Correct IP
   |         |
Fix DNS      |
record       v
         Query public resolvers:
           dig @8.8.8.8 yourdomain.com
           dig @1.1.1.1 yourdomain.com
                 |
           +-----+-----+
           |           |
        Wrong IP    Correct IP
           |           |
      Propagation      |
      in progress      v
      (check TTL)  Check from multiple
           |       regions: whatsmydns.net
           |             |
           v         +---+---+
        Wait or    Some    All
        flush      fail    fail
        local        |       |
        cache      ISP     CDN or
                   cache   proxying
                   issue   issue

TTL Migration Strategy

T-48h  Lower TTL → 300s          (old high-TTL caches will expire over next 48h)
T-24h  Verify TTL=300 is live     dig +short yourdomain.com (check TTL in answer)
T-0    Make DNS change            change A/CNAME record
T+5m   Verify propagation         dig @8.8.8.8 + whatsmydns.net
T+1h   Raise TTL → 3600s          reduce DNS query load on nameserver

/etc/hosts Quick Reference

# File location:
# Linux/macOS: /etc/hosts
# Windows:     C:\Windows\System32\drivers\etc\hosts

# Format: IP_ADDRESS  HOSTNAME  [ALIAS]

127.0.0.1    myapp.local
127.0.0.1    api.myapp.local
203.0.113.20 staging.myapp.com    # Pre-test before DNS change
0.0.0.0      ads.example.com      # Block a domain

Previous: Lesson 6.3 — DNS Record Types (03-dns-record-types.md) Next: Lesson 7.1 — Ping (../ch07-diagnostic-tools/01-ping.md)

This is Lesson 6.4 of the Networking Interview Prep Course — 8 chapters, 32 lessons.

DNS in Practice