WHOIS vs RDAP: how domain expiration tracking actually works

Why you should care

Domain expirations are the single most preventable outage. Registrars try to remind you, but their emails go to whichever inbox was active when the domain was registered — often a developer who left two years ago. By the time the actual outage happens, the registrar’s “grace period” is closing and the domain is at risk of being released.

Continuous expiration monitoring is the cheap insurance every domain needs. To do it, you need a reliable way to look up registration data. That’s where WHOIS and RDAP come in — and where the seemingly simple problem gets messy.

WHOIS: the original

WHOIS is from 1982. It’s a tiny TCP protocol on port 43: send a domain name, get back a text blob. The format of the blob is not standardized — every registrar and every TLD operator returns it slightly differently. Parsing it requires per-TLD heuristics.

$ whois example.com
   Domain Name: EXAMPLE.COM
   Registry Domain ID: 2336799_DOMAIN_COM-VRSN
   Registrar WHOIS Server: whois.iana.org
   ...
   Registry Expiry Date: 2027-08-13T04:00:00Z
   ...

Problems with WHOIS:

• No schema. “Registry Expiry Date” on one registrar is “Expiration Date” on another, “expires:” on a third.
• Rate limits. Most TLD WHOIS servers limit queries hard — sometimes 1 query per IP per minute. Polling hundreds of domains hourly from a single IP gets you blocked within minutes.
• GDPR redaction. Since 2018, contact details for European registrants are redacted to placeholder values. The registration dates are still there, but ownership info is gone.
• No structured access. You’re parsing free text. Every TLD update can break your parser silently.

WHOIS still works, and for some TLDs it’s still the only option. But it’s a fragile foundation for monitoring at scale.

RDAP: the structured successor

RDAP — Registration Data Access Protocol — is the modern replacement. It’s HTTPS-based, returns JSON, has a standardized schema (RFC 9083), and supports rate-limit headers and authentication.

$ curl https://rdap.verisign.com/com/v1/domain/example.com
{
  "objectClassName": "domain",
  "ldhName": "example.com",
  "events": [
    { "eventAction": "registration", "eventDate": "1995-08-14T04:00:00Z" },
    { "eventAction": "expiration",   "eventDate": "2027-08-13T04:00:00Z" },
    { "eventAction": "last changed", "eventDate": "2025-08-14T07:01:34Z" }
  ],
  "status": ["client delete prohibited", "client transfer prohibited"],
  ...
}

Every TLD operator is mandated by ICANN to provide RDAP. Coverage today is excellent for .com / .net / most generic TLDs and reasonably good for ccTLDs.

Why RDAP wins for automation:

• Structured JSON. events[].eventDate is always the same shape. One parser, all TLDs.
• Better rate limits. HTTP headers and bootstrap endpoints make polite polling easier.
• HTTPS. Authenticatable, observable, sane.
• Future-proof. New fields are added in a structured way without breaking existing parsers.

When you still need WHOIS

Despite RDAP being mandatory, you’ll hit edge cases:

• Some ccTLDs (.uk, .de, .ru, several smaller registries) have partial or absent RDAP. WHOIS is the only source.
• Older registrar-specific data shows up in WHOIS but not RDAP for some TLDs.
• WHOIS sometimes returns a useful “last-updated” timestamp that RDAP omits.

Production monitoring tools (DNSCheckPro included) try RDAP first and fall back to WHOIS for anything RDAP doesn’t cover.

The trap: caching and bulk polling

If you write your own monitor, the trap is bulk polling. Suppose you have 500 domains and you check each one daily. Naively: 500 lookups per day, distributed evenly. Fine.

Suppose you check each one hourly because some of them are critical. 12,000 lookups per day. Now you’re getting rate-limited, blacklisted, or temporarily banned by individual TLD operators. The fix is:

• Rate-aware scheduling. Different TLDs have different limits. Schedule per-TLD, not globally.
• Caching with backoff. Registration data doesn’t change minute-to-minute. Cache aggressively. Re-poll once daily for fresh data; re-poll within minutes only when you have a reason (e.g., the domain just hit its expiration date).
• Distributed query sources. Lookups from multiple egress IPs avoid single-IP rate caps.
• RDAP-first. It has better rate-limit headers and clearer protocols for being polite.

This is exactly why DNSCheckPro exists. We’ve already built the polite-polling infrastructure, the per-TLD cache logic, the parser fallbacks, and the alert escalation. You add a domain; we worry about whether .de is throttling us today.

The alerts that actually save you

A good expiration alert system fires at least these intervals:

• 90 days out — book the renewal in your registrar’s auto-renew if you haven’t.
• 60 days out — last cheap moment to transfer registrars without timing pressure.
• 30 days out — payment-method verification time. Did the credit card on file expire?
• 14 days out — yellow alarm. Should already be resolved.
• 7 days out — red alarm. Someone is getting paged.
• 1 day out — emergency. Wake people up.

Send each alert via multiple channels (email + Slack + SMS) once you cross 30 days. Single-channel reminders are how domains die.

In summary

WHOIS is the legacy text protocol; RDAP is the JSON-over-HTTPS successor. For monitoring at any scale, prefer RDAP — but expect to fall back to WHOIS for some TLDs. The hard part isn’t getting one value once; it’s polling thousands of domains politely, parsing varied formats reliably, and alerting at the right cadences via the right channels. That’s the work DNSCheckPro does for you.

Keep reading: DNS records explained covers what we monitor inside the zone; DNSSEC basics covers cryptographic verification.