Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

Resolving DNS Wildcard Shadowing: The adamcherrycomics Subdomain Incident

What Happened

The subdomain adamcherrycomics.dangerouscentaur.com was returning HTTP 404 responses despite the CloudFront distribution (ID: E2Q4UU71SRNTMB) being fully operational and serving content correctly. The root cause wasn't infrastructure failure—it was a subtle DNS configuration issue involving wildcard CNAME shadowing as specified in RFC 1034 § 4.3.3.

Initial Diagnosis

The troubleshooting began with the standard checklist:

  • Verified CloudFront distribution E2Q4UU71SRNTMB was active and returning HTTP 200 responses when queried directly with the Host header
  • Confirmed the origin content was accessible via direct CloudFront invocation
  • Ran DNS lookups from the local resolver showing the subdomain wasn't resolving
  • Queried Namecheap's authoritative nameservers directly to check the current DNS state

The CloudFront infrastructure was healthy. The problem was definitively DNS-related.

Root Cause: Wildcard Shadowing

Namecheap's DNS records for dangerouscentaur.com contained:

  • A wildcard CNAME record: * → cloudfront.dangerouscentaur.com (pointing to the CloudFront distribution)
  • An explicit CNAME record: www.adamcherrycomics → cloudfront.dangerouscentaur.com

The issue: that explicit www.adamcherrycomics record creates a DNS node at the label adamcherrycomics in the zone. When a resolver queries for adamcherrycomics.dangerouscentaur.com, it finds this node, but the node only contains the www subdomain—not an A record or CNAME for adamcherrycomics itself. Per RFC 1034, once a zone node exists, wildcard matching is blocked for that node and all children.

In other words: the wildcard can't match adamcherrycomics because an explicit child record (www.adamcherrycomics) already defines that zone node.

The Fix: Explicit CNAME Addition

The solution was to add an explicit CNAME record for adamcherrycomics itself, pointing to the CloudFront distribution.

Record added via Namecheap API:

adamcherrycomics CNAME cloudfront.dangerouscentaur.com

This was performed by fetching all existing DNS records for dangerouscentaur.com, building a complete set with the new record merged in, and submitting the updated record set back to Namecheap. The new record was assigned HostId 511341200.

Verification Steps

Post-deployment verification included:

  • Authoritative nameserver verification: Queried Namecheap's authoritative nameservers directly (both pdns1.namecheap.com and pdns2.namecheap.com) to confirm the new CNAME was present and propagated
  • Local resolver checks: Verified DNS resolution from the development environment's standard resolver
  • Polling for propagation: Implemented a polling loop against Namecheap's authoritative nameservers to detect when the record became available (accounting for DNS propagation latency)
  • HTTPS availability: Polled the subdomain over HTTPS until it returned a successful response
  • Content verification: Confirmed that adamcherrycomics.dangerouscentaur.com now properly routes to the CloudFront distribution and serves content

Key Decisions

Why add an explicit record instead of removing the wildcard?

The wildcard CNAME serves other subdomains under dangerouscentaur.com, so removing it wasn't an option. Adding an explicit record for adamcherrycomics was the minimal, non-breaking change that solved the shadowing problem while preserving all other subdomain routing.

Why query authoritative nameservers directly?

Authoritative nameserver queries bypass local resolver caches and intermediate DNS layers, providing ground truth about what's actually in the zone. This was essential for confirming the record was in Namecheap before assuming it was a propagation delay.

Why implement polling rather than manual verification?

DNS propagation times can vary. Polling against both authoritative nameservers and the live HTTPS endpoint provided confidence that the change was globally available, not just present in the zone file.

Infrastructure Notes

  • CDN: CloudFront distribution E2Q4UU71SRNTMB (status: fully operational)
  • Domain registrar & DNS provider: Namecheap
  • Authoritative nameservers: Namecheap's standard nameservers (pdns1.namecheap.com, pdns2.namecheap.com, etc.)
  • TTL: Default Namecheap TTL values (typically 1800 seconds for most records)

What's Next

This incident highlighted the importance of explicit DNS records when wildcard CNAMEs are in use. For future subdomain onboarding under dangerouscentaur.com, the template should include:

  • A dedicated CNAME for the primary subdomain (e.g., adamcherrycomics)
  • Optional WWW variant (e.g., www.adamcherrycomics) if needed
  • Documentation of the wildcard shadowing rule to prevent similar issues

The adamcherrycomics subdomain is now fully operational and properly routed through CloudFront.