Resolving DNS Wildcard Shadowing: Fixing adamcherrycomics.dangerouscentaur.com CloudFront Integration
Incident Summary
The subdomain adamcherrycomics.dangerouscentaur.com was unreachable for several hours despite CloudFront distribution E2Q4UU71SRNTMB being fully operational. The root cause was a subtle DNS configuration issue: an explicit CNAME record for www.adamcherrycomics in Namecheap was creating a DNS node that shadowed the wildcard CNAME, preventing resolution of the bare subdomain. This post details the diagnostic process and the RFC 1034-compliant fix applied.
What Was Done
We identified and resolved a DNS wildcard shadowing issue by:
- Diagnosing CloudFront connectivity and confirming content availability
- Tracing DNS resolution failures to Namecheap's authoritative nameservers
- Identifying RFC 1034 § 4.3.3 wildcard shadowing as the root cause
- Adding an explicit
adamcherrycomicsCNAME record to override the shadowing behavior - Verifying propagation across Namecheap's authoritative nameserver pool
Technical Details
Initial Diagnostics
The investigation began with basic HTTP connectivity checks against the CloudFront distribution:
curl -v -w "\nHTTP Status: %{http_code}\n" \
http://adamcherrycomics.dangerouscentaur.com/ \
--max-time 10
The request timed out, suggesting either DNS resolution failure or CloudFront unavailability. We then tested CloudFront directly using the Host header to bypass DNS:
curl -v -H "Host: adamcherrycomics.dangerouscentaur.com" \
https://E2Q4UU71SRNTMB.cloudfront.net/ \
--max-time 10
This returned HTTP 200, confirming CloudFront was operational and serving content correctly. The problem was therefore DNS-related.
DNS Resolution Analysis
We queried Namecheap's authoritative nameservers directly to inspect the live DNS state:
dig adamcherrycomics.dangerouscentaur.com @ns1.namecheap.com +short
dig adamcherrycomics.dangerouscentaur.com @ns2.namecheap.com +short
dig adamcherrycomics.dangerouscentaur.com @ns4.namecheap.com +short
All queries returned no results, indicating the subdomain was not resolving. We then fetched the complete DNS record set for dangerouscentaur.com from Namecheap's API to understand the configuration:
Existing DNS records for dangerouscentaur.com:
- * (wildcard) → CNAME to E2Q4UU71SRNTMB.cloudfront.net
- www.adamcherrycomics → CNAME to E2Q4UU71SRNTMB.cloudfront.net
Root Cause: RFC 1034 Wildcard Shadowing
The presence of the www.adamcherrycomics CNAME record created an explicit DNS node for the adamcherrycomics label. According to RFC 1034 Section 4.3.3, wildcard records only match when there is no explicit node at that level or any level in between. In this case:
- Query:
adamcherrycomics.dangerouscentaur.com - Zone apex has wildcard:
*.dangerouscentaur.com - But
adamcherrycomics.dangerouscentaur.comhas a child node (www.adamcherrycomics.dangerouscentaur.com) - This creates an implicit non-terminal node at
adamcherrycomics, shadowing the wildcard - Result: NXDOMAIN (name does not exist) instead of matching the wildcard
Infrastructure Changes
DNS Record Addition
To fix this, we added an explicit CNAME record for adamcherrycomics itself, bypassing the wildcard shadowing. Using Namecheap's DNS API, we performed a record set merge operation:
New record added:
Host: adamcherrycomics
Type: CNAME
Value: E2Q4UU71SRNTMB.cloudfront.net
TTL: 1800 (30 minutes)
HostId: 511341200
The complete record set was reconstructed with all existing records plus the new adamcherrycomics entry and submitted back to Namecheap via setHosts operation.
Verification Steps
After record submission, we performed progressive verification against Namecheap's authoritative nameservers:
dig adamcherrycomics.dangerouscentaur.com @ns1.namecheap.com
dig adamcherrycomics.dangerouscentaur.com @ns2.namecheap.com
dig adamcherrycomics.dangerouscentaur.com @ns4.namecheap.com
Initial queries returned no results; we waited 30 seconds to allow zone file synchronization across Namecheap's authoritative nameserver pool, then polled ns2.namecheap.com until the record appeared. The CNAME was confirmed present within 60 seconds.
Finally, we verified HTTPS connectivity from the application layer:
curl -v https://adamcherrycomics.dangerouscentaur.com/ \
--max-time 10
This returned HTTP 200 with CloudFront's standard response headers, confirming end-to-end resolution and content delivery.
Key Architectural Decisions
- CloudFront as Primary Origin: The site is served entirely from CloudFront distribution E2Q4UU71SRNTMB, providing global edge caching and DDoS protection.
- Wildcard CNAME Strategy: The original
*.dangerouscentaur.comwildcard CNAME reduced administrative overhead for new subdomains, but required careful handling of non-leaf DNS nodes. - Explicit Record Override: Rather than modifying the wildcard or reorganizing the domain structure, adding an explicit CNAME for the shadowed label was the minimal, RFC-compliant solution.
- TTL Consideration: The 1800-second (30-minute) TTL balances propagation speed for future changes against resolver cache efficiency.
What's Next
The adamcherrycomics subdomain is now fully operational. Future considerations include:
- Documenting wildcard shadowing behavior in internal DNS management runbooks
- Automating DNS record validation in pre