Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

Diagnosing and Resolving DNS Wildcard Shadowing on the adamcherrycomics Subdomain

What Was Done

The adamcherrycomics.dangerouscentaur.com subdomain was unreachable for several hours despite the underlying CloudFront distribution remaining healthy and serving content correctly. Root cause analysis revealed a DNS misconfiguration at the Namecheap authoritative nameservers: a pre-existing CNAME record for www.adamcherrycomics was creating an explicit DNS node that shadowed the wildcard CNAME, preventing adamcherrycomics itself from resolving. The fix involved adding an explicit CNAME record for the adamcherrycomics subdomain while preserving all existing records.

Technical Details: DNS Shadowing and RFC 1034

The issue stems from DNS behavior defined in RFC 1034 § 4.3.3. When a DNS zone contains both:

  • A wildcard CNAME: * CNAME d-c-cdn.cloudfront.net (at dangerouscentaur.com)
  • An explicit CNAME for a subdomain: www.adamcherrycomics CNAME d-c-cdn.cloudfront.net

The explicit record creates a DNS node at adamcherrycomics.dangerouscentaur.com. Per RFC 1034, when a non-wildcard node exists in a zone, wildcard matching does not occur at that level. This means queries for adamcherrycomics.dangerouscentaur.com fail with NXDOMAIN (non-existent domain) because:

  1. The authoritative nameserver finds an explicit node for adamcherrycomics (created by the www.adamcherrycomics record)
  2. That node has no A or AAAA record — only the wildcard would have matched
  3. Resolution fails

The immediate symptom: CloudFront distribution E2Q4UU71SRNTMB responded with HTTP 200 when accessed directly via its CloudFront domain, but the subdomain was unreachable.

Diagnostic Process

The investigation progressed through multiple layers:

  • HTTP layer: curl -v http://adamcherrycomics.dangerouscentaur.com/ — connection timeout
  • DNS layer: Local resolver queries showed no response; Namecheap authoritative nameservers confirmed the issue
  • Authoritative verification: Queries against Namecheap's authoritative nameservers (pdns2.namecheap.com, etc.) revealed the wildcard was present but not matching
  • Root cause: Manual inspection of Namecheap DNS records discovered the www.adamcherrycomics CNAME creating the shadowing node

Command used to query authoritative nameservers directly:

dig @pdns2.namecheap.com adamcherrycomics.dangerouscentaur.com +short

Infrastructure Changes

Namecheap DNS Record Management:

The fix required adding a new CNAME record to the dangerouscentaur.com zone via Namecheap's API:

  • Record type: CNAME
  • Hostname: adamcherrycomics
  • Target: d-c-cdn.cloudfront.net (the CloudFront domain alias)
  • TTL: Default Namecheap TTL (300 seconds)
  • HostId: 511341200 (assigned by Namecheap after creation)

The operation used Namecheap's setHosts API method, which requires fetching all existing records, adding the new one, and submitting the complete set back. This approach prevents accidental deletion of other zone records.

CloudFront Distribution:

No changes were required to CloudFront distribution E2Q4UU71SRNTMB. The distribution was serving content correctly; the problem was purely DNS resolution at the edge.

Site Content Deployment

While investigating, several content updates were deployed to the site:

  • /Users/cb/Documents/repos/sites/adamcherrycomics.com/lambda/checkout.py — Updated Stripe checkout Lambda function to include missing dependencies (typing_extensions) and fix hosted payment page initialization
  • index.html & shop.html — Updated navigation references and product configuration
  • about-artist.html — Deployed new artist photo (adam-cherry.jpg) replacing the previous version
  • contact.html & shipping.html — Fixed CSS dropdown positioning (corrected top value to eliminate rendering gaps)

All static assets were deployed to the S3 bucket backing the CloudFront distribution and cache invalidations were issued for affected files.

Verification and Propagation

After adding the explicit CNAME record, verification involved polling multiple nameservers:

dig @pdns2.namecheap.com adamcherrycomics.dangerouscentaur.com +short
dig @pdns3.namecheap.com adamcherrycomics.dangerouscentaur.com +short

Once the authoritative nameservers returned the correct CNAME target, local resolver cache was checked via:

dig adamcherrycomics.dangerouscentaur.com +short

DNS propagation typically completes within seconds to minutes given the 300-second TTL, but validation against multiple public resolvers (Google, Cloudflare, etc.) was performed to ensure global consistency.

Key Decisions

  • Explicit CNAME vs. wildcard reliance: Rather than modifying the wildcard configuration (which would affect other subdomains), adding an explicit record for adamcherrycomics was chosen to maintain zone stability and provide clarity in DNS records.
  • CloudFront URL aliasing: Using the d-c-cdn.cloudfront.net alias ensures that CloudFront distribution changes don't require DNS updates; the alias remains constant.
  • Lambda function containerization: Checkout functionality was isolated in a Lambda function with explicit dependency management to support future scaling and testing without impacting the static site.
  • Cache invalidation strategy: CloudFront cache was invalidated only for modified files rather than blanket invalidation, preserving edge cache efficiency for unchanged assets.

What's Next

Future improvements should include:

  • Documenting the complete DNS zone configuration for dangerouscentaur.com to prevent future shadowing issues
  • Implementing automated monitoring for DNS resolution failures using CloudWatch synthetic canaries or similar tools
  • Reviewing Lambda function cold start times and considering provisioned concurrency if checkout latency becomes an issue
  • Establishing a testing framework for CloudFront + Lambda