johnhooks

Tag: learning

  • How the Internet Finds Your Server

    How the Internet Finds Your Server

    As a web developer, I’ve been working on websites without really understanding DNS. DNS has been coming up more frequently at work and I realized it was time to dig deeper.

    This series is my journey to truly understand DNS from the ground up. If you’re a developer who’s ever felt lost when DNS issues arise, let’s learn together. We’ll start with the fundamentals and build up to troubleshooting complex issues like pros.

    The Problem DNS Solves

    Let’s start with the basics. Computers communicate using IP addresses – numbers like 192.0.2.1 or 2001:db8::1. But imagine telling your users to visit 192.0.2.1 to see your website. Not exactly memorable, right?

    DNS (Domain Name System) is the translation service that converts human-friendly names like hackipatch.com into the IP addresses that computers actually use. Think of it like your phone’s contacts app – you don’t memorize phone numbers anymore, you just tap on “Mom” and your phone handles the number.

    But here’s where it gets interesting: unlike your contacts app, DNS isn’t stored in one place. It’s distributed across thousands of servers worldwide, and the path from domain name to IP address involves multiple steps that can each fail in their own special way.

    The DNS Resolution Journey

    When you type example.com into your browser, here’s what actually happens:

    Step 1: Local Cache Check

    Your computer first checks if it already knows the answer. Operating systems cache DNS responses to speed things up. If you visited the site recently, you might get your answer here.

    Step 2: Recursive Resolver

    If there’s no cached answer, your computer asks a recursive resolver (usually your ISP’s DNS server or a public one like 8.8.8.8). This server does the heavy lifting of finding the answer for you.

    Step 3: Root Servers

    The resolver starts at the top of the DNS hierarchy with root servers. There are 13 root server addresses (a.root-servers.net through m.root-servers.net), though each address represents hundreds of actual servers worldwide.

    The root server doesn’t know where example.com is, but it knows who handles .com domains.

    Step 4: TLD Servers

    Next stop: the Top-Level Domain (TLD) servers. For .com, these servers are run by Verisign. The TLD server doesn’t know the IP for example.com either, but it knows which nameservers are authoritative for that domain.

    Step 5: Authoritative Nameservers

    Finally, we reach the authoritative nameservers for example.com. These servers have the actual DNS records and can give us the IP address.

    Step 6: The Response Journey

    The IP address travels back through the same path, getting cached at each step. That’s why DNS changes aren’t instant – all those caches need to expire.

    Your First DNS Query

    Enough theory. Let’s see this in action with dig, the Swiss Army knife of DNS tools.

    First, make sure you have dig installed:

    # macOS/Linux - usually pre-installed
dig -v

# Ubuntu/Debian
sudo apt-get install dnsutils

# macOS with Homebrew
brew install bind

    Now let’s do a basic query:

    dig example.com

    You’ll see output like this:

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

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            78641   IN      A       93.184.216.34

;; Query time: 28 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Nov 07 10:23:45 PST 2024
;; MSG SIZE  rcvd: 56

    Let’s break down the important parts:

    • QUESTION SECTION: Shows what we asked for (A record for example.com)
    • ANSWER SECTION: The actual answer (IP address 93.184.216.34)
    • 78641: That’s the TTL in seconds (about 22 hours). This answer will be cached for that long
    • SERVER: Which DNS server answered us (8.8.8.8 in this case)

    Following the DNS Trail

    Want to see the full journey? Use dig +trace:

    dig +trace example.com

    This shows each step of the resolution:

    ; <<>> DiG 9.10.6 <<>> +trace example.com
;; global options: +cmd
.                       2952    IN      NS      m.root-servers.net.
.                       2952    IN      NS      a.root-servers.net.
.                       2952    IN      NS      b.root-servers.net.
[... more root servers ...]

;; Received 239 bytes from 8.8.8.8#53(8.8.8.8) in 28 ms

com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
[... more .com servers ...]

;; Received 1170 bytes from 192.5.5.241#53(f.root-servers.net) in 72 ms

example.com.            172800  IN      NS      a.iana-servers.net.
example.com.            172800  IN      NS      b.iana-servers.net.

;; Received 195 bytes from 192.52.178.30#53(k.gtld-servers.net) in 124 ms

example.com.            86400   IN      A       93.184.216.34

;; Received 56 bytes from 199.43.135.53#53(a.iana-servers.net) in 20 ms

    Each section shows a hop in our journey:

    1. Root servers pointing to .com servers
    2. .com servers pointing to example.com‘s nameservers
    3. example.com‘s nameservers giving us the final IP

    Key Concepts That Matter

    TTL (Time To Live)

    TTL is how long (in seconds) a DNS answer can be cached. Lower TTL means changes propagate faster but more DNS queries. Higher TTL means better performance but slower updates.

    Common TTL values:

    • 300 (5 minutes): When you’re about to make changes
    • 3600 (1 hour): Good default for most records
    • 86400 (24 hours): For stable records that rarely change

    Authoritative vs Recursive Servers

    • Authoritative servers have the actual DNS records for a domain
    • Recursive servers find answers by asking other servers

    Your ISP runs recursive servers. Your domain registrar or DNS host runs authoritative servers.

    Why DNS Changes Aren’t Instant

    When you update a DNS record, here’s what needs to happen:

    1. Your authoritative servers get the update (instant)
    2. Cached answers need to expire (up to the old TTL)
    3. Some ISPs ignore TTL and cache longer (annoying but real)

    Pro tip: Lower your TTL a day before making changes, then raise it back after.

    Quick Wins

    Here are practical things you can do right now:

    Check if DNS is Your Problem

    # Compare your local DNS to Google's
dig @8.8.8.8 yourdomain.com
dig yourdomain.com

# Check what authoritative servers say
dig @ns1.yourdnshost.com yourdomain.com

    If these show different IPs, you’ve got a caching issue.

    See All Records for a Domain

    dig yourdomain.com ANY

    Note: Some servers restrict ANY queries now, but it’s worth trying.

    Debug Slow DNS

    # Time your DNS queries
dig yourdomain.com | grep "Query time"

# Try different DNS servers
dig @1.1.1.1 yourdomain.com    # Cloudflare
dig @8.8.8.8 yourdomain.com    # Google
dig @9.9.9.9 yourdomain.com    # Quad9

    What’s Next?

    Now that you understand the basics of DNS resolution, you’re ready to dive into specific record types. In the next post, we’ll explore A, AAAA, and CNAME records – the workhorses of DNS that you’ll use daily.

    For now, try running dig +trace on your own domain. See if you can identify each step in the resolution process. And next time DNS issues pop up at work, you’ll know exactly where to start looking.

    Remember: DNS isn’t magic, it’s just a distributed phone book. Once you know how to read it, debugging becomes much simpler.