DNS Deep Dive
Volume 2 — Networking Foundations
Everyone knows "DNS turns names into IP addresses." Almost every real DNS problem lives in the details past that sentence — which record type, which resolver, what TTL, and how long a change actually takes to take effect. This chapter covers those details.
1. The Resolution Hierarchy
DNS is a distributed, hierarchical system — no single server knows every domain. Resolving api.roundtrips.app walks down a hierarchy:
- Recursive resolver — the server you (or your OS) actually ask; it does the legwork of walking the hierarchy on your behalf and caches the answer.
- Authoritative server — the server that actually holds the real records for a domain and gives the final answer. For
roundtrips.app, that's wherever the domain's nameservers are configured (Cloudflare, in the Traxs setup).
Every device has a configured recursive resolver — often your router, your ISP, or a public one like 1.1.1.1 (Cloudflare) or 8.8.8.8 (Google) if manually configured.
2. Record Types
| Record | Purpose | Example |
|---|---|---|
A | Hostname → IPv4 address | api.roundtrips.app → 76.76.21.21 |
AAAA | Hostname → IPv6 address | api.roundtrips.app → 2606:4700::... |
CNAME | Hostname → another hostname (alias) | www.roundtrips.app → roundtrips.app |
MX | Which mail servers handle email for this domain | roundtrips.app → mx.sendgrid.net |
TXT | Arbitrary text — commonly used for domain verification and email authentication | SPF/DKIM/DMARC records |
NS | Which nameservers are authoritative for this domain | roundtrips.app → ns1.cloudflare.com |
SOA | Start of Authority — administrative metadata about the zone (primary nameserver, TTLs, refresh intervals) | one per zone |
SRV | Service location — host and port for a specific service | used by some enterprise/VoIP services |
A common trap: a CNAME cannot coexist with any other record type on the same name, and a bare apex domain (roundtrips.app with no subdomain) technically can't use a CNAME at all per the DNS spec — many providers work around this with a proprietary "flattened CNAME" or ALIAS record. If you've ever tried to point a root domain at something like a CDN and gotten a confusing error, this is why.
3. TTL (Time To Live)
Every DNS record has a TTL, in seconds, telling resolvers how long they're allowed to cache the answer before asking again.
api.roundtrips.app. 300 IN A 76.76.21.21
^^^
TTL: 300 seconds = 5 minutes
This is the single biggest source of "I changed the DNS record but nothing happened" confusion. A record with a 24-hour TTL that you just changed can keep resolving to the old value, for anyone whose resolver already cached it, for up to 24 hours — regardless of what the authoritative server now says. Lowering the TTL to something short (like 300 seconds) a day before a planned change, then changing the record itself once the low TTL has propagated, is the standard way to make a DNS cutover fast and predictable.
4. Split-Brain (Split-Horizon) DNS
Split-brain DNS is when the same hostname resolves to different answers depending on who's asking — typically, an internal answer for clients inside a private network and a different (or no) answer for clients on the public internet.
Azure Private DNS Zones are the mechanism for this: a zone linked to a VNet resolves certain names only for resources inside that VNet, while the public internet either gets a different answer or no answer at all. This is the right approach for internal-only resources (like a database server that should never be directly reachable from outside Azure) that still need a friendly hostname rather than a raw IP.
5. Email Authentication Records (SPF, DKIM, DMARC)
These are TXT records that let receiving mail servers verify an email claiming to be from your domain is legitimate — directly relevant since Traxs sends transactional email through SendGrid.
| Record | Purpose |
|---|---|
| SPF | Lists which servers are allowed to send mail as your domain. v=spf1 include:sendgrid.net ~all |
| DKIM | A cryptographic signature added to outgoing mail, verified against a public key published in DNS, proving the message wasn't altered in transit |
| DMARC | A policy telling receiving servers what to do if SPF/DKIM fail (quarantine, reject, or do nothing), plus where to send reports |
Getting these wrong is a common, quiet failure mode: SPF/DKIM/DMARC misconfiguration doesn't break your app, it just means an increasing share of your transactional emails (password resets, invoices, notifications) silently land in spam or get rejected outright. If notification emails go missing, this is one of the first things worth checking — not the SendGrid API integration.
6. Azure DNS and Private DNS Zones
| Concept | What it does |
|---|---|
| Azure DNS (public zone) | Hosts standard public DNS records for a domain, same as any registrar/DNS provider |
| Azure Private DNS Zone | Resolves names only for resources linked to it via a VNet — the mechanism behind split-brain DNS in Azure |
| Auto-registration | A Private DNS Zone can automatically create/update records as VMs join/leave a linked VNet |
Traxs currently uses Cloudflare for public DNS across roundtrips.app and related domains — Azure DNS becomes relevant specifically for private, VNet-internal name resolution (e.g., a database or internal service that shouldn't have a public DNS entry at all).
7. Propagation: What's Actually Happening
"DNS propagation" isn't really the record traveling anywhere — the authoritative server's answer is correct the instant you save it. What's "propagating" is the expiration of cached copies held by every resolver that queried the old value, worldwide, each on its own TTL-driven schedule. This is why:
- A fresh domain, or a hostname nobody has queried recently, can appear to update immediately — there was nothing cached to expire.
- A busy, long-cached hostname with a high TTL can take up to that TTL's full duration to be consistent everywhere.
- Your own machine can show the new value while a colleague's still shows the old one — you likely queried after their cache had already stored the old answer, or your OS/browser DNS cache differs from theirs.
8. Practical Developer Workflows
Check what a domain currently resolves to, and via which record type:
dig roundtrips.app A
dig roundtrips.app CNAME
dig roundtrips.app MX
dig roundtrips.app TXT
Check which nameservers are authoritative for a domain:
dig roundtrips.app NS
Query a specific DNS server directly (bypassing your local resolver's cache — useful to confirm what the authoritative source actually says, independent of caching):
dig @1.1.1.1 roundtrips.app A
Clear your local DNS cache when testing a recent change:
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder # macOS
sudo systemd-resolve --flush-caches # Linux (systemd-resolved)
ipconfig /flushdns # Windows
Remember this only clears your machine's cache — it does nothing about every other resolver on the internet that already cached the old answer.
9. Troubleshooting Playbook
| Symptom | Likely cause | What to check |
|---|---|---|
| Changed a record, still seeing the old value | TTL hasn't expired yet, locally or elsewhere | dig @1.1.1.1 domain to check the authoritative answer directly; flush local cache; wait out the old TTL |
| Works for you, broken for a colleague/user | Different resolver caches, different cache ages | Confirm both are querying the same record type; compare dig output from each side if possible |
NXDOMAIN | Record doesn't exist, typo in hostname, or wrong zone | dig domain NS to confirm you're even asking the right authoritative servers |
| CNAME setup fails at the apex domain | CNAMEs aren't valid at a zone apex per spec | Use the provider's flattened-CNAME/ALIAS/ANAME equivalent, or an A record with a static IP if the target supports it |
| New subdomain doesn't resolve internally but does externally (or vice versa) | Split-brain DNS — Private DNS Zone and public zone disagree, or one is missing the record | Confirm both zones have the intended record; confirm the querying resource is actually linked to the Private DNS Zone |
| SendGrid emails landing in spam or bouncing | SPF/DKIM/DMARC misconfigured or missing | dig domain TXT and compare against SendGrid's required records exactly |
| MX record misconfigured | Wrong priority, wrong target, or missing entirely | dig domain MX; confirm it matches the mail provider's documented values |
| Site loads over IP directly but not by hostname | DNS issue, not a connectivity issue | Confirms the problem is in this chapter, not TCP/IP fundamentals — proceed with dig/nslookup |
10. Quick Reference
| Category | Command / Concept | Purpose |
|---|---|---|
| Lookup | dig domain A | Get the IPv4 address |
| Lookup | dig domain MX | Get mail server records |
| Lookup | dig domain NS | Get authoritative nameservers |
| Lookup | dig @1.1.1.1 domain | Query a specific resolver directly, bypassing local cache |
| Cache | sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder | Flush DNS cache (macOS) |
| Records | CNAME | Alias one hostname to another — not valid at the zone apex |
| Records | TXT | Arbitrary text — SPF/DKIM/DMARC, domain verification |
| Concept | TTL | How long resolvers may cache an answer before re-querying |
| Concept | Split-brain DNS | Same name, different answer depending on internal vs. external query |
| Azure | Private DNS Zone | Resolves names only for resources linked via VNet |
Part of the Traxs Engineering Handbook — Volume 2: Networking Foundations. Companion chapters in this volume: TCP/IP Fundamentals, SSL/TLS Explained, VPN Fundamentals, Network Troubleshooting, Load Balancers & Reverse Proxies.