Solving the "Queen Of" Domain Franchise Model: Building a Scalable Port-City Availability Checker

Overview

Ticket t-f860fe03 presented a deceptively simple research problem: identify how many port cities worldwide have available queenof[city].com domains for a franchise concept where local tour operators could brand their boats as "the Queen of [City]." What began as a straightforward whois lookup evolved into a lesson in registry infrastructure, rate-limiting, and building reliable domain-availability tooling at scale.

What Was Done

We built a three-part solution:

Created domain-availability checking scripts for franchise concepts across three categories: port cities, dream destinations, and US cities
Implemented RDAP (Registration Data Access Protocol) as the authoritative lookup mechanism, replacing unreliable whois
Generated comprehensive markdown reports documenting availability across 100+ cities per category
Integrated results back into the ticket tracking system

Technical Details: The Evolution from WHOIS to RDAP

Initial Approach: WHOIS and Its Limitations

The first implementation used Python's whois library to check domain availability. We created /Users/cb/icloud-jada-ops/ticket-runner/check_queenof_domains.py with a straightforward approach:

import whois

def check_domain_availability(domain):
    try:
        result = whois.whois(domain)
        return "registered" if result else "available"
    except:
        return "unknown"

# Test with control domain
control = check_domain_availability("queenofsandiego.com")  # Known: TAKEN

This worked for initial validation—we confirmed that queenofsandiego.com (which hosts the franchise PDF at /g/dorsey-whitney-oct24.pdf) correctly showed as registered. However, when we scaled to 130 port cities, whois became unreliable: Verisign rate-limits queries per IP address, causing legitimate registered domains to return "unknown" status.

The fundamental issue: WHOIS is a legacy protocol without built-in rate-limiting tolerance. For port-city research at scale, this was a blocker.

The RDAP Solution

We switched to RDAP (RFC 7480/7481), Verisign's HTTP/JSON registry interface. Key advantages:

HTTP-native: Designed for modern web clients; respects standard HTTP status codes
Less throttled: Uses rate-limiting headers rather than connection drops
Authoritative: Queries Verisign's registry directly
Semantically clear: 404 = available, 200 = registered

We rewrote check_queenof_domains.py to use RDAP:

import requests
import time

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

def check_domain_rdap(domain):
    """
    Query RDAP for domain availability.
    404 = available, 200 = registered, other = error
    """
    try:
        response = requests.head(f"{RDAP_ENDPOINT}{domain}")
        if response.status_code == 404:
            return "available"
        elif response.status_code == 200:
            return "registered"
        else:
            return "error"
    except Exception as e:
        return "error"
    finally:
        # Respect rate limits
        time.sleep(0.5)

# Control test
test = check_domain_rdap("queenofsandiego.com")  # Should return "registered"

The result: zero unknown statuses, clean authoritative data. We validated that our control domain (queenofsandiego.com) correctly showed as registered.

Multi-Category Domain Checking

The project expanded to three distinct franchise concepts, each with its own script and city list:

1. Port Cities (Primary Concept)

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

Cities checked: ~130 major port cities (Singapore, Rotterdam, Hong Kong, Shanghai, Dubai, Los Angeles, New York, Sydney, etc.)

Report: QUEEN-OF-FRANCHISE-DOMAINS-2026-06-04.md

2. Dream Destinations

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

Focus: Scenic/aspirational destinations (Maldives, Bora Bora, Santorini, Bali, Mauritius, etc.)

Report: QUEEN-OF-DREAM-DESTINATIONS-2026-06-04.md

3. US Cities

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

Focus: US port and lakefront cities (Seattle, Miami, New Orleans, Chicago, Boston, etc.)

Report: QUEEN-OF-US-CITIES-2026-06-04.md

Each script followed the same pattern: curate a city list, iterate with RDAP checks, aggregate results, and generate a markdown report with availability counts and specific city-domain pairs.

Infrastructure and Integration Points

Ticket System Integration

The ticket (t-f860fe03) was fetched from a public board state endpoint and dynamically resolved. We identified the board writer permissions and integrated findings back through the established ticket tracking system, ensuring the reporter adapter could post results.

Data Sources and Control

City lists were compiled from:

Major shipping ports (World Ports Association rankings)
Tourism destination databases
US NOAA port directories

All checks were performed against the canonical .com TLD via Verisign's RDAP endpoint.

Key Decisions and Rationale

Why RDAP Over WHOIS?

At scale (100+ domains), WHOIS's per-IP throttling becomes a hard blocker. RDAP was designed to solve this via HTTP rate-limiting headers and distributed CDN-backed resolution. The tradeoff: WHOIS is more widely supported for legacy systems, but RDAP is the right choice for modern, scalable tooling.

Why Three Category Scripts?

Rather than a single monolithic script, we separated concerns:

check_queenof_domains.py for canonical port cities (core franchise concept)
check_queenof_dream.py for premium/aspirational variants
← All posts