memory: planned 2026-09-18 dragonfireacoustics move to Namecheap/Cloudflare — DNS-first ordering and the wildcard-masking trap

2026-09-17 21:50:16 -07:00
parent 8d2b5f6b2e
commit d8f4844a43
1 changed files with 22 additions and 0 deletions
@@ -117,6 +117,28 @@ no longer deployed sidecars here. See Recent decisions.)
 _As of 2026-09-17 ~09:00 PT._
 ### PLANNED 2026-09-18 (operator) — move `dragonfireacoustics.com` to Namecheap, DNS to Cloudflare
 Operator holds the **TAC/EPP** already. TAC is **single-use and dies 14 days after issue**, so the
 clock is running; domain itself expires **2026-10-30** and a transfer adds a year, so the transfer
 IS the renewal if it lands in time.
 ⚠ **Recommended order is DNS FIRST, transfer second** — stand the Cloudflare zone up, repoint the
 nameservers at eNom (NS is a registrar function he already has access to), verify mail and the site,
 THEN burn the TAC. The registry keeps the NS delegation across a transfer and Namecheap does not
 overwrite it, so nothing has to be redone; and if DNS goes wrong you still have a working registrar
 account to revert at instead of discovering it mid-transfer with a spent code.
 ⚠⚠ **The zone's `*` wildcard MASKS what is really there.** Everything — apex, mail, webmail, admin,
 ftp — answers 199.250.192.76 (dead) purely because of that one record. Cloudflare's add-a-zone scan
 will happily import the dead wildcard and may not surface what is genuinely configured, so the
 **7 Google Workspace MX records must be checked by hand after the import** or mail stops. The only
 records that actually matter: `www A 38.120.12.45` and those MX.
 Open sub-decisions carried into the move: point the apex at 38.120.12.45 too (makes the bare domain
 work for the first time and lets a replacement cert cover it), and add SPF/DMARC — the domain runs
 Google Workspace with **neither**.
 ### DONE: lv-mccarthy D4 pairs built — NEXT is `train_pairs_lora.py`
 `~/lv-mccarthy/pairs/` on gx10, 2026-09-17 11:55 PT via `run-pairs.sh` (committed at