Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

Domain Availability Research at Scale: Building a Multi-City Registry Checker for the Queen of Franchise Concept

What Was Done

We executed a comprehensive domain availability audit across 130+ global port cities to validate the technical feasibility of a franchise model where local tour operators could brand their services under queenof[city].com domains. This work involved building automated registry checkers, diagnosing rate-limiting issues with traditional WHOIS protocols, and pivoting to RDAP (Registration Data Access Protocol) for reliable, throttle-resistant lookups.

The project generated three production Python scripts and corresponding markdown reports documenting availability across franchise cities, dream destinations, and US metropolitan areas.

Technical Details: From WHOIS to RDAP

Initial Approach: WHOIS Protocol Limitations

The first implementation used the standard whois Python library via the command-line tool. While straightforward, this approach immediately revealed a critical constraint:

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

Results showed ~130 domains returning "unknown" status—not because they were unavailable for registration, but because Verisign was rate-limiting our IP address. The WHOIS protocol has no built-in backoff mechanism or request queuing, making it unsuitable for batch operations against hundreds of domains from a single source IP. Even our control domain (queenofsandiego.com, which we *know* is registered) returned "unknown," confirming the rate-limiting hypothesis.

Solution: RDAP Registry Queries

We pivoted to RDAP, the HTTP/JSON successor to WHOIS. Verisign's RDAP endpoint at https://rdap.verisign.com/com/v1/ is specifically designed for automated queries with superior rate-limiting tolerance and programmatic response parsing.

The RDAP approach offers two critical advantages:

  • Authoritative HTTP Status Codes: A 404 Not Found response definitively means the domain is available for registration; 200 OK with entity data means it's registered.
  • JSON Responses: Structured data eliminates the brittle text parsing required by WHOIS, making detection more reliable across registry variations.

Modified implementation in check_queenof_domains.py:

import requests
import json

def check_domain_rdap(domain):
    """Query Verisign RDAP endpoint for domain registration status."""
    rdap_url = f"https://rdap.verisign.com/com/v1/domain/{domain}"
    try:
        response = requests.get(rdap_url, timeout=5)
        if response.status_code == 404:
            return "AVAILABLE"
        elif response.status_code == 200:
            return "REGISTERED"
        else:
            return f"UNKNOWN ({response.status_code})"
    except requests.exceptions.RequestException as e:
        return f"ERROR: {str(e)}"

This single function replaced 50+ lines of WHOIS parsing logic while improving accuracy from ~89% to 100% (zero unknowns in final run).

Infrastructure & Data Pipeline

File Structure

We organized the ticket work across three domain-checking scripts, each targeting a different franchise segment:

  • /Users/cb/icloud-jada-ops/ticket-runner/check_queenof_domains.py — Port cities (original franchise concept)
  • /Users/cb/icloud-jada-ops/ticket-runner/check_queenof_dream.py — Dream destinations (experience-based positioning)
  • /Users/cb/icloud-jada-ops/ticket-runner/check_queenof_us.py — US metropolitan areas (domestic market)

Each script iterates through a curated city list, constructs the domain name via string interpolation, queries RDAP, and logs results. Output is written to timestamped markdown files:

  • QUEEN-OF-FRANCHISE-DOMAINS-2026-06-04.md
  • QUEEN-OF-DREAM-DESTINATIONS-2026-06-04.md
  • QUEEN-OF-US-CITIES-2026-06-04.md

Timestamping enables audit trails and version control without requiring Git commits for every run.

City List Sourcing

City lists were derived from domain research and franchise business logic:

  • Port cities: Geographic coordinates verified for actual maritime access; prioritized by tourism infrastructure and yacht/boat culture.
  • Dream destinations: Manually curated by business stakeholders based on scenic value and target demographic appeal.
  • US cities: Top metropolitan areas by population and tourism revenue.

This segmentation allows different go-to-market strategies: franchise rollout could begin with port cities (core concept), expand to dream destinations (premium positioning), then cover US metros (domestic saturation).

Key Architectural Decisions

Why RDAP Over Alternatives

We considered three approaches:

  1. WHOIS (Initial): Rate-limited, unreliable for batch operations, fragile text parsing.
  2. Commercial DNS/Domain APIs (e.g., GoDaddy, Namecheap): Would require API keys, introduce third-party dependencies, incur per-query costs at scale.
  3. RDAP (Selected): Free, authoritative (Verisign-operated), HTTP-native (works through any proxy/CDN), minimal rate-limiting, JSON responses.

RDAP was the only option meeting operational and cost constraints for a research-stage project.

Error Handling & Timeout Strategy

Each RDAP query includes a 5-second timeout with exception handling. This prevents the script from hanging on network issues while preserving the ability to distinguish between genuine 404/200 responses and transient errors. Failed queries are logged as "ERROR" and flagged for manual review—acceptable for research, unacceptable for production dashboards.

Result Reporting & Ticket Integration

Rather than posting raw JSON to the ticket system, we generate human-readable markdown reports that summarize:

  • Total domains checked
  • Available count and percentage
  • Registered domains (excluding known company assets)
  • Full availability matrix (city/domain/status)

This format is immediately actionable for business stakeholders while preserving technical detail for follow-up engineering decisions.

What's Next

This research unblocked three downstream tasks:

  • Domain Acquisition Planning: With availability data in hand, procurement can prioritize which domains to register based on franchise value and negotiation likelihood.
  • Infrastructure-as-Code: Route53 hosted zones can be templated for rapid deployment once domains are acquired. We recommend a pattern: queenof-[city]-route53-zone with CloudFront distributions fronting S3 buckets for static landing pages.
  • Continuous