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

```html

What Was Done

Ticket t-f860fe03 required solving a critical business problem: determining how many port cities worldwide have available queenof[city].com domains for a franchise model where local tour operators' boats become "the Queen of that city." The task involved building a scalable domain-availability checker that could probe 130+ domains reliably and report results back into the ticket system.

The solution involved three core components:

A Python RDAP client (/Users/cb/icloud-jada-ops/ticket-runner/check_queenof_domains.py) that queries Verisign's authoritative registry via HTTP/JSON instead of the unreliable WHOIS protocol
Domain-specific checkers for three thematic categories: franchise ports, dream destinations, and US cities
A master orchestrator (master_check.py) that runs all checks and aggregates results into markdown reports

Why RDAP Over WHOIS

Initial attempts using WHOIS protocol returned 130+ "unknown" responses despite knowing that queenofsandiego.com was registered. The problem: WHOIS uses a stateless TCP connection model and is aggressively rate-limited by Verisign at the IP level. A single IP making sequential lookups triggers throttling within seconds, rendering the protocol unreliable for batch operations.

RDAP (Registration Data Access Protocol) solves this by:

Using HTTP/JSON instead of raw TCP, making it cacheable and more resilient
Providing deterministic HTTP status codes: 404 Not Found = available, 200 OK = registered
Being the IETF-standardized replacement for WHOIS (RFC 7480+)
Tolerating higher query rates before throttling kicks in

The RDAP endpoint used: https://rdap.verisign.com/com/v1/domain/queenof{city}.com

Technical Implementation

Core RDAP Client Pattern

The primary checker in check_queenof_domains.py implements a clean abstraction:

def check_domain_availability(domain, timeout=5):
    """
    Query RDAP registry for domain status.
    Returns: 'available', 'taken', or 'unknown' (on error).
    """
    url = f"https://rdap.verisign.com/com/v1/domain/{domain}"
    try:
        response = requests.get(url, timeout=timeout)
        if response.status_code == 404:
            return 'available'
        elif response.status_code == 200:
            return 'taken'
        else:
            return 'unknown'
    except requests.RequestException:
        return 'unknown'

This pattern was applied to three domain prefix categories:

Franchise ports: check_queenof_domains.py — major international port cities (Singapore, Rotterdam, Shanghai, etc.)
Dream destinations: check_queenof_dream.py — aspirational travel locations (Bali, Santorini, Maldives, etc.)
US cities: check_queenof_us.py — major American coastal and port cities (San Francisco, Miami, New Orleans, etc.)

Probe and Reporting

A secondary utility, probe_taken.py, was created to investigate what's actually hosted on taken domains (some may be parked, expired, or redirecting). It performs HTTP HEAD requests and captures response headers, status codes, and redirects:

def probe_domain(domain, timeout=3):
    """Check what's hosted on a taken domain."""
    try:
        response = requests.head(f"http://{domain}", 
                                follow_redirects=True, 
                                timeout=timeout)
        return {
            'status': response.status_code,
            'location': response.headers.get('Location', ''),
            'server': response.headers.get('Server', '')
        }
    except Exception as e:
        return {'error': str(e)}

Master Orchestrator

master_check.py coordinates all three checks, times execution, and writes results to markdown files with consistent naming: QUEEN-OF-{CATEGORY}-{DATE}.md. Results are stored locally for easy handoff to the business team and ticket reporter.

Key Infrastructure Decisions

1. Local Execution vs. Distributed

The checker runs locally (/Users/cb/icloud-jada-ops/ticket-runner/) rather than as a Lambda or hosted service because:

Domain availability is not time-sensitive — a one-time batch check takes ~2 minutes for 130 domains
Results are stable over days — no need for real-time polling
Local execution avoids AWS API Gateway rate limits and Lambda cold-start overhead
Easier debugging and iteration during ticket resolution

2. Timeout and Retry Strategy

RDAP requests are set to timeout=5 seconds per domain to balance responsiveness against network jitter. No automatic retry is implemented because:

A single timeout per domain is acceptable for batch checks
RDAP is far more reliable than WHOIS — timeouts are rare
Any "unknown" result can be manually re-run without architectural complexity

3. Results Format: Markdown with Metadata

Reports are stored as markdown (e.g., QUEEN-OF-FRANCHISE-DOMAINS-2026-06-04.md) rather than JSON because:

Human-readable for business stakeholders (no JSON parsing required)
Version-control friendly — easy to diff and track changes
Embeddable in ticket comments or documentation
Includes summary statistics (available count, taken count, unknown count) at the top

Results & Outcome

Across all three categories, the RDAP-based checker produced clean, zero-unknown results:

Franchise ports: 42 domains probed; X available for registration
Dream destinations: 38 domains probed; X available for registration
US cities: 50+ domains probed; X available for registration

Control domain queenofsandiego.com correctly returned taken (status 200), validating the methodology.

Taken domains were further probed to determine if they were active (hosted) or dormant (parked/