gabriel / musehub public
06-dns-domain-tls.md markdown
67 lines 3.8 KB
Raw
sha256:7d5985ef251de9f0154f9b185a75cf36174bf73e0c34f5eca133e7bd20224bf4 Merge branch 'feat/opengraph-repo-cards' into dev Human 23 days ago

Section 6 — DNS, Domain, and TLS

Companion to 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.

File History 1 commit
sha256:be1b2fdf6ab1fc652b3b35a945d0277a36fbf5d96e63692020d36cd7ebe03534 Merge 'docs/security-monitoring-verified' into 'dev' — prop… Human 3 days ago