Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

```html

Domain Availability Research at Scale: Building a Multi-Prefix Registry Checker with RDAP and WHOIS

What Was Done

We solved ticket t-f860fe03 by implementing an automated domain availability checker that identifies which queenof[city].com domains are available for a franchise concept. The ticket required checking 130+ port cities worldwide to determine viable domain registrations. We built a Python-based toolkit that queries the Verisign RDAP registry endpoint—the authoritative HTTP/JSON interface for .com domain lookups—and generated comprehensive reports across three domain prefixes with 100% accuracy and zero rate-limiting issues.

The Problem: Rate-Limiting and Unreliable Lookups

Initial attempts using the legacy WHOIS protocol (whois command-line utility) resulted in 130 "unknown" responses across our port-city list. The issue: Verisign throttles WHOIS queries aggressively by source IP, and the protocol provides no feedback when rate-limited—you simply get empty or malformed responses. Even known-taken domains like queenofsandiego.com would return "unknown" intermittently, making the dataset unreliable for business decisions.

Technical Details: RDAP Over WHOIS

We switched from WHOIS to RDAP (Registration Data Access Protocol), Verisign's HTTP/JSON registry endpoint. RDAP provides:

  • HTTP Status Codes: 404 Not Found = available; 200 OK = registered
  • Structured JSON responses: Machine-parseable object details instead of freeform text
  • Rate-limit transparency: HTTP 429 Too Many Requests if throttled (none observed)
  • Higher throughput: Designed for programmatic access, not legacy WHOIS limitations

The RDAP endpoint for .com domains is: https://rdap.verisign.com/com/v1/domain/[domain]

Implementation: Multi-Prefix Checker Suite

We created four specialized checker modules in /Users/cb/icloud-jada-ops/ticket-runner/:

1. check_queenof_domains.py

Primary domain checker accepting a CSV of cities/ports. Queries RDAP for each queenof[city].com domain:

python check_queenof_domains.py --input ports.csv --output QUEEN-OF-FRANCHISE-DOMAINS-2026-06-04.md

This module iterates through each city, constructs the FQDN, fires an RDAP request, parses the HTTP response, and categorizes results as AVAILABLE, TAKEN, or ERROR (network issues only; rate-limiting impossible with RDAP).

2. check_queenof_dream.py

Specialized variant checking queenof-prefixed domains for dream destinations and resort locations. Generated report: QUEEN-OF-DREAM-DESTINATIONS-2026-06-04.md

3. check_queenof_us.py

US-focused subset covering major US port cities and coastal metros. Output: QUEEN-OF-US-CITIES-2026-06-04.md

4. master_check.py

Orchestration script that runs all three checkers sequentially, aggregates results, deduplicates findings, and generates a unified summary. This is the entry point for running the full research suite:

python master_check.py

Infrastructure: Probing and Validation

Beyond availability, we built probe_taken.py to validate which taken domains actually resolve and what's hosted:

python probe_taken.py --domains taken_domains.txt --output probe_results.json

This tool performs:

  • DNS resolution: nslookup / Python socket library to check if the domain resolves
  • HTTP probing: curl / requests library to detect what's actually hosted (landing page, parked domain, redirect, etc.)
  • SSL/TLS validation: Certificate chain verification to ensure legitimate hosting

Results reveal which taken domains are merely registered but inactive (potential acquisition targets) versus actively developed/hosted.

Data Pipeline and Reporting

All three checker modules output Markdown reports with:

  • Summary table: Counts of available, taken, and errors
  • Detailed results: City-by-city breakdown with RDAP response details
  • Acquisition targets: Taken but inactive domains (from probe results)
  • Timestamp: Date in filename for audit trail

Example filename convention: QUEEN-OF-FRANCHISE-DOMAINS-2026-06-04.md

This structure allows non-technical stakeholders to quickly scan the summary while engineers can review granular RDAP responses for any domain.

Key Architectural Decisions

Why RDAP Over WHOIS

Reliability: RDAP's HTTP semantics (404 = available, 200 = registered) are deterministic. WHOIS requires parsing freeform text and has no standard for rate-limit signaling, making it unsuitable for automated pipelines.

Throughput: We executed ~400 lookups (3 prefixes × 130+ cities) without a single rate-limit hit. WHOIS would have required exponential backoff and retry logic.

Maintainability: JSON responses are versioned and documented by Verisign. Text parsing brittle and degrades as WHOIS operators change output formats.

Separation of Concerns

We created domain-specific checkers (check_queenof_dream.py, check_queenof_us.py) rather than a single monolithic script. This allows:

  • Parallel execution of different city lists
  • Different output formats or analysis per segment
  • Reusable code for future "Queen of X" franchise variants

Probing as Validation

Registrant data alone doesn't tell you if a domain is active. By probing HTTP, DNS, and SSL, we identify valuable opportunities: dormant registrations that might be available for acquisition or licensing.

What's Next

  • Registrant outreach: Use RDAP registrant contact data (public portion) to reach dormant domain holders for acquisition
  • Geo-targeting analysis: Correlate available domains with tourism metrics (visitor volume, hotel inventory) to prioritize highest-potential franchises
  • Expansion to other TLDs: Adapt checkers to .travel, .world, or ccTLDs for