Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

Debugging DNS Wildcard Shadowing: How a Single CNAME Record Broke adamcherrycomics Subdomain Resolution

The Problem

The adamcherrycomics subdomain on dangerouscentaur.com went down for several hours. The site content was present and healthy at the CloudFront distribution (E2Q4UU71SRNTMB), returning 200 responses with correct content. However, DNS resolution was failing entirely—the subdomain simply wouldn't resolve to anything.

Initial diagnostics showed:

  • CloudFront distribution E2Q4UU71SRNTMB was operational and serving content correctly
  • Direct HTTPS requests to the CloudFront origin succeeded
  • DNS queries for adamcherrycomics.dangerouscentaur.com returned NXDOMAIN (non-existent domain)
  • The wildcard CNAME *.dangerouscentaur.com was present in Namecheap DNS

The root cause: DNS wildcard shadowing caused by an existing CNAME record at a parent node.

Technical Details: Understanding the DNS Issue

The dangerouscentaur.com domain had a DNS configuration that included:

  • A wildcard CNAME: *.dangerouscentaur.com → cloudfront.dangerouscentaur.com
  • A specific CNAME for www: www.adamcherrycomics.dangerouscentaur.com → cloudfront.dangerouscentaur.com

The issue stems from RFC 1034 § 4.3.3, which defines how DNS handles wildcard matching. When a query arrives for adamcherrycomics.dangerouscentaur.com:

  1. The DNS resolver checks for an exact match at adamcherrycomics.dangerouscentaur.com
  2. If no exact match exists, it looks for a CNAME at the parent zone that created a DNS node (apex)
  3. The www.adamcherrycomics CNAME record creates a DNS node at adamcherrycomics.dangerouscentaur.com that explicitly blocks wildcard matching
  4. With no exact CNAME at adamcherrycomics, and wildcard matching blocked, the query fails with NXDOMAIN

This is called wildcard shadowing—the presence of a DNS node at a parent level prevents the wildcard from matching descendant queries.

Infrastructure Changes

The fix required adding an explicit CNAME record at the adamcherrycomics subdomain level in Namecheap:

  • Hostname: adamcherrycomics
  • Record Type: CNAME
  • Target: CloudFront distribution domain (E2Q4UU71SRNTMB)
  • Namecheap HostId: 511341200

This was added alongside the existing wildcard and www records, bringing the total DNS configuration to:

  • *.dangerouscentaur.com (wildcard, handles all unmapped subdomains)
  • www.adamcherrycomics.dangerouscentaur.com (specific www subdomain)
  • adamcherrycomics.dangerouscentaur.com (new explicit record to break the shadowing)

Deployment Process and Verification

The deployment followed a methodical verification pattern:

1. DNS Record Addition

Updated Namecheap's authoritative nameservers with the new record via their API, merging the new CNAME with all existing records in a single setHosts call.

2. Authoritative Nameserver Verification

# Query Namecheap's authoritative nameservers directly
dig @dns1.registrar.dangerouscentaur.com adamcherrycomics.dangerouscentaur.com CNAME

Confirmed the record was present at the authoritative source.

3. Recursive Resolver Propagation

# Check local resolver (which queries public DNS recursively)
dig adamcherrycomics.dangerouscentaur.com CNAME

Allowed 30+ seconds for resolver cache expiration and re-queried until propagation completed.

4. HTTPS Endpoint Verification

# Verify SSL/TLS endpoint is responsive
curl -v https://adamcherrycomics.dangerouscentaur.com/ --connect-timeout 10

5. Cross-resolver Validation

Confirmed resolution across multiple public DNS resolvers (8.8.8.8, 1.1.1.1) and Namecheap's authoritative nameservers.

Site Content Redeployment

While resolving DNS, the development session also included content updates:

  • Lambda Functions: Updated /Users/cb/Documents/repos/sites/adamcherrycomics.com/lambda/checkout.py with dependency fixes (typing_extensions) and hosted_page configuration for Stripe integration
  • S3 Deployment: Pushed updated index.html and about-artist.html to the S3 bucket serving adamcherrycomics.com
  • CloudFront Invalidation: Invalidated CloudFront cache (E2Q4UU71SRNTMB) to ensure fresh content delivery
  • Photo Update: Replaced adam-cherry.jpg profile image with updated photo in S3 and CloudFront

Key Decisions

Why Add an Explicit CNAME Instead of Removing www?

Removing the www subdomain would have fixed the shadowing issue but broken www.adamcherrycomics.dangerouscentaur.com. The explicit CNAME maintains both the www subdomain and the bare adamcherrycomics subdomain, supporting all expected access patterns.

Why Query Authoritative Nameservers Directly?

Recursive resolvers cache negative responses (NXDOMAIN) for several minutes. Checking Namecheap's authoritative nameservers (dns1.dangerouscentaur.com, dns2.dangerouscentaur.com) confirmed changes were applied at the source immediately, allowing us to validate the fix before waiting for recursive resolver cache expiration.

Why Include Stripe Checkout Lambda Updates?

The checkout flow was broken due to missing dependencies (typing_extensions in the Stripe library) and incorrect Stripe hosted page configuration. Rebuilding the deployment zip with proper dependencies and redeploy ensured the e-commerce functionality worked end-to-end.

Testing and Validation

Post-