Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

Resolving DNS Shadowing on adamcherrycomics.dangerouscentaur.com: A Wildcard CNAME Pitfall

Executive Summary

A subdomain deployment for adamcherrycomics.dangerouscentaur.com went dark after hours of uptime. The root cause: an existing CNAME record for www.adamcherrycomics at the DNS provider created a DNS node that shadowed the wildcard CNAME rule, preventing proper subdomain resolution. The fix required explicit CNAME creation and understanding of RFC 1034 § 4.3.3 DNS name shadowing semantics.

What Happened

The site was serving content from a CloudFront distribution (ID: E2Q4UU71SRNTMB) accessed via adamcherrycomics.dangerouscentaur.com. A DNS lookup failure caused the subdomain to return no results, while direct CloudFront testing confirmed the distribution was healthy and returning HTTP 200.

Investigation revealed that dangerouscentaur.com is managed at Namecheap with a wildcard CNAME rule (* → cloudfront-alias.dangerouscentaur.com) intended to route all subdomains through CloudFront. However, the subdomain resolution was failing despite the wildcard being in place.

Root Cause Analysis

Digging against Namecheap's authoritative nameservers (pdns2.namecheap.com and pdns1.namecheap.com) revealed the problem:

  • A www.adamcherrycomics CNAME record existed in the DNS zone
  • This created an explicit DNS node at the label adamcherrycomics
  • According to RFC 1034 § 4.3.3, when a non-wildcard RR exists at a name, the wildcard does not apply to that name
  • The query for adamcherrycomics.dangerouscentaur.com matched the node created by www.adamcherrycomics, not the wildcard
  • Since adamcherrycomics itself had no explicit records, the query returned NXDOMAIN

The fix was straightforward: add an explicit adamcherrycomics CNAME record pointing to the same CloudFront alias as the wildcard, overriding the shadowing behavior.

Implementation

DNS Record Management

All DNS records for dangerouscentaur.com are managed through Namecheap's API. The existing record set included:


* CNAME cloudfront-alias.dangerouscentaur.com
www.adamcherrycomics CNAME [target]
mail CNAME [target]
[other records...]

The fix involved fetching the current DNS state, building a new record object with the explicit adamcherrycomics CNAME added, and merging it into the existing set:


# Query Namecheap authoritative nameserver for current records
dig @pdns1.namecheap.com dangerouscentaur.com AXFR

# Add explicit adamcherrycomics CNAME to the record set
# Merge with existing records and push via Namecheap API
# Record HostId: 511341200 (generated on creation)

The new record was created with:

  • Name: adamcherrycomics
  • Type: CNAME
  • Target: cloudfront-alias.dangerouscentaur.com
  • TTL: 1800 seconds (30 minutes)

Verification Steps

After adding the record, verification occurred at multiple stages:


# Check Namecheap authoritative nameserver
dig @pdns1.namecheap.com adamcherrycomics.dangerouscentaur.com

# Poll until resolution succeeds
dig +short adamcherrycomics.dangerouscentaur.com @8.8.8.8

# Verify HTTPS connectivity
curl -v https://adamcherrycomics.dangerouscentaur.com/
curl -H "Host: adamcherrycomics.dangerouscentaur.com" \
  https://d[cloudfront-id].cloudfront.net

# Check page content loads
curl https://adamcherrycomics.dangerouscentaur.com/ | grep -i "title"

DNS propagation required polling across multiple nameservers, with pdns2.namecheap.com taking the longest to sync. Full propagation to major public resolvers (8.8.8.8, 1.1.1.1) took approximately 30-40 seconds.

Application Changes During the Session

While resolving the DNS issue, several application updates were deployed to the site:

Lambda Function Updates

The checkout handler at /Users/cb/Documents/repos/sites/adamcherrycomics.com/lambda/checkout.py was updated multiple times to fix Stripe integration issues:

  • Added typing_extensions to dependencies (required for Python type hints in Lambda runtime)
  • Fixed ui_mode parameter for Stripe Checkout (changed from redirect to hosted_page)
  • Rebuilt checkout.zip with all dependencies included
  • Deployed to Lambda function adam-cherry-checkout via AWS CLI

Lambda invocations were tested with product IDs like hells-lounge to verify the updated checkout flow.

HTML and Asset Updates

Multiple HTML files were updated and deployed to S3:

  • index.html — Updated Stripe checkout reference and navigation links
  • shop.html — Fixed checkout patterns and product navigation
  • about-artist.html — Updated artist photo (adam-cherry.jpg)
  • contact.html — Fixed CSS dropdown positioning gap
  • shipping.html — Fixed matching dropdown styling

All updates were deployed to S3 bucket adamcherrycomics-prod with CloudFront cache invalidations:


# Invalidate CloudFront cache for updated files
aws cloudfront create-invalidation \
  --distribution-id E2Q4UU71SRNTMB \
  --paths "/index.html" "/about-artist.html" "/contact.html" "/shipping.html"

Key Decisions and Lessons

Why Explicit CNAME Over Other Solutions

Several approaches were considered:

  • Remove www.adamcherrycomics CNAME: Would break existing www subdomain references
  • Use Route 53 alias records: Danger