RDAP vs WHOIS for domain expiration dates

Choosing rdap vs whois expiration data is not nostalgia—it is whether your automation survives GDPR redaction, HTML layout changes, and registry throttling when renewal season hits.

DNS administrators and procurement analysts still inherit scripts that open port 43 and grep for Registry Expiry Date. Those scripts worked until rate limits, partial responses, and privacy masking stripped the fields monitoring depended on.

RDAP answers with JSON over HTTPS, explicit status arrays, and event objects aligned with registry policy. WHOIS remains useful for quick human lookups on some ccTLDs but is a poor foundation for rdap vs whois expiration automation at scale.

This cluster hub explains when each protocol still matters, how to read expiration events, and how domain monitoring products should behave when neither source is complete.

What this guide covers

You will compare transport, schema, rate limits, and data quality for registration expiry—not TLS notAfter. TLS remains the domain of live handshake monitors and OpenSSL spot checks.

Legal and compliance teams sometimes mandate WHOIS receipts for audits while engineering prefers RDAP in CI. This guide helps both sides map the same underlying entitlement without duplicating contradictory dates in the CMDB.

MSP engineers onboarding transferred client domains should re-query RDAP after every transfer because registrar expiration events change shape across backends.

Key concepts

WHOIS (port 43) returns unstructured or semi-structured text. Parsers break when registries adjust field labels or when thick vs thin models expose different data. Automated bulk queries often violate acceptable use.

RDAP uses HTTPS, content negotiation for application/rdap+json, and objects with events[] entries. Common actions include registration, last changed, expiration, and sometimes registrar expiration.

Bootstrap routing via IANA JSON maps TLDs to authoritative servers. Redirect services help humans; production should cache authoritative bases per suffix.

Redaction affects both systems but manifests differently. WHOIS may omit fields entirely; RDAP may return roles without contact handles while still publishing expiration events—unless the registry withholds them.

rdap vs whois expiration debates should end with one rule: prefer RDAP where the registry publishes complete domain objects, document fallbacks where they do not, and never scrape HTML registrar portals as if it were a protocol.

Procurement should ask SaaS vendors whether registration dates come from RDAP, scraped WHOIS, or manual entry. If the answer is unclear, assume staleness until they demonstrate structured JSON with status codes and explicit unknown handling in a live demo during evaluation.

How to work through your portfolio

Inventory every TLD you operate and note the lookup path: RDAP authoritative, RDAP partial, WHOIS fallback, or registrar API only.

Side-by-side probe for comparison during migration:

DOM=example.com
curl -s -H "Accept: application/rdap+json" "https://rdap.org/domain/${DOM}" \
  | jq '.events[] | select(.eventAction | test("expir"; "i")) | {action: .eventAction, date: .eventDate}'

WHOIS (where permitted):

whois "${DOM}" | grep -iE 'expir|paid-till|registry expiry'

When outputs disagree, treat RDAP event dates as automation input unless your legal team standardizes on registrar portal exports. Log disagreements for finance reconciliation, not for silent overwrites.

Mark domains where both queries lack expiration. Schedule quarterly manual verification and keep TLS monitoring on customer hostnames independent of registration parsing success.

During TLD migrations (for example rebranding from a legacy ccTLD), rebuild scripts to use new bootstrap entries before decommissioning WHOIS parsers that hard-coded old field names.

Archive sample RDAP JSON per TLD in your internal wiki when legal asks for audit evidence—screenshots of WHOIS text are weaker than stored JSON with timestamps. Train new hires on the rdap vs whois expiration policy during onboarding so shadow spreadsheets do not reintroduce port-43 greps for “just this one urgent domain.” If a vendor still ships WHOIS-only connectors, require a roadmap date for RDAP or registrar API support before contract signature.

Related guides in this silo

RDAP depth

• RDAP lookup for domain expiration — step-by-step event extraction.
• Domain registration expiry monitoring (RDAP era) — pillar strategy.

WHOIS transition

• WHOIS expiration date alternatives — APIs and portals when JSON fails.
• Live certificate check vs registrar WHOIS — separating TLS from registration queries.

Operations and tools

• Check domain registration expiry — manual verification playbook.
• RDAP domain expiry monitoring tool — scheduled lookup products.
• Domain and SSL expiry monitoring in one place — unified alerting.

When to use automation

Parsing WHOIS in cron jobs creates on-call debt every time a registry reformats a paragraph. rdap vs whois expiration strategy should centralize on RDAP with explicit unknown states.

ssldays uses RDAP for registrar expiry where registries publish it and always performs live TLS checks on configured hostnames. Alerts at 30, 14, 7, and 1 days fire once per threshold per cycle. Free tier includes 3 domains with daily checks; Starter offers 25 with hourly TLS polling and Slack and Discord webhooks; Pro supports 100 domains.

Use /check to validate TLS while RDAP integration catches registration drift. Retire brittle WHOIS greps as you confirm RDAP coverage per TLD in the portfolio spreadsheet.