RDAP domain expiry check for TLDs that support it

[berthubert]

After discussion with @alarig it emerged that some registries publish through RDAP when a domain is set to expire.
https://data.iana.org/rdap/dns.json has a list of servers
then query the RDAP server with https://rdap.server/domain/domain.com and parse the JSON.
For example: curl https://rdap.publicinterestregistry.org/rdap/domain/skewdb.org
Not all TLDs provide RDAP and many do not publish expiry date, or it might not even be meaningful.

[iPythoning]

Here's what I've learned implementing RDAP-based domain expiry checks in practice:

TLD coverage (real-world, not spec):

• gTLDs (.com, .net, .org, .info, etc.) — all required to support RDAP per ICANN contract. Expiry date reliably available via events[].eventAction: "expiration".
• Popular ccTLDs: .de (DENIC) has RDAP but doesn't publish expiry. .co.uk (Nominet) has RDAP with expiry. .ca (CIRA) has RDAP with expiry. .io, .ai — RDAP exists, expiry hit or miss.
• Many smaller ccTLDs simply don't have RDAP yet. The IANA bootstrap file is accurate but the server at the listed URL may return 404 or HTML instead of JSON.

Implementation pitfall — redirects:
The IANA bootstrap gives you the base URL, but many RDAP servers redirect. E.g., rdap.org is a redirect service, not a real RDAP server. The actual RDAP URL for .org is https://rdap.publicinterestregistry.org/rdap/. You'll want your HTTP client to follow redirects and also handle https://rdap.org/domain/{domain} as a universal fallback that delegates to the correct TLD server.

Caching the bootstrap:
Don't fetch dns.json on every query — it's ~2MB and rarely changes. Cache it for 24h. The TLD→server mapping is stable.

Browser CORS limitation:
If you ever want a browser-based frontend to do RDAP queries: most RDAP servers don't return CORS headers, so direct browser queries fail. You need a backend proxy. For server-side (Perl in your case), this isn't an issue.

Happy to share more specifics if you run into issues with particular TLDs. I've been building a browser-based RDAP/WHOIS tool at https://ipythoning.github.io/dns-tools/ that hits similar problems.

[iPythoning]

Can confirm RDAP works well for this use case. We built a WHOIS lookup tool (https://ipythoning.github.io/dns-tools/whois.html) that uses RDAP client-side, and the expiration detection path is straightforward:

The key field in RDAP JSON responses is events array — look for eventAction: "expiration" and read eventDate in ISO 8601 format.

Some practical observations on coverage:

• gTLDs (.com, .net, .org): All return expiration via RDAP reliably. Verisign's RDAP (.com/.net) is the most consistent.
• ccTLDs: Hit or miss. .de (DENIC) returns good RDAP data. .io and .co work. But .tk, .ml, .ga (Freenom) don't support RDAP at all.
• The IANA bootstrap at https://data.iana.org/rdap/dns.json is the canonical source for which TLDs have RDAP servers — but it doesn't tell you whether those servers actually return expiration data.

One approach we considered: maintain a small deny-list of TLDs known to not return expiration via RDAP, and fall back to WHOIS text parsing only for those. The list is much shorter than maintaining regexes for everything.

Cache the IANA bootstrap file (it's ~400KB) — it only changes when new TLDs are added or RDAP servers move.