Table of Contents
By Khimananda Oli | Last reviewed: August 2026
When a user reports that "the site is down" but your load balancer metrics look healthy, the problem often lies in name resolution rather than application code. Understanding how DNS works is fundamental for any engineer managing cloud infrastructure, as it bridges the gap between human-readable domains and machine-routable IP addresses. This guide moves beyond textbook definitions to explain the actual resolution flow, caching behaviors, and debugging techniques you need when configuring services like those in our Ubuntu DNS configuration guide or troubleshooting connectivity in Kubernetes clusters.
How does the DNS resolution process actually work?
The phrase "how DNS works" usually refers to the recursive lookup chain. When you type a URL into a browser, your local stub resolver checks its cache. If the answer isn't there, it forwards the request to a recursive resolver—typically provided by your ISP, Cloudflare (1.1.1.1), or Google (8.8.8.8). This recursive server performs the heavy lifting on behalf of the client, traversing the distributed database hierarchy.
The recursive resolver starts at the rightmost label. For api.khimananda.com, it first queries a Root Nameserver. The Root doesn't know the IP; it responds with a referral to the .com Top-Level Domain (TLD) servers. The resolver then queries the TLD server, which responds with a referral to the authoritative nameservers for khimananda.com. Finally, the resolver queries the authoritative server, which returns the definitive A or AAAA record. Crucially, the recursive resolver caches every response based on the Time-To-Live (TTL) value, so subsequent requests for the same domain skip the traversal entirely.
Why recursion matters for latency
In practice, most production outages related to DNS stem from misunderstanding this delegation chain. If your authoritative nameserver is slow or unreachable, the recursive resolver will eventually timeout, but users experience this as intermittent failures long before the final timeout. For teams deploying on AWS or Azure, understanding this flow is critical when configuring Route53 or Azure DNS zones. As detailed in our Amazon EKS practical guide, CoreDNS within Kubernetes adds another layer of internal resolution that must align with external VPC DNS settings to avoid split-horizon confusion.
What are the essential DNS record types for production?
While there are dozens of DNS record types defined in RFCs, only a handful matter for daily operations. Choosing the wrong type is a common source of misconfiguration, particularly when setting up CDNs, email authentication, or multi-region failover.
| Record Type | Purpose | Common Use Case | Critical Note |
|---|---|---|---|
| A / AAAA | Maps hostname to IPv4 / IPv6 | Web servers, API endpoints | Use multiple A records for simple round-robin load balancing |
| CNAME | Aliases one name to another | CDN origins, S3 static sites | Never use at zone apex (root); causes NXDOMAIN errors |
| MX | Mail exchange priority | Email routing (Workspace, O365) | Lower number = higher priority; always have backup MX |
| TXT | Arbitrary text metadata | SPF, DKIM, DMARC, domain verification | Split long strings into 255-char chunks to avoid truncation |
| NS | Delegates subdomain authority | Subdomain management, DNS hosting | Mismatched NS records cause silent resolution failures |
| SRV | Service location + port | SIP, LDAP, Minecraft, K8s discovery | Includes weight/priority for sophisticated load distribution |
A frequent mistake I see in audits is using CNAME records at the zone apex (e.g., khimananda.com instead of www.khimananda.com). Standard DNS RFCs forbid this because it conflicts with SOA and NS records at the root. Modern providers offer ALIAS or ANAME pseudo-records to solve this, but if you're running BIND or standard cloud DNS, you must use A records at the apex. For deeper Linux-level configuration, refer to the BIND DNS server setup guide.
How do TTL values impact propagation and caching?
Time-To-Live (TTL) is the single most misunderstood parameter in DNS operations. It is not a "propagation time" in the sense of a global broadcast; it is a per-cacher expiration timer. When you change a record, recursive resolvers that have cached the old value will continue serving it until their specific TTL expires. This means different users around the world may see different IPs simultaneously during a migration.
- Pre-migration lowering: At least 24 hours before changing critical A/CNAME records, lower the TTL to 60 seconds. This ensures that when you make the actual switch, stale caches expire quickly.
- Steady-state production: Use 3600 (1 hour) to 86400 (24 hours) for stable records. Lower TTLs increase query volume to your authoritative servers and add latency for end users who miss the cache.
- Negative caching: Remember that NXDOMAIN responses are also cached (per the SOA MINIMUM field). If you accidentally delete a record, users may fail to resolve it even after you restore it, until the negative cache expires.
- Provider overrides: Some enterprise firewalls and ISPs ignore low TTLs and enforce minimums (often 300s). Always test with
dig +traceto verify actual behavior versus theoretical specs.
In Nepal, where ISP infrastructure can sometimes involve multiple layers of NAT and transparent proxies, I've observed aggressive caching that ignores TTLs entirely. When deploying services for local audiences, always validate resolution from multiple networks (NTC, Ncell, WorldLink) rather than assuming global DNS behavior applies uniformly. This is especially relevant when following our Nepal hosting latency guide.
How do you debug DNS issues with dig and nslookup?
Browser dev tools won't tell you if DNS is broken. You need command-line utilities that expose the full protocol exchange. dig (Domain Information Groper) is the industry standard; nslookup is acceptable for quick checks but lacks the granularity needed for production debugging.
<!-- Check current resolution and TTL -->
dig +noall +answer api.khimananda.com
<!-- Trace the full delegation path from root -->
dig +trace api.khimananda.com
<!-- Query specific record types -->
dig MX khimananda.com
dig TXT _dmarc.khimananda.com
<!-- Bypass local cache and query authoritative NS directly -->
dig @ns1.khimananda.com api.khimananda.com
<!-- Check reverse DNS (PTR) for mail/IP reputation -->
dig -x 203.0.113.45The +trace flag is invaluable because it forces your local resolver to perform iterative queries starting from the root, bypassing all intermediate caches. If +trace succeeds but normal resolution fails, the issue is likely a poisoned cache or a misconfigured recursive resolver. If +trace itself fails at a specific delegation point, you've found the exact nameserver causing the outage.
Validating DNSSEC and EDNS
DNSSEC adds cryptographic signatures to prevent spoofing, but misconfigurations cause total resolution failure (SERVFAIL). Always validate with dig +dnssec +multiline. In 2026, EDNS Client Subnet (ECS) is widely used by CDNs and public resolvers to optimize geo-routing. If your users are being routed to the wrong region, check whether your authoritative provider supports ECS and whether your recursive resolver is forwarding subnet information correctly.
Secure and Optimize Your DNS Infrastructure
Mastering how DNS works requires treating it as a distributed system with its own failure modes, not just a static phonebook. Start by auditing your current TTLs and record types against the patterns described here. Implement DNSSEC if you haven't already, and integrate DNS health checks into your monitoring stack alongside the metrics covered in our four golden signals guide. When debugging, always use dig +trace before blaming the application. If you need help designing resilient DNS architecture for multi-cloud or compliance-sensitive environments, reach out to discuss your infrastructure.
