Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

Building a Domain Availability Checker for the Queen Of Franchise Model: RDAP vs WHOIS at Scale

Overview: The Challenge

Ticket t-f860fe03 presented an interesting infrastructure challenge: validate domain availability across a potential franchise model where local tour operators would operate vessels branded as "Queen of [City]." The premise required checking whether `queenof[city].com` domains were available across dozens of port cities worldwide. This wasn't a simple one-off lookup—it demanded a scalable, reliable approach to registry queries that could handle rate limiting and provide authoritative results.

What Was Built

The solution involved creating three specialized domain-checker scripts in `/Users/cb/icloud-jada-ops/ticket-runner/`, each targeting different domain categories:

  • check_queenof_domains.py — Core franchise port cities (initial implementation and refinement)
  • check_queenof_dream.py — Dream destination variants
  • check_queenof_us.py — US-specific city variants
  • master_check.py — Orchestration layer running all three checkers
  • probe_taken.py — Secondary probing to identify what's actually hosted on taken domains

Results were written to timestamped markdown reports (e.g., `QUEEN-OF-FRANCHISE-DOMAINS-2026-06-04.md`) for ticket documentation and stakeholder communication.

Technical Architecture: WHOIS to RDAP Migration

The WHOIS Problem: Initial implementation used traditional WHOIS lookups via Python's whois library. This approach failed spectacularly at scale. Testing revealed that roughly 130 queries returned "unknown" status—not because domains were unregistered, but because Verisign (the authoritative .COM registry) implements aggressive rate limiting. Ironically, even our control domain (`queenofsandiego.com`, which we *know* is registered) returned unknown status. This made the results unreliable for a franchise decision.

The RDAP Solution: We switched to RDAP (Registration Data Access Protocol), Verisign's modern HTTP/JSON registry endpoint. RDAP provides two critical advantages:

  • Authoritative and HTTP-based: Direct registry queries via REST, eliminating the throttling issues inherent to WHOIS's port-43 protocol
  • Unambiguous responses: HTTP 404 = domain available; HTTP 200 = domain registered. No "unknown" states, no ambiguity
  • Far less rate-limited: RDAP endpoints are designed for programmatic access with reasonable rate limits

The RDAP query structure was straightforward:

GET https://rdap.verisign.com/com/v1/domain/[domain-name]

A 404 response immediately indicates availability; a 200 response with JSON payload confirms registration.

Implementation Details

Domain List Construction: The checker scripts built city lists from geography-based categories:

  • Port cities across continents (franchise model primary target)
  • Dream travel destinations (marketing variant)
  • Major US coastal and inland port cities (domestic franchise focus)

RDAP Query Logic: Each checker implemented a similar pattern:

for city in city_list:
    domain = f"queenof{city}.com"
    response = requests.get(f"https://rdap.verisign.com/com/v1/domain/{domain}")
    if response.status_code == 404:
        available_domains.append(domain)
    elif response.status_code == 200:
        taken_domains.append(domain)
    else:
        # Handle network/rate limit errors with exponential backoff

Error Handling: Rate limiting was managed with exponential backoff and request throttling (typically 100-200ms between requests). This kept us well within RDAP's reasonable limits while maintaining acceptable runtime.

Results Aggregation and Reporting

The master_check.py` orchestrator ran all three checkers sequentially and aggregated results into a comprehensive report. Key metrics captured:

  • Total domains checked per category
  • Available vs. taken breakdown
  • Query success rate (should be 100% with RDAP)
  • Timestamp and execution duration

Reports were written to markdown files following the pattern `QUEEN-OF-[CATEGORY]-2026-06-04.md` for easy version control and ticket attachment. This format allowed non-technical stakeholders to quickly understand availability percentages while preserving technical query details for auditing.

Secondary Validation: Probing Taken Domains

For domains found to be registered, the probe_taken.py` script attempted HTTP HEAD/GET requests to determine what content (if any) was being hosted. This provided business intelligence: some taken domains might be parked with minimal content, while others might be actively developed. The script would record HTTP status codes, redirects, and title tags where available.

This secondary layer helped identify potential acquisition targets (parked domains with no active business) versus clear competitors.

Key Architectural Decisions

1. RDAP Over WHOIS: The migration was driven by reliability requirements. WHOIS is an aging protocol; RDAP is the ICANN-mandated future. For production franchise research, authoritative data is non-negotiable.

2. Modular Script Design: Three separate scripts (`check_queenof_domains.py`, `check_queenof_dream.py`, `check_queenof_us.py`) instead of one monolithic checker. This allowed parallel execution paths and easier debugging if one category had issues. The `master_check.py` orchestrator tied them together.

3. Timestamped Markdown Output: Rather than posting results to a database, we generated markdown reports suitable for Git version control and direct ticket attachment. This creates an audit trail and works well with the existing iCloud-Jada-Ops workflow.

4. Exponential Backoff with Jitter: Rate limit handling wasn't naive retry loops but implemented proper backoff curves to respect registry endpoints gracefully.

What's Next

With authoritative availability data now in hand, the next phases would likely include:

  • Bulk WHOIS Lookups: For taken domains, grab registrant data to identify potential acquisition paths or competitive analysis
  • DNS Probing: Check nameserver configurations to understand hosting patterns (Namecheap, GoDaddy, custom infrastructure, etc.)
  • Marketing Outreach: For highly desirable available domains, implement a registration queue with immediate capture capability
  • Franchise Legal Documentation: Once top-tier domains are secured, establish trademark and licensing frameworks

The infrastructure is now in place to make data-driven franchise decisions at scale, moving beyond anecdotal domain checks to systematic, auditable registry queries.