DNS Lookups — Why Your MX Change Took 48 Hours to Propagate

Every single time you open a browser and visit a website, something remarkable happens in the background — something so fast and so reliable that most developers take it completely for granted. Your computer doesn't actually know where 'youtube.com' lives. It only speaks in numbers. DNS is the invisible system that bridges the human-readable world of domain names and the machine-readable world of IP addresses, and it handles over a trillion lookups every single day across the planet.

Before DNS existed — and yes, there was a time before it — every computer on the internet had to maintain a single text file called HOSTS.TXT that listed every known hostname and its IP address. A central team at Stanford Research Institute would update it, and sysadmins everywhere had to manually download the latest copy. When the internet had a few hundred machines, this was just about manageable. When it grew to thousands? The system collapsed under its own weight. DNS was invented in 1983 by Paul Mockapetris to solve exactly this scalability crisis — and the solution he came up with is still running the internet today.

By the end of this article you'll be able to explain exactly what happens between typing a URL and a webpage loading, describe the hierarchy of DNS servers and the role each one plays, understand what DNS records like A, CNAME, and MX actually do, and confidently answer DNS questions in a technical interview. No prior networking knowledge needed — we're building this from the ground up.

IP Addresses: The Numbers the Internet Actually Uses

Before DNS makes any sense, you need to understand what it's translating TO. Every device connected to the internet — your laptop, your phone, a web server in a data centre in Virginia — has a unique numerical address called an IP address. Think of it like a home address, except for computers.

An IPv4 address looks like this: 142.250.80.46. Four numbers, each between 0 and 255, separated by dots. That specific address is one of Google's servers. Your computer could reach Google by typing that number directly into your browser — try it. It works. But nobody wants to memorise 142.250.80.46 instead of 'google.com'.

IPv6 addresses look even worse: 2607:f8b0:4004:c09::6a. Humans are terrible at remembering these. Computers are great at them. DNS exists purely to bridge that gap — to let humans use words while computers use numbers. Every domain name on the internet is ultimately just a friendly alias for one or more IP addresses.

# This command performs a DNS lookup from your terminal.
# It asks: "What IP address does 'google.com' map to?"
# nslookup is available on Windows, macOS, and Linux.

nslookup google.com

# You can also use 'dig' on macOS/Linux for more detail:
dig google.com +short

# Let's also look up a smaller site to see a simpler single-IP result:
nslookup github.com

The DNS Hierarchy: Four Servers, One Answer

DNS isn't a single giant database. If it were, it would be the most catastrophic single point of failure in human history. Instead, DNS is a beautifully distributed hierarchy of servers spread across the entire planet. When your computer needs to resolve a domain name, it talks to up to four different types of server in sequence until it gets an answer.

Think of it like asking for directions in an unfamiliar city. You first ask your hotel concierge (your local DNS resolver). They might know the answer from memory. If not, they call the city's central tourist office (the Root Nameserver). The tourist office doesn't know the exact restaurant, but they say 'for Italian restaurants, call the Italian Quarter office' (the TLD Nameserver). The Italian Quarter office then gives you the exact address (the Authoritative Nameserver). Four stops, one answer.

Here are the four players:

