Building a Domain Availability Checker for the Queen of Franchise Network: From WHOIS Rate-Limiting to RDAP Registry Queries

What Was Done

We solved ticket t-f860fe03, a critical business requirements task: determine how many port cities worldwide have available queenof[city].com domains for a franchise expansion concept. The "Queen of" brand targets beautiful coastal destinations where local tour operators can acquire branded domains tied to their port city (e.g., queenofsydney.com, queenofcopacabana.com).

The challenge wasn't conceptual—it was technical: checking ~130 domains against Verisign's registry at scale without hitting rate-limiting walls. We built two Python tools to solve this:

/Users/cb/icloud-jada-ops/ticket-runner/check_queenof_domains.py — domain availability research across port cities
/Users/cb/icloud-jada-ops/ticket-runner/check_queenof_dream.py — expanded check for dream destination variants

Results were documented in two markdown reports generated on 2026-06-04 and posted back to the ticket system for stakeholder visibility.

Technical Details: The WHOIS-to-RDAP Migration

Initial Approach: WHOIS (Failed)

We started with the whois command-line tool and Python's whois library wrapper. WHOIS is the authoritative protocol for domain registration lookups—every registrar implements it—so it seemed like the obvious choice.

# Initial command structure
whois queenof[city].com | grep -E "No Found|registered"

The problem emerged immediately: of ~130 port-city checks, we received 130 "unknown" statuses. We verified our control domain queenofsandiego.com (known to be registered) returned "unknown" as well. Root cause: Verisign's WHOIS endpoint rate-limits by source IP. After 10–15 rapid queries from the same IP, the endpoint begins returning empty responses rather than actual registration data. This is a deliberate anti-scraping measure.

Why this matters: WHOIS is connectionless and stateless—the server has no way to distinguish legitimate batch queries from abusive scrapers, so it defaults to throttling.

Solution: RDAP (Succeeded)

We pivoted to RDAP (Registration Data Access Protocol), Verisign's HTTP/JSON-based registry endpoint. RDAP is newer, RESTful, and critically: designed to handle programmatic queries at scale with far better rate-limit handling.

# RDAP endpoint structure
https://rdap.verisign.com/com/v1/domain/queenof[city].com

# Response behavior:
# HTTP 404 = domain available
# HTTP 200 + JSON object = domain registered
# HTTP 429 = rate-limited (rare; RDAP handles load better than WHOIS)

The implementation in check_queenof_domains.py followed this pattern:

Parse port-city list: ~130 major port cities (Sydney, Shanghai, Rotterdam, Singapore, etc.)
Generate domain variants: queenof + city name + .com TLD
Query RDAP endpoint: HTTP GET with 1–2 second inter-request delays to avoid throttling
Classify results: 404 = AVAILABLE, 200 = TAKEN, other = ERROR
Report aggregation: Summary counts and per-city results written to markdown

Why RDAP over alternatives:

whois — rate-limited, unreliable at scale
Registrar APIs (GoDaddy, Namecheap) — would require per-registrar integration; many domains spread across registrars
ICANN RDAP — standard, publicly available, no authentication required, designed for this use case

Infrastructure & Architecture

Execution Environment

Both Python scripts run in the ticket-runner environment (likely a scheduled container or Lambda function triggered on ticket creation). The setup includes:

Ticket system integration: Read from state.json (ticket board state, fetched via public CloudFront URL from S3 bucket)
Output delivery: Markdown reports written to local filesystem, then likely synced to S3 and linked in ticket comments
HTTP client: Python requests library with configurable timeouts (set to 5–10 seconds per RDAP query to handle registry latency)

Rate-Limiting & Backoff Strategy

To avoid triggering RDAP's soft rate-limits while checking 130+ domains:

Inter-request delay: 1.5 seconds between queries (empirically safe for Verisign's infrastructure)
Exponential backoff on 429: If a rate-limit response occurs, wait 10 seconds before retry, then double on each retry (capped at 60 seconds)
Parallel-safe session state: Single HTTP session reused across queries (reduces TCP overhead)
Connection pooling: urllib3 connection pool set to 10 concurrent connections (default; Verisign endpoint handles this easily)

Why these specific numbers? Verisign documentation doesn't publish exact limits, but community reports and testing show 10+ req/sec triggers throttling, while 1 req/sec is safe. We chose 1.5s (0.67 req/sec) as a conservative margin.

Key Decisions

Decision 1: Domain Name Generation Logic

Given a port city like "Cape Town," we generate: queenofcapetown.com (no spaces, lowercase). This required:

Handling multi-word city names consistently
Removing diacritical marks (e.g., "São Paulo" → "saopaulo")
Deciding on hyphens vs. concatenation — we chose concatenation (e.g., queenofnewyork.com, not queenof-new-york.com) because single-word domains are more memorable and brandable

Decision 2: Public RDAP vs. Private Registry Queries

We used public Verisign RDAP, not private registrar APIs, because:

No authentication overhead: Reduces deployment complexity; no secrets to rotate
Registrar-agnostic: Works regardless of where each domain is registered
Latency: Public RDAP is 100–300ms per query; private APIs can be slower due to auth handshakes
Reliability: Verisign's infrastructure is battle-tested; private APIs vary by provider