Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

File write requires approval. Here's the HTML directly: ---

RDAP Domain Scanning for a Franchise Concept, and Cutting Over a Parked Site to CloudFront

What Was Done

Two unrelated workstreams ran in parallel on June 5. The first was a domain-availability sweep for a franchise concept: for every notable port city in the world, is queenof[city].com available? The idea is that a local boat operator in each city could license the "Queen of" brand—the Queen of Lisbon, the Queen of Cartagena—and the domain portfolio becomes the moat. The second task was diagnosing and completing a stalled CloudFront deployment for dragonbodyguards.com, a site that had DNS and S3 config in place but was not serving traffic.

Technical Details: RDAP Domain Scanner

The first cut of the domain checker used the system whois binary, wrapped in a Python subprocess call inside check_queenof_domains.py. Verisign rate-limits whois aggressively by source IP—even queenofsandiego.com, a domain we own and know is registered, came back unknown on the first run. 130 out of 131 domains returned indeterminate results, which is useless. The fix was to replace WHOIS with RDAP (Registration Data Access Protocol), Verisign's HTTP/JSON endpoint at https://rdap.verisign.com/com/v1/domain/{name}. The semantics are clean: HTTP 404 means the domain is not registered (available); HTTP 200 means registered (taken). No parsing of freeform text, no rate-limit blackouts, fully deterministic output. The rewritten checker used Python's requests library with a short timeout and a one-second sleep between queries to stay polite.

The city list was split into three separate domain lists, each with its own checker script:

  • check_queenof_domains.py — port cities worldwide (the core franchise targets)
  • check_queenof_dream.py — aspirational "dream destination" cities
  • check_queenof_us.py — US cities only, for a domestic-first rollout scenario

master_check.py orchestrated all three, writing results to markdown reports under /Users/cb/icloud-jada-ops/: QUEEN-OF-FRANCHISE-DOMAINS-2026-06-04.md, QUEEN-OF-DREAM-DESTINATIONS-2026-06-04.md, and QUEEN-OF-US-CITIES-2026-06-04.md. A fourth script, probe_taken.py, took every domain that came back registered and issued an HTTP GET against it—checking whether it resolves to an active site, a parked page, or an error—which tells you how aggressively a squatter is holding each name. Results landed in QUEEN-OF-TAKEN-DOMAINS-2026-06-04.md. The control check (queenofsandiego.com) correctly returned TAKEN on every run under RDAP. Final tally: a meaningful fraction of desirable port-city queenof*.com names are unregistered.

Technical Details: dragonbodyguards.com CloudFront Cutover

The dragonbodyguards.com site had been stalled: DNS pointed at an old endpoint, and the S3 bucket was misconfigured for the routing pattern expected by the existing CloudFront function. Diagnosis started with curl -v probes against the S3 REST endpoint and the distribution, which surfaced a bucket policy gap and a viewer-request CloudFront function that wasn't matching the apex and www aliases consistently. The fix was drafted in /tmp/router_new.js before being applied. The deploy plan was written to sites/dragonbodyguards/DEPLOY-PLAN.md and the site structure was documented in sites/dragonbodyguards/CLAUDE.md and sites/dragonbodyguards/CONTEXT.md before any changes went live.

The cutover sequence:

  • Deployed a single-file index.html MVP to the S3 bucket with aws s3 cp—no asset dependencies, so the full path could be verified before adding complexity.
  • Requested an ACM certificate in us-east-1 (CloudFront's required region) covering both dragonbodyguards.com and www.dragonbodyguards.com.
  • Added the two DNS CNAME validation records in Namecheap to let ACM auto-validate via DNS.
  • Updated and published the CloudFront routing function—capturing the ETag from the DEVELOPMENT stage before promoting to LIVE—to correctly handle both host variants.
  • Created a new CloudFront distribution fronting the S3 bucket with the ACM cert attached and both aliases configured.
  • Cut DNS for apex and www to the new .cloudfront.net hostname.

Distribution propagation took roughly 15 minutes. Verification used curl --resolve dragonbodyguards.com:443:[ip] https://dragonbodyguards.com/ to bypass local DNS cache and hit the distribution directly, then confirmed clean resolution via fresh public resolvers once TTLs expired. Both variants served the page over TLS. Live infrastructure state was saved to .claude/projects/.../memory/dragonbodyguards-live.md so the next session doesn't re-diagnose from scratch.

Key Decisions

Switching from WHOIS to RDAP was the pivotal call on the domain scanner. WHOIS is freeform text with no stable schema and a per-IP rate limit that Verisign enforces hard against any automated client. RDAP is the IETF standard replacement (RFC 7483), returns structured JSON, and Verisign's endpoint is designed for programmatic access. The 404/200 semantic requires zero string parsing and is unambiguous. For any future domain research at scale, RDAP is the only correct starting point—WHOIS is a dead end the moment your list has more than a handful of names. On the CloudFront side, keeping the initial deploy to a single static index.html with no external assets was intentional: it let us verify the complete path (DNS → CloudFront function → S3 origin → TLS termination) in isolation. Full content can be added without touching infrastructure.

What's Next

  • Register the highest-value available queenof[city].com domains before the research report circulates and tips off anyone watching registrar transaction logs.
  • Wire the domain reports into the ticket board so ticket t-f860fe03 closes with a linked artifact rather than a markdown file on disk with no provenance.
  • Build out dragonbodyguards.com beyond the MVP index—the infra path is proven clean, so this is purely content and design work now.
  • Add a live-recheck cron to master_check.py so the available-domain list stays current; squatters register names continuously and the window closes without notice.