1. RECURSIVE RESOLVER — Your ISP or a public DNS service (like 8.8.8.8 — Google's DNS). This is the server your device asks first. It does all the legwork of talking to the other servers on your behalf.
2. ROOT NAMESERVER — There are 13 logical root nameservers (labelled A through M) run by organisations like NASA and ICANN. They don't know IP addresses — they just know which TLD nameserver to contact for '.com', '.org', '.uk', etc.
3. TLD NAMESERVER — TLD stands for Top-Level Domain. The .com TLD nameserver knows which Authoritative Nameserver is responsible for every .com domain ever registered.
4. AUTHORITATIVE NAMESERVER — This is the final authority. It's managed by whoever owns the domain (or their hosting provider). It holds the actual DNS records and gives the definitive answer.

# The 'dig +trace' command shows you the FULL DNS resolution journey.
# Watch it walk through all four server types step by step.
# Run this in your terminal (macOS or Linux). On Windows, use WSL.

dig thecodforge.io +trace

# WHAT YOU'LL SEE:
# Step 1 — Your resolver contacts a ROOT nameserver (e.g., a.root-servers.net)
# Step 2 — Root server says: "for .io domains, ask this TLD server"
# Step 3 — TLD server says: "for thecodeforge.io, ask THIS authoritative server"
# Step 4 — Authoritative server gives the actual IP address

# You can also see exactly WHICH root servers exist:
dig . NS +short

DNS Records Demystified: A, CNAME, MX, TXT and More

DNS isn't just about mapping domain names to IP addresses. It's a full-blown database of records that controls how your domain behaves across the internet. Each record type answers a different question about your domain.

Think of DNS records like different departments in a company. The A Record department handles 'where is the website?'. The MX Record department handles 'where should emails go?'. The CNAME department handles 'this name is just an alias for another name'. They all live in the same building (your Authoritative Nameserver) but do completely different jobs.

Here are the records every developer needs to know:

— A RECORD: Maps a domain name directly to an IPv4 address. This is the most fundamental record. 'thecodeforge.io → 104.21.45.67'.

— AAAA RECORD: Same as A, but for IPv6 addresses. The four A's stand for 'quad-A'.

— CNAME RECORD: 'Canonical Name' — an alias. 'www.thecodeforge.io → thecodeforge.io'. Points one name to another name, not directly to an IP.

— MX RECORD: 'Mail Exchange' — tells the internet which server handles email for your domain. Without this, nobody can email you at your domain.

— TXT RECORD: Plain text attached to a domain. Used for email verification (SPF, DKIM), proving domain ownership to Google/GitHub, and security configs.

— NS RECORD: 'Nameserver' — declares which servers are authoritative for this domain. When you buy a domain and point it to Cloudflare, you're updating NS records.

— TTL (Time To Live): Not a record type, but every record has one. It's a number in seconds telling DNS servers how long to cache this record before checking again. TTL of 3600 means 'cache this for 1 hour'.

# Let's query specific DNS record types for real domains.
# The syntax is: dig <domain> <RECORD_TYPE>

# 1. A Record — get the IPv4 address for github.com
dig github.com A +short
# Output: 140.82.114.4

# 2. MX Record — find where GitHub's email servers are
dig github.com MX +short
# Output: 1 aspmx.l.google.com.  (GitHub uses Google Workspace for email)

# 3. CNAME Record — www is often a CNAME alias
dig www.github.com CNAME +short
# Output: github.com.  (www.github.com is just an alias for github.com)

# 4. TXT Records — see domain verification and security records
dig github.com TXT +short
# Output includes SPF record: "v=spf1 ip4:192.30.252.0/22 include:_netblocks.google.com ~all"

# 5. NS Records — which nameservers are authoritative for github.com?
dig github.com NS +short
# Output:
# ns-1283.awsdns-32.org.   <-- GitHub uses Amazon Route 53
# ns-1707.awsdns-21.co.uk.
# ns-421.awsdns-52.com.
# ns-520.awsdns-01.net.

# 6. Check TTL — how long is this record cached? (look at the number after IN)
dig github.com A
# In the ANSWER SECTION you'll see something like:
# github.com.  60  IN  A  140.82.114.4
#              ^^--- TTL of 60 seconds — GitHub refreshes DNS frequently

DNS Caching, TTL and Why Your Changes Seem to Take Forever

You've just launched your new website. You updated the DNS records. You refresh the browser. Still showing the old site. You check the DNS settings — everything looks right. What's happening? The answer is caching, and understanding it will save you hours of frustration.

Every DNS resolver along the lookup chain caches the answer it receives for exactly as long as the TTL (Time To Live) says. If your A record has a TTL of 86400 (24 hours), every resolver that looked up your domain in the past 24 hours won't check again until that timer runs out. Even if you change the IP address at the Authoritative Nameserver, millions of resolvers worldwide are still serving the old answer from their cache.

This is called 'DNS propagation' — and it's not actually propagation in the way people imagine (records pushing outward). It's really just the world's cached copies expiring and fetching fresh answers at different times. Different users around the world will see the new records at different times depending on when their local resolver's cache expires.

The professional move: before making a big DNS change (like moving a site to a new host), lower your TTL to 300 seconds (5 minutes) a day or two in advance. Once traffic is migrated successfully, raise it back to 3600 or 86400 for better performance.

# Python's built-in 'socket' library can perform basic DNS lookups.
# For richer DNS querying, we'll also use 'dnspython' — install it with:
# pip install dnspython

import socket
import dns.resolver  # from the dnspython library

# ─────────────────────────────────────────────
# METHOD 1: Basic lookup using Python's socket module
# This asks your OS's configured DNS resolver for an IP address
# ─────────────────────────────────────────────
domain_name = "github.com"

# getaddrinfo returns a list of (family, type, proto, canonname, sockaddr) tuples
results = socket.getaddrinfo(domain_name, 80)  # port 80 = HTTP

print(f"IP addresses for {domain_name}:")
for result in results:
    ip_address = result[4][0]  # sockaddr is a tuple; index 0 is the IP
    print(f"  → {ip_address}")

print()

# ─────────────────────────────────────────────
# METHOD 2: Querying specific record types with dnspython
# This gives us full control — like running 'dig' from Python
# ─────────────────────────────────────────────

# Query the A record (IPv4 address)
print(f"A Records for {domain_name}:")
a_records = dns.resolver.resolve(domain_name, 'A')
for record in a_records:
    print(f"  IP Address : {record.address}")
    print(f"  TTL        : {a_records.rrset.ttl} seconds")

print()

# Query the MX record (mail servers)
print(f"MX Records for {domain_name}:")
mx_records = dns.resolver.resolve(domain_name, 'MX')
for record in mx_records:
    # MX records have a 'preference' (priority) — lower number = higher priority
    print(f"  Mail Server : {record.exchange}  (Priority: {record.preference})")

print()

# Query TXT records (often used for domain verification)
print(f"TXT Records for {domain_name}:")
txt_records = dns.resolver.resolve(domain_name, 'TXT')
for record in txt_records:
    # Decode bytes to string for readable output
    decoded_text = b"".join(record.strings).decode('utf-8')
    print(f"  TXT : {decoded_text[:80]}...")  # Truncate long records for display

DNS in Production: Monitoring, Troubleshooting, and Pitfalls

DNS looks simple on paper — a few records, a cache, done. But in a production environment, DNS failures are notoriously hard to diagnose because they manifest as unrelated symptoms: 'the site is down', 'email isn't sending', 'API calls timeout'. The root cause is often a DNS misconfiguration that has been silently wrong for hours or days.

Here's what you need to monitor and how to troubleshoot the most common production DNS scenarios:

Monitoring - Track DNS query latency from your application servers. Spikes often indicate resolver overload or network issues. - Set up synthetic checks that resolve your own domains from multiple geographic locations. If any region fails, you'll know before users do. - Watch for NXDOMAIN (non-existent domain) responses. A sudden increase often means a client typo or a misconfigured CNAME.

Troubleshooting flow 1. Start with 'dig @your-resolver yourdomain.com A'. Check the ANSWER SECTION. 2. If you get a response but it's wrong, check the authoritative NS: 'dig @your-ns yourdomain.com A'. 3. If authoritative is correct but public resolvers show old data, you're waiting out TTL. 4. If no response at all, check firewall rules (UDP/53 and TCP/53) and that your resolver IP is reachable.

Common pitfalls in production - Using the same TTL for all records without planning for changes. - Putting a CNAME at the root domain — many providers now throw an error, but some silently break. - Not having a fallback resolver. If your primary resolver (like your ISP's) goes down, your app goes down. Configure a secondary. - Forgetting that DNSSEC can break resolution if misconfigured. Always test with 'delv' before enabling.

# Quick DNS health check script
# Run this to verify your domain's records from multiple angles

DOMAIN="yourdomain.com"
EXPECTED_IP="203.0.113.10"

# 1. Query a public resolver to see what users see
echo "=== Public resolver (Google 8.8.8.8) ==="
PUBLIC_IP=$(dig @8.8.8.8 $DOMAIN A +short)
echo "Resolved IP: $PUBLIC_IP"

if [ "$PUBLIC_IP" != "$EXPECTED_IP" ]; then
  echo "WARNING: Public resolver does not match expected IP!"
fi

# 2. Query the authoritative nameserver directly
echo ""
echo "=== Authoritative nameserver ==="
NS=$(dig $DOMAIN NS +short | head -1)
dig @$NS $DOMAIN A +short

# 3. Check MX records for email
echo ""
echo "=== MX Records ==="
dig $DOMAIN MX +short

# 4. Check DNS response time
echo ""
echo "=== Response time ==="
time dig @8.8.8.8 $DOMAIN A +short > /dev/null