Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

```html

Domain Availability Research at Scale: Building a Franchise Validation Pipeline for "Queen Of" Port Cities

Overview

Ticket t-f860fe03 required determining how many port cities worldwide have available queenof[city].com domains for a franchise concept where local tour operators would operate branded boat services. This task involved:

  • Assembling a curated list of ~130 beautiful port cities
  • Checking domain availability at scale without rate-limiting
  • Authoritatively determining registration status via registry queries
  • Recording results for business decision-making

The challenge: naive whois queries hit Verisign throttling within ~50 requests, returning "unknown" status for domains that might be available. The solution required switching to RDAP (Registrar Data Access Protocol)—Verisign's HTTP/JSON endpoint—which is authoritative, rate-resistant, and returns clean 404/200 responses.

Architecture and Implementation

File Structure

Created a modular checking system under /Users/cb/icloud-jada-ops/ticket-runner/:

  • check_queenof_domains.py — Primary domain checker using RDAP queries
  • check_queenof_dream.py — Dream destination city variant
  • check_queenof_us.py — US cities variant
  • master_check.py — Orchestrates all three checks
  • probe_taken.py — Deep inspection of taken domains (whois, hosting probe, SSL inspection)

Output reports written as markdown:

  • QUEEN-OF-FRANCHISE-DOMAINS-2026-06-04.md — International port cities (~130 domains)
  • QUEEN-OF-DREAM-DESTINATIONS-2026-06-04.md — Curated dream locations
  • QUEEN-OF-US-CITIES-2026-06-04.md — US port cities
  • QUEEN-OF-TAKEN-DOMAINS-2026-06-04.md — Detailed analysis of registered domains

RDAP-Based Availability Checking

The initial whois approach failed because Verisign's whois server implements IP-based rate limiting. After ~50 sequential queries from a single IP, responses degrade to "unknown" status, making it impossible to distinguish between "not yet queried by this IP" and "actually unregistered."

RDAP (RFC 7480/7481) solved this by:

  • Using HTTP instead of raw socket queries, allowing more granular rate-limit headers
  • Returning deterministic JSON responses: HTTP 404 = domain available, HTTP 200 = domain registered
  • Being the official registry data access protocol (less throttled than legacy whois)

Example query pattern:

curl -s "https://rdap.verisign.com/com/v1/domain/queenofsandiego.com" | jq .status
# Returns: ["active"]  → domain IS registered
# Returns: 404 → domain IS available

The Python wrapper in check_queenof_domains.py:

  • Iterates through city list
  • Constructs queenof{city}.com domain names
  • Fires RDAP queries (with backoff for rate limits)
  • Logs status: AVAILABLE, TAKEN, ERROR
  • Compiles markdown report with statistics

Validation Domain (Control Test)

To verify the checker was working correctly, we used queenofsandiego.com as a known-taken control. The domain is legitimately registered and points to infrastructure. Initial whois queries reported "unknown" due to rate limiting, but RDAP correctly returned HTTP 200 with active registration status, confirming the approach.

Deep Inspection of Taken Domains

After determining which domains were registered, probe_taken.py performed follow-up analysis:

  • Whois records: Registrar, registration date, nameserver details
  • DNS resolution: Nameserver queries to determine if domain points to live hosting
  • HTTP probing: Attempting to resolve and connect to the domain's IP to identify what's hosted (live website, parked page, S3 bucket error, etc.)
  • SSL certificate inspection: Fetching cert details to understand hosting provider and date of last update

This yielded actionable intelligence: which taken domains were truly active businesses vs. speculative registrations or abandoned domains.

Results and Reporting

Across three city lists:

  • International franchise domains (~130): X available, Y taken
  • Dream destinations (~50 curated): X available, Y taken
  • US port cities (~30): X available, Y taken

Each report included:

  • Summary statistics
  • Complete list of available domains (immediately actionable for registration)
  • Complete list of taken domains with registrar and probe results
  • Timestamp and methodology notes

Key Technical Decisions

Why RDAP Over Whois

whois is the legacy standard for domain queries, but it's vulnerable to rate limiting at the transport layer. Verisign's whois server throttles by IP, not by auth token or account. RDAP, by contrast, is the modern registry access protocol and is explicitly designed for programmatic, at-scale queries. Using RDAP meant we could reliably check 130+ domains without hitting unknown responses.

Modular Checker Design

Rather than one monolithic script, we created separate checkers for:

  • Franchise domains (international port cities)
  • Dream destinations (curated travel locations)
  • US cities (domestic focus)

This allows different city lists to be maintained independently and re-run on different schedules. The master_check.py orchestrator runs all three and combines results for the ticket reporter.

Separation of Availability Check and Deep Probe

check_queenof_domains.py answers: "Is this domain registered?" probe_taken.py answers: "What's actually hosting on this domain?" Keeping these separate makes the pipeline faster (probing is I/O-heavy and optional) and clearer (each script has one responsibility).

Integration with Ticket System

Results were formatted as markdown reports and stored alongside ticket metadata, allowing the ticket system to reference them for business decisions. The clean AVAILABLE/TAKEN/ERROR categorization makes it trivial to extract actionable domain lists (domains ready to register, domains already claimed by competitors).

What's Next

  • Domain registration pipeline: Auto