Solving Domain Availability at Scale: Building a Reliable Registry Checker for the Queen Of Franchise Model
The Problem: Validating 150+ Domain Names Against Live Registry Data
Ticket t-f860fe03 presented a deceptively simple requirement: determine how many domains matching the pattern queenof[city].com are available for registration across global port cities. The business model behind this was elegant — a franchise concept where local tour operators could operate under a branded "Queen of [City]" identity with corresponding domain ownership. However, the technical execution required solving several non-trivial infrastructure and data-quality challenges.
The core issue wasn't just building a domain checker; it was building one that could produce authoritative results at scale without getting rate-limited or blocked by registry operators.
Technical Architecture: From WHOIS to RDAP
Initial Approach: WHOIS Protocol
Our first implementation in /Users/cb/icloud-jada-ops/ticket-runner/check_queenof_domains.py used the standard WHOIS protocol. This is the traditional method for domain availability checking and was already available in our development environment.
#!/usr/bin/env python3
# check_queenof_domains.py - Initial WHOIS-based approach
import whois
import csv
from datetime import datetime
PORT_CITIES = [
"sandiego", "seattle", "portland", "losangeles",
"sanfrancisco", "oakland", "longbeach", "ventura",
# ... 140+ additional cities
]
def check_domain_whois(domain):
"""Query WHOIS registry for domain registration status"""
try:
result = whois.whois(domain)
return "TAKEN" if result.creation_date else "AVAILABLE"
except whois.parser.PywhoisError:
return "AVAILABLE" # Assumption: if whois fails, domain is available
except Exception as e:
return "UNKNOWN" # Rate limit or network error
# Test control domain
control = check_domain_whois("queenofsandiego.com")
# Expected: TAKEN (we know this domain exists)
The WHOIS implementation worked initially, but quickly revealed a critical flaw: Verisign rate-limiting. When checking 130 consecutive domains, the registry operator would throttle our requests, returning empty responses. Even worse, our control domain (queenofsandiego.com, which we knew was registered) came back as "UNKNOWN," invalidating our entire dataset.
The Solution: RDAP Registry Protocol
WHOIS is a legacy protocol with inherent limitations. RDAP (Registration Data Access Protocol) is its modern successor — HTTP/JSON-based, RESTful, and specifically designed for programmatic access. Most importantly, Verisign's RDAP endpoint has significantly higher rate limits and more predictable behavior.
We rewrote the core checker using RDAP:
#!/usr/bin/env python3
# check_queenof_domains.py - RDAP-based approach
import requests
import time
from typing import Literal
from collections import defaultdict
RDAP_BASE_URL = "https://rdap.verisign.com/com/v1/domain/"
def check_domain_rdap(domain: str) -> Literal["AVAILABLE", "TAKEN", "ERROR"]:
"""
Query Verisign RDAP endpoint for domain status.
RDAP returns:
- 200 + JSON object: domain is REGISTERED
- 404: domain is AVAILABLE
- 5xx/timeout: temporary error, retry
"""
try:
url = f"{RDAP_BASE_URL}{domain}.com"
response = requests.get(url, timeout=10)
if response.status_code == 404:
return "AVAILABLE"
elif response.status_code == 200:
return "TAKEN"
else:
return "ERROR"
except requests.exceptions.Timeout:
return "ERROR"
except Exception as e:
print(f"Exception checking {domain}: {e}")
return "ERROR"
def batch_check_domains(cities: list, delay_ms: int = 500) -> dict:
"""
Check multiple domains with rate-limiting.
Args:
cities: list of city names (e.g., ["sandiego", "seattle"])
delay_ms: milliseconds between requests (500ms = ~7200 req/hour)
Returns:
dict with counts by status and list of available domains
"""
results = defaultdict(list)
for city in cities:
domain = f"queenof{city}"
status = check_domain_rdap(domain)
results[status].append(domain)
time.sleep(delay_ms / 1000.0)
return dict(results)
# Test with control domain
control_result = check_domain_rdap("queenofsandiego")
# Expected: "TAKEN"
Data Collection: Building the Port-City Inventory
Beyond the protocol change, we needed a comprehensive, accurate list of global port cities. We compiled ~150 port cities across all continents with meaningful tourism potential. This data was sourced from:
- World Tourism Organization port-of-call databases
- International cruise industry port rankings
- Regional port authority records
The cities were stored in structured format within the Python script and later exported as markdown:
# Data structure in check_queenof_domains.py
PORT_CITIES_BY_REGION = {
"north_america": [
"sandiego", "seattle", "portland", "losangeles",
"sanfrancisco", "oakland", "longbeach", "ventura",
"newyork", "boston", "miami", "neworleans",
# ... more
],
"europe": [
"barcelona", "amsterdam", "hamburg", "marseille",
# ... more
],
"asia_pacific": [
"singapore", "hongkong", "sydney", "auckland",
# ... more
]
}
Infrastructure & Execution Environment
The scripts executed within our ticket-runner environment at /Users/cb/icloud-jada-ops/ticket-runner/, which has:
- Network access: Outbound HTTPS to Verisign RDAP endpoints (port 443)
- Python runtime: Python 3.8+ with
requestslibrary for HTTP queries - Local storage: Results written to markdown files in the parent directory (
/Users/cb/icloud-jada-ops/) - Rate limiting: 500ms inter-request delay to respect registry operators' ToS and maintain good standing
Output Artifacts
We generated two primary deliverables:
QUEEN-OF-FRANCHISE-DOMAINS-2026-06-04.md— Comprehensive domain availability report with counts by region and statusQUEEN-OF-DREAM-DESTINATIONS-2026-06-04.md— Curated list of highest-potential port cities (available domains + tourism appeal)
These files are structured as markdown tables for easy consumption by business stakeholders and include metadata (timestamp, methodology notes, RDAP endpoint version).