Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

Debugging DNS Shadowing: How a Wildcard CNAME Broke adamcherrycomics.dangerouscentaur.com

A subdomain was completely unreachable for hours despite the underlying CloudFront distribution being healthy. The culprit? A DNS shadowing issue caused by RFC 1034 § 4.3.3 compliance in Namecheap's authoritative nameservers. This post walks through the debugging process and the explicit CNAME record we added to fix it.

The Problem: Site Unreachable, But CloudFront Was Fine

The site at adamcherrycomics.dangerouscentaur.com returned nothing—no DNS resolution, no connection, complete timeout. Initial diagnostics showed:

  • CloudFront distribution E2Q4UU71SRNTMB responded with HTTP 200 and correct content when accessed directly
  • The Host header override worked: curl -H "Host: adamcherrycomics.dangerouscentaur.com" https://E2Q4UU71SRNTMB.cloudfront.net returned the expected page
  • DNS was the failure point—no resolution from local resolvers, Namecheap authoritative servers, or major public resolvers

This meant the infrastructure was operational, but DNS configuration was broken.

Namecheap DNS Configuration: The Wildcard + Explicit Record Issue

The dangerouscentaur.com domain had a wildcard CNAME record configured in Namecheap:

* → CloudFront distribution CNAME alias

This wildcard was intended to catch all subdomains and route them to CloudFront. However, there was also an explicit record:

www.adamcherrycomics → [some target]

According to RFC 1034 Section 4.3.3, when a DNS node exists (even if it's just a CNAME record), that node shadows the wildcard for all names below it. In this case, the www.adamcherrycomics CNAME created a DNS node at adamcherrycomics.dangerouscentaur.com, which prevented the wildcard * from matching the base adamcherrycomics subdomain.

The result: queries for adamcherrycomics.dangerouscentaur.com found no matching record (the wildcard was shadowed by the node above it) and failed with NXDOMAIN.

The Fix: Adding an Explicit CNAME Record

The solution was straightforward: add an explicit CNAME record for the adamcherrycomics subdomain itself, pointing it to the same CloudFront distribution alias as the wildcard.

Records added to Namecheap for dangerouscentaur.com:

  • adamcherrycomics CNAME → d1234567890abc.cloudfront.net (exact CloudFront alias)
  • Existing wildcard * CNAME remained unchanged
  • HostId assigned by Namecheap: 511341200

The DNS hierarchy now looks like:

dangerouscentaur.com
  ├─ adamcherrycomics (explicit CNAME)
  ├─ www.adamcherrycomics (existing explicit CNAME)
  ├─ * (wildcard CNAME, catches other subdomains)

Verification and Propagation

After adding the record, we verified resolution at multiple levels:

  • Namecheap authoritative nameservers: Queried directly using dig @pdns1.registrar-servers.com adamcherrycomics.dangerouscentaur.com CNAME to confirm the record existed in Namecheap's system
  • Propagation delay: Polled the second authoritative nameserver (pdns2.registrar-servers.com) until the new record appeared—about 30 seconds
  • Local resolver propagation: Tested dig adamcherrycomics.dangerouscentaur.com and nslookup against system resolvers
  • Public resolver coverage: Checked against major resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1) to ensure global DNS propagation
  • HTTPS handshake: Verified the site responded with SSL/TLS and returned correct content: curl -v https://adamcherrycomics.dangerouscentaur.com

Secondary Issue: Lambda Checkout Endpoint

While debugging DNS, we also discovered and fixed issues with the checkout Lambda function. The site's checkout feature (/Users/cb/Documents/repos/sites/adamcherrycomics.com/lambda/checkout.py) had two problems:

  • Missing dependency: The typing_extensions module was not included in the Lambda deployment zip, causing import errors
  • Stripe configuration: The ui_mode parameter was missing from the Stripe checkout session creation

We rebuilt the deployment zip at checkout.zip with all dependencies included and redeployed the Lambda function adam-cherry-checkout. Smoke testing with a test product (hells-lounge SKU) confirmed the checkout flow worked end-to-end.

Key Decisions

Why not just rely on the wildcard? While the wildcard CNAME alone would have worked for other subdomains, the explicit www.adamcherrycomics record created a DNS node that shadowed it for the base domain. Rather than removing working records, adding an explicit CNAME for adamcherrycomics was the safest, most explicit solution. This follows the principle of making DNS configuration readable and maintainable—future engineers can see exactly which subdomains are configured rather than guessing whether wildcards apply.

Why verify against authoritative nameservers directly? DNS caching at resolvers and ISPs can hide propagation issues. Querying Namecheap's authoritative nameservers directly (pdns1, pdns2`) removed all layers of caching and showed us the ground truth of what Namecheap was actually serving.

What's Next

The site is now operational. Going forward:

  • Monitor CloudWatch logs for the adam-cherry-checkout Lambda function to catch any Stripe API errors
  • Document the Namecheap DNS configuration for dangerouscentaur.com to prevent future shadowing issues
  • Consider DNS-as-code tooling (Terraform, CDK) to manage DNS records explicitly and prevent manual misconfigurations

TL;DR: RFC 1034 DNS shadowing caused a wildcard CNAME to fail for the base subdomain. Adding an explicit CNAME record for adamcherrycomics.dangerouscentaur.