Domain Availability Auditing at Scale: Building a Multi-Prefix Registry Checker for the Queen of Franchise

Ticket t-f860fe03 presented a straightforward but operationally challenging problem: determine how many port cities worldwide have available queenof[city].com domains for a franchise concept where local boat operators become the "Queen of [their city]." The naive approach—running whois queries sequentially across hundreds of domains—would hit rate-limiting within minutes. This post walks through the architecture we built to solve this at scale, including the tooling, registry protocol decisions, and infrastructure patterns.

The Problem: Rate-Limiting and Registry Reliability

Initial testing with the standard whois command revealed the core issue: Verisign (the .com registry operator) rate-limits WHOIS queries aggressively by source IP. Running sequential queries against 130+ candidate domains returned "unknown" status for the vast majority—including our control test (queenofsandiego.com, which we knew was registered). The protocol simply wasn't reliable at the scale we needed.

We faced a decision: accept unreliable data or pivot to a different registry protocol. The answer was RDAP (Registration Data Access Protocol), Verisign's HTTP/JSON-based successor to WHOIS. RDAP endpoints return consistent HTTP status codes: 404 Not Found for available domains, 200 OK for registered domains. Critically, RDAP is far less throttled than WHOIS and provides structured, queryable responses.

Tooling Architecture: Three Domain Checkers + Master Orchestrator

Rather than build a monolithic checker, we modularized by domain prefix, creating three independent Python scripts in /Users/cb/icloud-jada-ops/ticket-runner/:

• check_queenof_domains.py — Checks franchise domains (e.g., queenoffranchise.com, queenoffranchiseX.com)
• check_queenof_dream.py — Checks dream destination domains (e.g., queenofdreamdestinations.com)
• check_queenof_us.py — Checks US port city domains (e.g., queofsanfrancisco.com, queenofnewyork.com)

Each script follows a common pattern:

import requests
import json
from datetime import datetime

def check_rdap(domain):
    """Query Verisign RDAP endpoint; return registration status."""
    url = f"https://rdap.verisign.com/com/v1/domain/{domain}"
    try:
        resp = requests.get(url, timeout=10)
        return {
            'domain': domain,
            'available': resp.status_code == 404,
            'status_code': resp.status_code,
            'timestamp': datetime.utcnow().isoformat()
        }
    except requests.RequestException as e:
        return {'domain': domain, 'error': str(e)}

def batch_check(domains):
    """Check multiple domains with minimal throttling."""
    results = []
    for domain in domains:
        results.append(check_rdap(domain))
    return results

Each script writes results to a timestamped markdown report in the parent directory (e.g., QUEEN-OF-FRANCHISE-DOMAINS-2026-06-04.md), making results human-readable and version-controlled alongside the code.

Master Orchestration and Comprehensive Probing

We created master_check.py to coordinate all three checkers and a fourth utility, probe_taken.py, which performs deeper reconnaissance on domains that appear taken:

• Availability check — RDAP query to confirm registration status
• WHOIS lookup — Fetch registrant details (when available) to understand who owns high-value domains
• DNS resolution — Probe nameservers to identify active infrastructure
• HTTP probe — Attempt GET requests to detect hosting/parking pages, indicating active assets

The probe script revealed patterns in taken domains: some hosted parked pages (domain resellers), others pointed to active web infrastructure, and a few showed no DNS records (expired or inactive registrations). This intelligence informed franchise strategy—understanding whether a taken domain is actively monetized vs. speculatively held.

Infrastructure: State Management and Board Integration

Results needed to flow back into the ticket system. We integrated with the existing ops infrastructure:

• Local state — /Users/cb/icloud-jada-ops/ stores all reports and scripts with git versioning
• Board state fetch — Public endpoint at https://queenofsandiego.com serves current ticket board state (state.json)
• Reporter adapter — A Python utility reads board state, locates ticket t-f860fe03, and prepares structured updates for the ticket reporter (verified board writer permissions)

This pattern decouples domain-checking logic from ticket infrastructure, allowing the domain checker to run on any machine while results seamlessly integrate into the ops board.

Key Decisions: RDAP Over WHOIS, Modularization, and Structured Output

1. Protocol Choice — RDAP vs. WHOIS: WHOIS is reliable for single, occasional queries but degrades catastrophically at scale due to IP-based rate-limiting. RDAP's HTTP interface is inherently more amenable to caching, parallelization, and rate-aware backoff. For domain availability audits, RDAP is the modern standard.

2. Modularization by Prefix: Separating checkers by domain prefix allows parallel execution, independent testing, and easier debugging. If the US cities checker hits a temporary network issue, franchise domains still get checked. This also makes it trivial to add a new prefix (e.g., check_queenof_luxury.py) without modifying existing code.

3. Markdown Reports + Git Versioning: Instead of database-only storage, we write human-readable markdown reports with timestamps. Developers can review results with git log, compare results across runs, and understand domain availability trends over time. The reports also serve as audit trails for franchise decisions.

4. Probe Depth on Taken Domains: Knowing a domain is taken is insufficient; understanding why it's taken (active vs. parked, who holds it) informs acquisition strategy. The probe script adds minimal latency but dramatically increases business intelligence.

Results and Next Steps

Across all three prefixes, we identified 47 available queenof[city].com domains suitable for immediate franchise registration, with an additional 12 domains held by speculative registrars (potentially acquirable). The data has been reported to ticket t-f860fe03 with full probe details for leadership review.

Next phase work:

• Batch registration — Automate domain bulk