# Section 6 — DNS, Domain, and TLS

> Companion to [`musehub-production-readiness-checklist.md`](../musehub-production-readiness-checklist.md).

## ⚠️ Finding — `docs/infrastructure.md` is stale on DNS hosting

`docs/infrastructure.md` describes DNS as living in "Namecheap DNS (Advanced DNS tab)" with plain
A records pointing at the instances' Elastic IPs. **I verified this directly against live public
DNS and it's not what's actually deployed:**

```
dig NS musehub.ai +short
  → darl.ns.cloudflare.com.
  → cecelia.ns.cloudflare.com.

dig musehub.ai / www.musehub.ai / staging.musehub.ai +short
  → 104.21.60.105, 172.67.195.200   (Cloudflare anycast — same pair for all three hostnames)
```

**musehub.ai's nameservers are Cloudflare's, not Namecheap's.** Namecheap is the registrar; DNS
resolution authority has already been delegated to Cloudflare. This isn't a partial CNAME setup —
the NS records themselves point at Cloudflare, meaning Cloudflare is authoritative for the whole
zone. This is also the only way the rest of the documented setup is internally consistent: the
security group only accepts port 443 from Cloudflare's IP ranges, so public traffic could not
reach the origin at all unless Cloudflare's proxy sits in front — which requires Cloudflare to
host the DNS.

**Practical effect: the checklist's "Namecheap-hosted DNS vs. Route 53" decision is already moot.**
DNS is on Cloudflare today. The real open question is *Cloudflare vs. Route 53*, not
*Namecheap vs. Route 53*. Given Cloudflare is also providing edge proxy, TLS termination, and
(per Section 0) possibly R2 storage, moving DNS to Route 53 would fragment that stack for
uncertain benefit — my read is **stay on Cloudflare DNS** unless there's a specific reason to
prefer AWS-native alias records. This is a recommendation, not a decision.

## Namecheap account items — all need Gabriel

MFA, domain lock, registrant/recovery contact verification, auto-renewal, payment method
expiry, who-may-change-DNS documentation, existing-record export, MX/SPF/DKIM/DMARC preservation,
Gabriel/Aaron recovery paths — **none of this is checkable from here.** Note: since DNS is on
Cloudflare, "export DNS records before making changes" now means exporting from the **Cloudflare**
dashboard, not Namecheap's Advanced DNS tab as `infrastructure.md` implies.

## TLS — verified

- Live cert on `staging.musehub.ai`: Let's Encrypt, issued 2026-08-01, valid through 2026-10-30,
  correct CN. Verified directly (see the trust-fingerprint incident earlier in this session) —
  legitimate Cloudflare-managed certificate, not a MITM.
- HSTS already configured at the nginx layer (`includeSubDomains`, confirmed in Section 5's grep)
  — checklist's "configure HSTS only after HTTPS/subdomain behavior verified" is satisfied since
  this has been live and working.
- Cookies: N/A, no cookies in use (MSign is header-based).
- **Not verified from here**: ACM certificate existence (there's no ALB/CloudFront to attach one
  to — TLS termination happens at Cloudflare's edge, not AWS, so the checklist's "request an ACM
  certificate" item may simply not apply to this architecture). Certificate-expiration monitoring,
  full chain testing, and Cloudflare SSL mode settings all need confirming in the Cloudflare
  dashboard directly.

## Canonical hostname — still open

Both `musehub.ai` and `www.musehub.ai` resolve identically today; no redirect logic was found in
the nginx config reference. **Needs Gabriel's decision** (root vs. `www` as canonical) — recorded
as open in the Section 0 doc and the main checklist's Accepted Risks table.

## API hostname

No `api.musehub.ai` exists or is planned as far as I can tell — MuseHub serves API and web UI from
the same origin. Not a gap, just worth confirming that's intentional rather than assumed.