RDAP Replaces WHOIS: Monitor Domain Data Safely

From WHOIS to RDAP: what changed technically

WHOIS emerged in the early days of the internet as a plain query service over port 43: you send a domain name and get back a block of free text. The format was never strictly standardized - every registry and registrar formatted the answer a little differently, sometimes with a field called “Registry Expiry Date”, sometimes “paid-till”, sometimes “Expiration Date”. Readable for humans, but a constant guessing game for machines. That is exactly where RDAP steps in.

RDAP delivers the same information through a modern, clearly defined interface: queries run as an HTTPS request following a uniform pattern (RFC 9082), the response is structured JSON with firmly named fields (RFC 9083), and which server is responsible for which TLD is listed in a central bootstrap file maintained by IANA (RFC 9224). That lets you read expiry date, status, nameservers and contact references unambiguously, without parsing free text. RDAP also supports internationalization, encrypted access and - unlike the open WHOIS - tiered access rights to sensitive data (ICANN).

# RDAP: HTTPS query per RFC 9082 instead of WHOIS over port 43
curl -s https://<rdap-base-url>/domain/your-domain.example

# Structured response (excerpt, RFC 9083):
# "status": ["clientTransferProhibited"]
# "events": [{ "eventAction": "expiration", "eventDate": "2027-03-14T09:00:00Z" }]
# "nameservers": ["NS1.EXAMPLE.NET", "NS2.EXAMPLE.NET"]
# "secureDNS": { "delegationSigned": true }

The cut-off of 28 January 2025 - and the three exceptions

The shutdown did not come overnight: it marked the end of an 18-month transition period following a contract amendment by ICANN (ICANN). Since 28 January 2025, gTLD registries and registrars are no longer required to offer WHOIS over port 43 or the web - RDAP is mandatory in its place (ICANN). Three endings form an explicit exception and may keep running WHOIS: .com, .name and .post (ICANN). For the overwhelming majority of generic and new TLDs, however, whoever still queries WHOIS there relies on a service the operator is allowed to switch off - and in many cases already has.

Registries made quick use of that right. As early as February 2025, according to an ICANN reachability scan, 74 gTLD registries had shut down their WHOIS service (ICANN); by September 2025, data from the TLD RDAP Monitor showed 374 gTLDs no longer offering WHOIS (TLD RDAP Monitor). An expiry check that stubbornly hits port 43 gets either an error at those TLDs or - worse - a stale answer from a cache. Anyone who wants to be sure a domain does not expire unnoticed can no longer rely on that source.

The gap: RDAP coverage is only around 77 percent

As clear as the direction is, the transition is unfinished. Across all top-level domains, RDAP coverage stood at around 77% in September 2025, up from 74.8% in February 2025 (TLD RDAP Monitor). The average, though, hides a wide spread: for generic TLDs the switch is practically complete, because ICANN's rules apply there. For country-code endings (ccTLDs), by contrast, only 34.2% offered RDAP in September 2025 - up from 29.4% in February (TLD RDAP Monitor). ccTLDs such as .de, .fr or .it are not bound by ICANN contracts and decide their own timeline.

The TLD RDAP Monitor, which tracks the switch across more than 1,400 endings (WhoisXML API), makes the core problem visible: a tool that wants to monitor a domain cannot assume that either WHOIS or RDAP works everywhere. It needs both paths - RDAP first, WHOIS only as a fallback for the endings that have not yet made the switch. Exactly this dual strategy separates future-proof monitoring from a tool that hangs on a single, partly disabled source.

Why WHOIS-based expiry checks return wrong data

A domain expiry that nobody notices is one of the most expensive yet most avoidable incidents in running a website. When a domain lapses, website and email go offline in an instant - and recovery can be costly and drawn out. WHOIS-based checks are increasingly unreliable for several reasons:

