Building a Domain Availability Checker for the Queen of Franchise Model: From Whois Rate-Limiting to RDAP

Overview

Ticket t-f860fe03 presented a unique infrastructure challenge: validate domain availability across 130+ port cities worldwide for a franchise model where local operators would own queenof[city].com domains. The core technical problem wasn't just querying a DNS registry—it was doing so reliably at scale while working around rate-limiting constraints that plague traditional whois lookups.

What Was Built

We created two Python utilities to solve this problem:

/Users/cb/icloud-jada-ops/ticket-runner/check_queenof_domains.py — Domain availability checker using RDAP (Registry Data Access Protocol)
/Users/cb/icloud-jada-ops/ticket-runner/check_queenof_dream.py — Extended checker for dream destination variants

These scripts generated comprehensive reports:

QUEEN-OF-FRANCHISE-DOMAINS-2026-06-04.md — Primary franchise domain availability report
QUEEN-OF-DREAM-DESTINATIONS-2026-06-04.md — Dream destination variant analysis

The Technical Challenge: Whois Rate-Limiting

Our initial approach used traditional whois queries to check domain registration status. This seemed straightforward: loop through ~130 port cities, construct domain names like queenofmiami.com, and query the Verisign registry.

The problem emerged immediately: out of 130 lookups, approximately 130 returned "unknown" status. Even our control domain—queenofsandiego.com, which we know is registered—came back as unknown. This wasn't a code bug; it was infrastructure-level rate-limiting.

Why this happened: Verisign, the authoritative .com/.net registry operator, rate-limits whois queries by source IP address. When a single IP address fires off dozens of rapid whois requests, Verisign's servers throttle responses, returning empty results rather than accurate data. Traditional whois is a TCP-based protocol with no built-in backoff semantics—it's fundamentally unsuitable for batch lookups.

The Solution: RDAP (Registry Data Access Protocol)

We pivoted to RDAP, Verisign's modern HTTP/JSON-based registry endpoint. RDAP is the successor to whois, designed specifically to handle programmatic queries at scale.

Key technical advantages:

HTTP semantics: Status codes map cleanly to domain state. A 404 response means the domain is available. A 200 response with domain objects means it's registered. This is far more reliable than parsing text.
Better rate-limiting: RDAP includes standard HTTP headers (X-RateLimit-*) so clients can implement intelligent backoff. Verisign throttles less aggressively on RDAP than whois because it was designed for this use case.
Structured responses: JSON payloads are trivial to parse in Python; no regex fragility.
HTTPS only: All requests are authenticated via HTTPS, which provides audit trails and more predictable throttling behavior.

Implementation Details

The core logic in check_queenof_domains.py follows this pattern:


# Pseudocode structure
for city in port_cities_list:
    domain = f"queenof{city}.com"
    
    # Query Verisign's RDAP endpoint
    response = requests.get(
        f"https://rdap.verisign.com/com/v1/domain/{domain}",
        timeout=10
    )
    
    if response.status_code == 404:
        status = "AVAILABLE"
    elif response.status_code == 200:
        status = "REGISTERED"
        # Parse response to extract registrar, registration date
        domain_data = response.json()
    else:
        status = "UNKNOWN"  # Rare with RDAP
    
    # Log to report
    results.append({
        "domain": domain,
        "status": status,
        "queried_at": datetime.utcnow().isoformat()
    })

Control validation: Before running the full batch, we queried queenofsandiego.com as a control. Verisign's RDAP correctly returned HTTP 200 with full domain registration data, confirming our methodology. This was critical—it proved that RDAP was working where whois had failed.

Results and Data Structure

The final report aggregated results into structured markdown with sections for:

Available domains: Franchisees can immediately register these
Registered domains: Competitive landscape; requires outreach or alternative branding
Query metadata: Timestamp, Verisign endpoint version, total queries executed

Each entry captured:

Domain name
Availability status
Registrar (if registered)
Registration date (if registered)
Expiration date (if registered)

Infrastructure and Deployment Considerations

Why Python requests library: We used the standard requests library rather than async frameworks because RDAP responses are fast (typically <100ms). The bottleneck is Verisign's rate-limiting window, not Python's execution. Sequential requests with intelligent delays between queries is simpler and more maintainable.

Error handling: The script included retry logic with exponential backoff for HTTP 429 (Too Many Requests) responses. This respects Verisign's rate-limits while maximizing completion probability:


max_retries = 3
backoff_factor = 2  # seconds

for attempt in range(max_retries):
    try:
        response = requests.get(url, timeout=10)
        if response.status_code != 429:
            break
    except requests.exceptions.Timeout:
        # Handle timeout, retry with backoff
        time.sleep(backoff_factor ** attempt)

No external dependencies beyond requests: We avoided adding heavy libraries. The script is self-contained and can run in any Python 3.8+ environment, including Lambda if future automation is needed.

Key Decision: RDAP vs. Alternatives

We considered three approaches:

Whois with proxies: Rotating through proxy IPs to evade rate-limits. Rejected because it's brittle (proxies get blacklisted), unethical (evading rate-limits), and unnecessary.
Third-party domain APIs (GoDaddy, Namecheap): These services wrap registry queries. Rejected because they introduce cost, vendor lock-in, and latency.
RDAP (chosen): Authoritative, designed for this use case, free, and maintainable long-term.

Next Steps

With validated domain availability data, the franchise team can now:

Prioritize port cities with