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 adamcherrycomics CNAME 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.com has 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.com wildcard 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