Solving the Queen of Franchise Domain Availability: RDAP Over WHOIS for Reliable Registry Queries at Scale

What We Did

We solved ticket t-f860fe03, a critical business problem: identifying available queenof[city].com domains across 130+ US port cities for a franchise expansion opportunity. The Queen of [City] concept—where local tour operators purchase branded domains for boat operations—required us to systematically check domain availability across a large geographic footprint.

The challenge wasn't just writing a script; it was choosing the right registry query method when the naive approach (WHOIS) failed due to rate-limiting, then building reliable infrastructure to validate our findings.

Technical Details: From WHOIS to RDAP

The WHOIS Problem

Initial implementation in /Users/cb/icloud-jada-ops/ticket-runner/check_queenof_domains.py used Python's whois library for domain lookups. The results were stark: 130+ domains returned "unknown" status due to Verisign rate-limiting.

This wasn't a bug in our code—it was a fundamental limitation of WHOIS:

Connection-based throttling: Verisign throttles by source IP after ~10-15 rapid queries, returning empty responses rather than hard rejections
No authentication: WHOIS has no built-in rate-limit headers or authentication, making per-IP limits the only control mechanism
Blocking uncertainty: Distinguishing between "domain available" and "IP throttled" is impossible from the client side
Control test failure: Even querying queenofsandiego.com (which we know is registered) returned unknown, confirming throttling had begun

The RDAP Solution

We switched to RDAP (Registration Data Access Protocol), Verisign's HTTP/JSON registry endpoint. RDAP is fundamentally better for programmatic queries:

HTTP-based: Standard HTTP status codes provide unambiguous results: 404 = available, 200 = registered
Rate-limit friendly: Rate limits are communicated via HTTP headers, not connection drops
JSON responses: Structured data is easier to parse and validate
Less throttling: RDAP is designed for programmatic access; abuse is mitigated through rate-limit headers rather than IP blocking

Our updated Python implementation uses the RDAP registry endpoint directly:

import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

def check_domain_rdap(domain, max_retries=3):
    """
    Check domain availability via RDAP (Registration Data Access Protocol).
    Returns: 'available', 'registered', or 'error'
    """
    session = requests.Session()
    retry_strategy = Retry(
        total=max_retries,
        backoff_factor=1,
        status_forcelist=[429, 500, 502, 503, 504]
    )
    adapter = HTTPAdapter(max_retries=retry_strategy)
    session.mount("http://", adapter)
    session.mount("https://", adapter)
    
    try:
        # RDAP domain lookup endpoint (Verisign)
        url = f"https://rdap.verisign.com/com/v1/domain/{domain}"
        response = session.get(url, timeout=5)
        
        if response.status_code == 404:
            return 'available'
        elif response.status_code == 200:
            return 'registered'
        else:
            return 'error'
    except requests.RequestException:
        return 'error'

Key implementation details:

Exponential backoff: We use urllib3's Retry strategy with backoff_factor=1 to respect rate-limit delays (1s, 2s, 4s between retries)
Status code handling: Rather than parsing response bodies, we rely on HTTP semantics
Control validation: Testing against queenofsandiego.com correctly returned 200 (registered), proving the method works

Infrastructure & Workflow Integration

Ticket-Runner Architecture

The domain checker lives within our ticket-runner system at /Users/cb/icloud-jada-ops/ticket-runner/check_queenof_domains.py. This is a standalone module that:

Reads a hardcoded list of 130+ US port cities (major cargo ports, cruise hubs, and regional harbors)
Constructs domain names as queenof{city}.com (lowercase, spaces/hyphens stripped)
Queries the RDAP endpoint for each domain
Logs results with timing data for audit trails

Results & Reporting

Final results were written to /Users/cb/icloud-jada-ops/QUEEN-OF-FRANCHISE-DOMAINS-2026-06-04.md, a structured markdown report containing:

Available domains: List of all queenof[city].com domains with 404 status
Registered domains: Domains already taken (competitor franchises or squatters)
Query metadata: Timestamp, total domains checked, success rate, average response time
Methodology notes: Explicit documentation that RDAP was used and why WHOIS was insufficient

Key Decisions & Trade-offs

Why Not Use Third-Party Domain APIs?

Services like GoDaddy API or Namecheap offer high-level domain checking, but we chose direct RDAP access because:

Cost: RDAP is free; commercial APIs charge per query or require subscriptions
Transparency: Direct registry queries are authoritative with no middleman caching or delays
Speed: No extra API orchestration layer—direct to Verisign's registry
Audit trail: All lookups are logged locally without third-party records

Rate-Limit Handling

Rather than blast all 130 domains in parallel, we implemented sequential queries with exponential backoff. This approach:

Respects Verisign's rate limits (avoiding IP blocking)
Makes the process predictable and reproducible
Allows easy manual re-runs if needed without infrastructure changes
Completes in ~3-5 minutes for full dataset (acceptable for a one-time research task)

For future scale (checking 10,000+ domains), we'd implement multi-threaded queries with per-domain backoff tracking.

What's Next

With domain availability confirmed, the next steps for the franchise team are:

Bulk registration: Prioritize the highest-value port cities for immediate domain purchases