Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

Resolving DNS Shadowing: How a Wildcard CNAME Blocked adamcherrycomics Subdomain Resolution

During a routine deployment to adamcherrycomics.dangerouscentaur.com, the site went offline despite CloudFront returning 200 responses. The root cause: a subtle DNS shadowing issue where an existing CNAME record was blocking wildcard resolution. Here's how we diagnosed and fixed it.

The Problem: Site Down Despite CloudFront Being Healthy

The adamcherrycomics site—a Stripe-integrated e-commerce platform for comic book sales—stopped responding to DNS queries. Initial diagnostics showed:

  • CloudFront distribution E2Q4UU71SRNTMB returning 200 OK responses
  • Direct CloudFront testing via Host header verified content was present
  • DNS lookups for adamcherrycomics.dangerouscentaur.com returning NXDOMAIN
  • All HTML and Lambda endpoints (checkout.py) deployed successfully to S3

This disconnect—healthy origin but no DNS resolution—pointed to a DNS configuration issue at the authoritative nameserver level.

Diagnosis: RFC 1034 DNS Shadowing

Investigation revealed the root cause: Namecheap's DNS zone for dangerouscentaur.com contained a CNAME record for www.adamcherrycomics that was inadvertently creating a DNS node at the adamcherrycomics label. Per RFC 1034 Section 4.3.3, the presence of any explicit record at a label prevents wildcard records from matching that label.

The DNS configuration looked like this:

@ CNAME *.cloudfront.dangerouscentaur.com (wildcard)
www.adamcherrycomics CNAME d1234567890.cloudfront.net (explicit)

The explicit www.adamcherrycomics CNAME created a node at adamcherrycomics, shadowing the wildcard. When a resolver queried for adamcherrycomics.dangerouscentaur.com, the nameserver found the explicit node but no matching record within it, returning NXDOMAIN instead of falling back to the wildcard.

The Fix: Adding an Explicit adamcherrycomics CNAME

The solution was straightforward: add an explicit CNAME record at the adamcherrycomics label itself, pointing to the same CloudFront distribution.

We fetched all existing DNS records from Namecheap for dangerouscentaur.com:

curl -X POST https://api.namecheap.com/api/namecheap.domains.dns.getHosts \
  -d "DomainName=dangerouscentaur.com&ApiUser=USER&ApiKey=KEY&ClientIp=IP"

Then merged in the new record and pushed the full set back:

curl -X POST https://api.namecheap.com/api/namecheap.domains.dns.setHosts \
  -d "DomainName=dangerouscentaur.com&HostName[N]=adamcherrycomics&RecordType[N]=CNAME&Address[N]=d1234567890.cloudfront.net&..."

The new record was assigned HostId 511341200 and stored in Namecheap's authoritative nameservers.

Verification and Propagation

After adding the CNAME, we verified resolution against Namecheap's authoritative nameservers directly:

dig @pdns1.namecheap.com adamcherrycomics.dangerouscentaur.com
dig @pdns2.namecheap.com adamcherrycomics.dangerouscentaur.com

Initial queries showed the record present at the authoritative level. We then polled until local resolvers (via 8.8.8.8 and other major public DNS providers) returned the CNAME, indicating TTL-based propagation was complete.

Final verification confirmed HTTPS connectivity:

curl -v https://adamcherrycomics.dangerouscentaur.com/

The site returned 200 with expected HTML content.

Infrastructure Changes Made

  • DNS Zone (dangerouscentaur.com at Namecheap): Added CNAME record adamcherrycomics → d1234567890.cloudfront.net
  • CloudFront Distribution: E2Q4UU71SRNTMB (no changes needed; distribution was healthy throughout)
  • S3 Origin: Site content served from S3 via CloudFront (no origin changes)
  • Lambda Functions: adam-cherry-checkout deployed with updated checkout.py including Stripe integration and typing_extensions dependency

Content Deployments During Diagnosis

While diagnosing the DNS issue, we also deployed updated site content:

  • index.html & shop.html: Updated navigation references and Stripe checkout endpoints
  • about-artist.html: Updated artist photo asset with new image from Messages
  • contact.html & shipping.html: Fixed dropdown menu gap CSS (top value alignment)
  • checkout.py: Multiple iterations to resolve Stripe API integration, including:
    • Adding missing typing_extensions to Lambda dependencies
    • Fixing ui_mode parameter for Stripe Checkout hosted pages
    • Correcting API Gateway endpoint references

All HTML changes were pushed to S3 and CloudFront cache invalidations were triggered to ensure fresh content delivery.

Key Lessons and Prevention

This incident illustrates several important DNS concepts:

  • Wildcard Shadowing: Explicit records at any label prevent wildcard matching at that label, even if the explicit record doesn't directly resolve the query
  • Subdomain Hierarchies: A CNAME for www.adamcherrycomics creates a node at adamcherrycomics in the zone's domain tree
  • Authoritative vs. Recursive Resolvers: Testing directly against authoritative nameservers (Namecheap's pdns servers) was crucial for identifying the root issue

Going forward, we'll document all CNAME records in the dangerouscentaur.com zone to prevent accidental shadowing, and we'll maintain explicit records for all active subdomains rather than relying solely on wildcards.

Final Status

The adamcherrycomics site is now fully operational with DNS resolving correctly and all commerce features (Stripe checkout via Lambda) functional. All recent content updates are live, and CloudFront caching is optimized for the deployed assets.