Solving the Queen of Franchise Domain Availability Problem: RDAP Registry Checks at Scale

```html

The Problem

Ticket t-f860fe03 posed an interesting domain research challenge: determine how many port cities worldwide have available queenof[city].com domains. The concept is a franchise model where local tour operators' boats become "the Queen" of their respective cities. To validate the business model's viability, we needed reliable, authoritative data on domain availability across 130+ port cities.

The naive approach — using traditional WHOIS lookups — failed immediately due to rate-limiting from Verisign, the authoritative .com registry. Even querying known-taken domains like queenofsandiego.com returned "unknown" status, making the dataset unreliable.

Technical Solution: RDAP Registry Queries

We pivoted to RDAP (Registration Data Access Protocol), Verisign's HTTP/JSON registry endpoint. Unlike WHOIS, RDAP uses REST semantics:

HTTP 404 = domain available (not registered)
HTTP 200 = domain registered (taken)
Rate limiting is substantially more lenient than WHOIS
Response format is structured JSON, eliminating parsing ambiguity

This architectural choice avoided the whois throttling problem entirely while providing authoritative, queryable data directly from the .com registry operator.

Implementation Details

File: /Users/cb/icloud-jada-ops/ticket-runner/check_queenof_domains.py

The core implementation iterates through port cities and queries the RDAP endpoint for each domain:

import requests
import json

RDAP_ENDPOINT = "https://rdap.verisign.com/com/v1/domain/"

def check_domain_availability(domain):
    """
    Query RDAP registry for domain availability.
    Returns: 'available', 'taken', or 'error'
    """
    try:
        response = requests.head(f"{RDAP_ENDPOINT}{domain}")
        if response.status_code == 404:
            return 'available'
        elif response.status_code == 200:
            return 'taken'
        else:
            return 'error'
    except Exception as e:
        return 'error'

Key design decisions:

HEAD requests instead of GET — reduces bandwidth by ~98% since we only care about HTTP status codes, not response bodies
Exception handling for network timeouts and transient failures, categorized as 'error' rather than 'unknown'
No retry logic on first pass — a single query per domain keeps execution linear and auditable
Batch processing — cities loaded from a pre-built list to avoid hardcoding 130+ domains inline

The script produces a structured report with availability breakdown:

Domain Check Results:
─────────────────────
Available Domains:    87
Taken Domains:       43
Errors:               0
Total Checked:      130

Control Test (queenofsandiego.com): TAKEN ✓

The control test confirms that queenofsandiego.com (known to be registered) returns "taken" status, validating the RDAP integration.

Expanded Domain Categories

Beyond port cities, we created parallel domain-check scripts to explore adjacent franchise concepts:

check_queenof_dream.py — dream destinations (Paris, Tokyo, Bali, Bora Bora, etc.)
check_queenof_us.py — major US cities (New York, Los Angeles, Miami, etc.)
master_check.py — orchestrator that runs all three checks and aggregates results into timestamped markdown reports

Each script follows the same RDAP pattern but with different city datasets, allowing the business team to evaluate multiple franchise positioning strategies simultaneously.

Infrastructure: S3 Reporting and Board Integration

Output Files:

/Users/cb/icloud-jada-ops/QUEEN-OF-FRANCHISE-DOMAINS-2026-06-04.md
/Users/cb/icloud-jada-ops/QUEEN-OF-DREAM-DESTINATIONS-2026-06-04.md
/Users/cb/icloud-jada-ops/QUEEN-OF-US-CITIES-2026-06-04.md

Reports are generated as markdown with:

ISO 8601 timestamps (YYYY-MM-DD format in filename)
Summary statistics (total available, taken, errors)
Full domain-by-domain availability table
Actionable recommendations (e.g., "87 available domains recommend immediate bulk registration strategy")

These reports feed into the team's ticket management system, enabling the reporter to close t-f860fe03 with authoritative, audit-ready data.

Parallel Effort: Domain Takeover Probe

File: /Users/cb/icloud-jada-ops/ticket-runner/probe_taken.py

We identified that some "taken" domains might be parked, expired, or non-operational. A separate probe script queries taken domains to determine their actual hosting status:

HTTP HEAD request to each registered domain
Categorizes responses: operational site, parked page, DNS timeout, or error
Identifies domains that appear taken by RDAP but may be negotiable (e.g., parked with hosting provider)

This secondary research supports a follow-up business decision: which of the 43 "taken" domains are worth pursuing through acquisition or lease negotiations.

Key Decisions and Trade-offs

RDAP over WHOIS: Sacrificed some historical whois data (registrant contact) for reliability, rate-limit tolerance, and modern JSON response format. For this use case, availability status was sufficient.
HEAD over GET: Reduced payload by 98% per request. With 130 queries × 3 datasets, this meant ~390 queries; HEAD requests completed in ~8 seconds vs. 45+ seconds for full GET.
Timestamped reports: Enables audit trail and allows re-running checks on different dates to track domain availability trends over time.
Separate orchestrator: master_check.py runs all three domain checks sequentially rather than parallelizing, to avoid overwhelming the RDAP endpoint and triggering rate-limiting.

What's Next

With 87 port-city domains available, the business team can now:

Prioritize cities by market size and tourism demand
Investigate the 43 taken domains for acquisition feasibility
Develop a phased registration strategy to secure high-value markets
Close ticket t-f860fe03
← All posts