• Disabled service: at endings without WHOIS, the port-43 server no longer answers at all - the check either reports an error or wrongly treats the absence as “no expiry in sight”.
• Stale caches: some WHOIS answers come from caches whose expiry date is not updated immediately after a renewal - the monitor sees a long-outdated date.
• Inconsistent field names: without a standard, the expiry date is sometimes called “Registry Expiry Date”, sometimes “paid-till”, sometimes it is not in the answer at all - a parser that only knows one field format misses the others.
• Rate limits and blocks: WHOIS servers throttle automated queries aggressively; some deliberately return reduced or obscured records.
• Missing status signals: critical states such as “redemptionPeriod” or “pendingDelete” often do not appear in terse WHOIS answers at all - precisely the signals that should trigger an urgent warning.

RDAP clears these pitfalls because every field is named and typed. An expiry date arrives as an “expiration” event, a lock or transfer protection as a standardized status code. The monitor no longer has to guess but can evaluate signals unambiguously - the foundation of any robust domain expiry monitoring.

Which domain signals really matter

Reliable domain monitoring is not limited to a single expiry date. Four signal groups decide whether a domain stays secure, reachable and in your own hands:

The domain lifecycle: from expiry to deletion

Understanding what happens after the expiry date also explains why an early signal is so valuable. After expiry a gTLD passes through several phases in which recovery becomes ever more expensive and uncertain:

1. Auto-renew grace period: right after expiry many registrars grant a grace window in which the domain can be renewed easily - ICANN allows up to 45 days here, with the exact length set by the registrar (ICANN).
2. Redemption grace period: once the domain is deleted, a 30-day recovery window (“redemptionPeriod”) follows, in which only the previous owner can restore the domain for a usually steep restoration fee (ICANN).
3. Pending delete: after that the domain sits for five days in the status “pendingDelete” - now no recovery is possible, and the domain is released for deletion (ICANN).
4. Release: finally the domain falls back into the pool and can be registered anew by third parties - including automated services that catch coveted names within seconds.

These very transitions are mirrored in the EPP status codes that RDAP outputs in machine-readable form (ICANN). A monitor that recognizes the codes “redemptionPeriod” or “pendingDelete” can escalate immediately - whereas a WHOIS check that does not carry those fields sleeps through the emergency.

WHOIS check versus RDAP monitoring

The difference between an occasional manual glance and continuous monitoring is especially clear at the data source:

Setting up domain monitoring via RDAP

1. Inventory your domains: gather all domains in productive use - including rarely used redirect and brand domains, which experience shows are the first to be forgotten.
2. Choose the source: check per ending whether RDAP is available, and use WHOIS only as a fallback where the ending has not yet switched.
3. Define thresholds: set warning levels - for example 90, 30 and 7 days before expiry - and treat a status change such as “redemptionPeriod” as an immediate alert.
4. Bundle the signals: monitor expiry, nameservers, EPP status and DNSSEC together, so a single glance shows the domain's health completely.
5. Deliver the alerts: route warnings across multiple channels and document the trail via reports and status pages, so no signal drowns in the inbox.

Domain monitoring does not stand alone here: an expired or wrongly delegated certificate throws the same kind of silent outage as a forgotten domain expiry. How short-lived certificates change oversight is shown in the piece on 6-day certificates in SSL monitoring; how third-party infrastructure becomes an outage risk, the piece on cloud outages and third-party dependencies. Together, domain, SSL and DNS monitoring form a safety net that covers the pillars of availability.

Monitor domain expiry reliably - with XICTRAQ

The DNS and domain monitoring by XICTRAQ reads registration data from RDAP and only falls back to WHOIS where an ending has not yet switched. That keeps the expiry date dependable even when a registry shuts down its WHOIS service overnight. If nameservers or status codes change, the monitor reports the deviation instead of letting it drown in free text.

Instead of checking manually once a year, XICTRAQ monitors your domains continuously and typically warns with days to weeks of lead time - combined with SSL, DNS and uptime monitoring in one view. Start with a free trial and add your most important domains, or book a personal demo to see expiry early warning and status alerts in action.