DNS Resolution
debt(d7/e5/b5/t5)
Closest to 'only careful code review or runtime testing' (d7). DNS resolution issues are invisible at compile time. The listed tools (curl, strace, blackfire) are runtime diagnostic tools that require manual investigation. Slow DNS or misconfigured records typically surface only when users experience latency or outages in production. There's no static analysis that catches high TTLs before migration or missing CNAME cleanup.
Closest to 'touches multiple files / significant refactor in one component' (e5). The quick_fix mentions caching DNS with local resolver (infrastructure change) and reusing connections with CURLOPT_TCP_KEEPALIVE (code changes across HTTP clients). Fixing DNS issues often requires coordinating infrastructure changes (DNS records, TTLs, resolvers) with application code changes (connection reuse patterns). Not a one-line fix, but not architectural rework either.
Closest to 'persistent productivity tax' (b5). DNS affects every external request in web and CLI contexts (per applies_to). The misconception notes DNS is 'the first step in every request' — it's a constant concern whenever dealing with external services, migrations, or failovers. It's not architecture-defining, but every team must repeatedly revisit DNS configuration for migrations, provider changes, and incident response.
Closest to 'notable trap' (t5). The misconception explicitly states developers believe 'DNS changes propagate instantly' when propagation is bounded by TTL which can be hours or days. This is a documented gotcha that most experienced developers eventually learn, often the hard way during a migration. It contradicts the intuition that changes take effect immediately like other configuration updates.
Also Known As
TL;DR
Explanation
DNS resolution begins at a recursive resolver (usually provided by the ISP or a public resolver like 8.8.8.8). If not cached, the resolver queries root nameservers, then TLD nameservers, then the authoritative nameserver for the domain. Results are cached for the duration specified by the TTL. High TTLs reduce DNS latency but slow propagation of changes; low TTLs enable fast failover but increase resolver load.
Diagram
sequenceDiagram
participant C as Client
participant R as Recursive Resolver
participant ROOT as Root NS
participant TLD as .com NS
participant AUTH as example.com NS
C->>R: Where is example.com?
R->>ROOT: Where is .com?
ROOT-->>R: Ask TLD NS
R->>TLD: Where is example.com?
TLD-->>R: Ask AUTH NS
R->>AUTH: What is example.com?
AUTH-->>R: 93.184.216.34 (TTL 3600)
R-->>C: 93.184.216.34 (cached)
Common Misconception
Why It Matters
Common Mistakes
- High TTLs before a planned migration — reduce TTL days before to enable fast propagation.
- Not removing CNAME records when deprovisioning cloud resources — enables subdomain takeover.
- Using A records instead of CNAME for load balancers that change IP — the IP becomes stale.
- Forgetting that DNS is the first step in every request — slow DNS adds latency to every connection.
Code Examples
# DNS record not removed after deprovisioning:
; staging.example.com CNAME myapp.herokuapp.com
; Heroku app deleted — CNAME still exists
; Attacker registers same Heroku hostname → subdomain takeover# DNS best practices:
; Lower TTL before planned changes:
example.com. 300 IN A 203.0.113.1 ; 5min TTL for pre-migration
; Remove records when deprovisioning:
; Run: dig staging.example.com — verify no dangling CNAMEs
; Use ALIAS/CNAME for load balancers that change IP:
www IN CNAME myapp.us-east-1.elb.amazonaws.com.