Domain Expiry Monitoring: RDAP vs WHOIS Explained

Losing a domain to accidental expiry is one of the most avoidable, and most damaging, incidents in operations. It takes down every service tied to that name simultaneously - website, email, API endpoints, SSL certificates - and recovery can take days or be permanently impossible if someone else registers it first. This article explains how domain expiry data is actually retrieved, the practical differences between WHOIS and RDAP, and the registry-specific quirks that trip up naive monitoring scripts.

WHOIS: The Legacy Protocol

WHOIS has been the standard way to query domain registration data since the 1980s. It's a plain-text protocol over TCP port 43:

whois example.com

Or manually over raw TCP:

echo -e "example.com\r\n" | nc whois.verisign-grs.com 43

Problems with WHOIS as a monitoring data source:

• No standardized output format. Every registry and registrar formats its response differently. Parsing "Registry Expiry Date" from Verisign differs from "Expiration Date" or "paid-till" fields used by other registries.
• Rate limiting is inconsistent and undocumented. Aggressive polling can get your IP blocked with no clear error message.
• Some registries return no expiry field at all, especially for privacy-protected or thin registries.
• Text-based parsing is fragile. A registry can change its output format at any time without notice, silently breaking regex-based extraction.

RDAP: The Structured Replacement

RDAP (Registration Data Access Protocol) was designed specifically to fix WHOIS's shortcomings. It runs over HTTPS and returns structured JSON:

curl -s https://rdap.verisign.com/com/v1/domain/example.com | jq '.events'

A typical response includes an events array with clearly labeled eventAction types:

{
  "events": [
    { "eventAction": "registration", "eventDate": "2010-01-15T00:00:00Z" },
    { "eventAction": "expiration", "eventDate": "2025-01-15T00:00:00Z" },
    { "eventAction": "last changed", "eventDate": "2024-06-02T10:11:00Z" }
  ]
}

Extracting the expiration date programmatically becomes trivial:

curl -s https://rdap.verisign.com/com/v1/domain/example.com \
  | jq -r '.events[] | select(.eventAction=="expiration") | .eventDate'

RDAP vs WHOIS at a Glance

RDAP is clearly the better foundation for automated monitoring, but it isn't universal yet - some ccTLDs still only support WHOIS, so production-grade monitoring tools need to support both and fall back gracefully.

Finding the Right RDAP Server

Use IANA's bootstrap registry to find the correct RDAP base URL for any TLD without hardcoding a list:

curl -s https://data.iana.org/rdap/dns.json | jq '.services[] | select(.[0][] == "com")'

This returns the RDAP server responsible for .com, which you then query directly as shown above.

ccTLD Quirks, Including .rs

Country-code TLDs frequently deviate from the gTLD norm, and monitoring scripts need to account for this:

• .rs (Serbia): RNIDS, the Serbian registry, has historically had partial or delayed RDAP support and WHOIS output that differs structurally from generic TLD registries. Always test actual output rather than assuming compatibility.
• .de (Germany): DENIC's WHOIS output intentionally omits the expiration date for privacy reasons in many queries, meaning expiry tracking may need to come from your registrar account rather than public WHOIS/RDAP.
• .uk: Nominet provides RDAP, but registrant-visible fields differ from gTLD conventions, and renewal status terminology varies.
• .io, .ai, and other repurposed ccTLDs: Often run by third-party commercial registry operators with their own RDAP/WHOIS quirks distinct from the "true" country registry norms.

The practical takeaway: don't assume a single parser works across all TLDs. Build monitoring that handles missing fields gracefully and flags "unable to determine expiry" as its own alert state rather than silently treating it as "fine."

Registrar Lock and What It Actually Protects

Registrar lock (clientTransferProhibited status) prevents unauthorized transfers away from your registrar, but it does not prevent expiry. A locked domain still expires on schedule if auto-renewal fails or a payment method is declined.

Check current domain status codes via RDAP:

curl -s https://rdap.verisign.com/com/v1/domain/example.com | jq '.status'

Look for:

• clientTransferProhibited - transfer lock is active (good, prevents hijacking)
• clientHold - the domain is not resolving, usually due to a registrar or registry action
• pendingDelete - the domain has passed through redemption and is about to be released
• redemptionPeriod - the domain has expired and is in the redemption window

Grace and Redemption Periods

Most gTLDs follow a standard post-expiry lifecycle:

1. Auto-renew grace period (0–45 days): The domain has expired but is typically still resolving. The registrant can renew at the normal price.
2. Redemption grace period (RGP, ~30 days): The domain stops resolving entirely. Renewal is possible but usually requires paying a steep redemption fee to the registrar, sometimes $80–$300+.
3. Pending delete (~5 days): The domain is locked from any action and about to be released back into the available pool.
4. Release: The domain becomes available for anyone to register.

This means the moment your service actually goes down (start of RGP) can be weeks after the technical expiration date. Don't rely on "it's still working" as evidence a domain is safe - check the actual expiry date, not just current resolution status.

Auto-Renew Failure Modes

Auto-renewal is not a guarantee. Common ways it silently fails:

• Expired or declined credit card on file with the registrar
• Registrar account email bouncing, so renewal failure notices never arrive
• Domain moved between registrar accounts without auto-renew being re-enabled
• ICANN-mandated WHOIS/RDAP contact verification email going unanswered, leading to suspension
• Manual renewal disabled by mistake when consolidating a domain portfolio

Building a Monitoring Checklist

• Query RDAP first, fall back to WHOIS for unsupported TLDs
• Alert at multiple thresholds: 30, 14, and 3 days before expiry
• Explicitly alert when expiry data is unavailable rather than assuming it's fine
• Check domain status codes for redemptionPeriod or pendingDelete as critical-severity alerts
• Cross-reference with your registrar's billing/payment status, not just public records

Domain expiration monitoring from an independent third party catches the case where your own registrar's renewal notification email is the thing that fails - you get an alert regardless of whether the registrar's systems are working correctly.

FAQ

Is RDAP replacing WHOIS entirely?

ICANN has mandated RDAP support for gTLD registries and registrars, and it's steadily becoming the primary protocol. However, WHOIS remains in use for many ccTLDs and as a fallback, so both protocols are relevant for the foreseeable future.

Does registrar lock prevent domain expiry?

No. Registrar lock only prevents unauthorized transfers to another registrar. It has no effect on the renewal/expiry lifecycle - an expired locked domain still enters grace and redemption periods normally.

Why did my domain stop resolving before its listed expiration date?

Some registrars place domains on hold slightly before or at the technical expiry moment, and DNS propagation of the hold can lag. Always monitor with buffer thresholds well before the actual expiry date.

Can I recover a domain after it's fully released?

No. Once a domain passes pending delete and is released, it becomes available to any registrant on a first-come basis. Recovery at that point requires trying to re-register it or negotiating with whoever acquires it.

Why does WHOIS for some ccTLDs not show an expiration date at all?

Some registries, particularly in jurisdictions with strict privacy regulations, deliberately omit expiry data from public WHOIS output. In those cases, monitoring must rely on registrar account data or accept that public expiry tracking isn't fully reliable for that TLD.