DNS Explained for Developers: How Domain Names Work

DNS Explained for Developers: How Domain Names Work

Every time you visit a website, your browser performs a series of lookups before it sends a single byte of HTTP data. That invisible system is DNS — the Domain Name System. Understanding DNS is fundamental to deploying apps, debugging outages, and configuring custom domains correctly.

What DNS Actually Is

DNS is a globally distributed database that maps human-readable domain names to machine-readable IP addresses. Think of it as the internet's phone book: you look up example.com and get back 93.184.216.34.

Without DNS, you'd have to remember IP addresses for every service you use. DNS abstracts that away.

The DNS Resolution Chain

When you type app.example.com in a browser, here's what happens:

1. 1Browser cache — The browser checks if it has recently resolved this name.
2. 2OS cache — If not, the OS checks its local resolver cache (and /etc/hosts).
3. 3Recursive resolver — Your ISP or a public resolver (like 8.8.8.8) takes over.
4. 4Root nameservers — The resolver asks a root server which nameserver handles .com.
5. 5TLD nameservers — The .com nameserver says which nameserver handles example.com.
6. 6Authoritative nameserver — The authoritative server for example.com returns the actual record.
7. 7Answer returned — The resolver caches and returns the IP to your browser.

This whole process typically takes under 100ms.

Common DNS Record Types

Querying DNS from the Terminal

# Basic A record lookup
dig example.com

# Query a specific record type
dig example.com MX
dig example.com TXT

# Use a specific resolver
dig @8.8.8.8 example.com

# Short output
dig +short example.com

# Trace the full resolution chain
dig +trace example.com

nslookup is a simpler alternative, but dig gives you more detail for debugging.

TTL: Time to Live

Every DNS record has a TTL (in seconds) that tells resolvers how long to cache the answer. A TTL of 3600 means resolvers cache the record for 1 hour.

Before migrating a domain:

# Lower your TTL to 300 (5 minutes) 24–48 hours before the change
# This speeds up propagation when you make the switch

After migration is confirmed stable, raise it back to 3600 or higher to reduce DNS load.

The CNAME Restriction at Apex Domains

A CNAME record says "this domain is an alias for another domain." This is fine for app.example.com but not allowed at the apex (example.com) per RFC 1912 — because CNAME must be the only record at a name, and apex domains need SOA and NS records.

Some DNS providers (Cloudflare, Route 53) implement workarounds:

• Cloudflare CNAME Flattening — Resolves CNAME at the apex and returns the underlying A record.
• AWS Route 53 ALIAS records — Behave like CNAME but work at apex.

Wildcard DNS Records

Wildcard records match any subdomain that doesn't have an explicit record:

Type:  A
Name:  *
Value: 203.0.113.10

This means anything.example.com resolves to that IP. Useful for multi-tenant SaaS apps where each customer gets a subdomain.

DNS and SSL Certificates

Let's Encrypt (and other CAs) verify domain ownership before issuing certificates. There are two challenge methods:

• HTTP-01 — CA hits http://yourdomain/.well-known/acme-challenge/. Requires domain to resolve to your server.
• DNS-01 — You add a TXT record to prove control. Useful for wildcard certs.

PandaStack handles this automatically when you add a custom domain — no manual certificate management needed.

Debugging DNS Issues

# Check what your local resolver sees
dig app.example.com

# Check what a specific resolver sees (bypasses local cache)
dig @1.1.1.1 app.example.com

# Check propagation across global resolvers
# Use dnschecker.org in a browser

# Check SOA record to find authoritative nameserver
dig SOA example.com

Conclusion

DNS is one of those foundational systems that developers interact with constantly but rarely think deeply about. Understanding the resolution chain, record types, TTL behavior, and apex domain restrictions will save you hours of debugging when deploying apps. Configure custom domains on PandaStack at [dashboard.pandastack.io](https://dashboard.pandastack.io) and see [docs.pandastack.io](https://docs.pandastack.io) for platform-specific DNS guidance.