RDAP (the Registration Data Access Protocol) is the replacement for WHOIS. It returns a domain’s registration data, including its expiry date, as JSON over HTTPS. Since January 28, 2025, ICANN treats RDAP as “the definitive source for delivering generic top-level domain name (gTLD) registration information in place of sunsetted WHOIS services”.

To look up a domain right now:

curl -sL https://rdap.org/domain/example.com \
  | jq -r '.events[] | select(.eventAction == "expiration") | .eventDate'
2027-08-13T04:00:00Z

The rest of this guide explains what that command did, how to read the full response, and what to do for the many country-code domains that RDAP doesn’t cover yet.

What changed, and when

  • August 26, 2019: ICANN’s deadline for gTLD registries and registrars to run an RDAP service (timeline).
  • February 3, 2024: end of the ramp-up period; all gTLD registries and registrars had to meet the gTLD RDAP Profile.
  • January 28, 2025: the WHOIS sunset. gTLD registries and registrars must still provide RDAP, but “are no longer required to provide WHOIS services (except for .com, .name, and .post)”, in ICANN’s words.
  • August 21, 2025: ICANN’s Registration Data Policy took effect, setting what registration data is collected, published and redacted.

These dates cover generic TLDs such as .com, .org and .app. Country-code TLDs (.uk, .de, .io) are run under their own national rules, and many don’t offer RDAP at all. More on that below.

WHOIS and RDAP side by side

  • Transport. WHOIS is plain text over TCP port 43. RDAP uses HTTPS.
  • Format. WHOIS replies in free text, and every server formats it differently. RDAP replies in JSON with a standard structure.
  • Finding the right server. WHOIS has no standard way, so clients carry hardcoded server lists. RDAP uses a bootstrap file published by IANA.
  • Character sets. WHOIS isn’t internationalized. RDAP is UTF-8 JSON.
  • Access control. WHOIS has none. RDAP can authenticate clients and give authorized users more data.
  • Redaction. Both use placeholder text such as “REDACTED FOR PRIVACY”. RDAP adds an optional, machine-readable redacted list.
  • Specification. WHOIS is RFC 3912 (2004). RDAP is Internet Standard STD 95, made of five RFCs.

RFC 3912 says it plainly: “The WHOIS protocol has not been internationalised”, and “WHOIS lacks mechanisms for access control, integrity, and confidentiality.” It only defines a text request and a text reply, which is why every WHOIS client ends up with a pile of per-registry parsers.

The RDAP standards

RDAP is STD 95, made of five RFCs:

  • RFC 7480: HTTP Usage in the Registration Data Access Protocol (RDAP), March 2015.
  • RFC 7481: Security Services for the Registration Data Access Protocol (RDAP), March 2015.
  • RFC 9082: Registration Data Access Protocol (RDAP) Query Format, June 2021. It replaced RFC 7482.
  • RFC 9083: JSON Responses for the Registration Data Access Protocol (RDAP), June 2021. It replaced RFC 7483.
  • RFC 9224: Finding the Authoritative Registration Data Access Protocol (RDAP) Service, March 2022. It replaced RFC 7484.

Older articles cite RFCs 7482 to 7484; those were the 2015 originals, replaced by the three newer ones.

How an RDAP lookup finds the right server

Your RDAP client IANA bootstrap file Registry RDAP server Registrar RDAP server curl, a library, or rdap.org data.iana.org/rdap/dns.json rdap.verisign.com/com/v1/ from the “related” link 1. Which server answers for .com? 2. GET /domain/example.com 3. Optional: registrar’s own view
The RDAP bootstrap (RFC 9224): IANA publishes which RDAP server is authoritative for each TLD.
  1. Bootstrap. IANA publishes dns.json, a list that maps TLDs to the base URL of their registry’s RDAP server. For .com, that is https://rdap.verisign.com/com/v1/.
  2. Registry query. The client appends domain/<name> to that base URL and fetches it. The registry’s answer covers the registration itself: status, dates, name servers and which registrar manages it.
  3. Registrar query (optional). The registry response usually includes a link with "rel": "related" pointing to the registrar’s RDAP server, which may hold contact details (mostly redacted) and its own view of the dates.

rdap.org does step 1 for you: it “aggregates information about all known RDAP servers” and redirects your query to the right one. It is run by Gavin Brown in his own time, and Cloudflare limits clients to 10 requests in 10 seconds, so for anything beyond occasional lookups, read the bootstrap file yourself and cache it.

curl -s -o /dev/null -D - https://rdap.org/domain/example.com | grep -iE '^(HTTP|location)'
HTTP/2 302 
location: https://rdap.verisign.com/com/v1/domain/example.com

Read an RDAP response

Here are the useful parts of the registry’s answer for example.com (trimmed with jq):

curl -sL https://rdap.org/domain/example.com \
  | jq '{objectClassName, ldhName, status, events, nameservers: [.nameservers[].ldhName]}'
{
  "objectClassName": "domain",
  "ldhName": "EXAMPLE.COM",
  "status": [
    "client delete prohibited",
    "client transfer prohibited",
    "client update prohibited"
  ],
  "events": [
    { "eventAction": "registration", "eventDate": "1995-08-14T04:00:00Z" },
    { "eventAction": "expiration", "eventDate": "2027-08-13T04:00:00Z" },
    { "eventAction": "last changed", "eventDate": "2026-08-14T08:01:43Z" },
    { "eventAction": "last update of RDAP database", "eventDate": "2026-10-14T17:17:10Z" }
  ],
  "nameservers": [
    "ELLIOTT.NS.CLOUDFLARE.COM",
    "HERA.NS.CLOUDFLARE.COM"
  ]
}

What each part means:

  • events carries the dates. expiration is when the registration runs out unless renewed; registration is when it was first registered; last changed is the last update to the domain record. last update of RDAP database is when the server’s data was refreshed, not a change to your domain.
  • status uses plain-English strings mapped from the registry’s EPP status codes by RFC 8056: client transfer prohibited is EPP’s clientTransferProhibited (the registrar’s transfer lock), and active is EPP’s ok.
  • entities lists the organizations involved with their roles. In a registry response that is usually just the registrar, with its IANA Registrar ID.
  • links can include a related link to the registrar’s RDAP server. example.com has none; google.com’s points to rdap.markmonitor.com.
  • notices and remarks hold terms of use and explanations, as text.

Just the expiry date

Three ways to print only the expiration date, all tested against google.com:

URL=https://rdap.verisign.com/com/v1/domain/google.com

# jq
curl -s "$URL" | jq -r '.events[] | select(.eventAction == "expiration") | .eventDate'

# Node.js
curl -s "$URL" | node -e 'let s="";process.stdin.on("data",c=>s+=c).on("end",()=>console.log(JSON.parse(s).events.find(e=>e.eventAction==="expiration").eventDate))'

# Python
curl -s "$URL" | python3 -c 'import json,sys; print(next(e["eventDate"] for e in json.load(sys.stdin)["events"] if e["eventAction"]=="expiration"))'

Each prints 2028-09-14T04:00:00Z.

Registry and registrar can disagree

For google.com, the .com registry (Verisign) and the registrar (MarkMonitor) both answer over RDAP, with different details:

The registry, Verisign (rdap.verisign.com):

  • expiration: 2028-09-14T04:00:00Z
  • last changed: 2019-09-09T15:39:04Z
  • Contacts: only the registrar

The registrar, MarkMonitor (rdap.markmonitor.com):

  • expiration: 2028-09-13T07:00:00.000+00:00
  • registrar expiration: 2028-09-14T07:00:00.000+00:00
  • last changed: 2024-08-02T02:17:33.000+00:00
  • Contacts: the registrant, mostly “REDACTED FOR PRIVACY”

The registry is the database the domain is actually registered in, so we treat its expiration as the date of record and the registrar’s dates as the registrar’s own view, which can include its billing schedule. When the two differ by more than a day, ask your registrar which date your renewal is planned against.

Where RDAP falls short: country-code domains

Almost every generic TLD has RDAP, because ICANN’s contracts require it; the only exceptions in IANA’s list are .arpa, .edu and .mil. Country-code TLDs set their own rules. IANA’s bootstrap file published on September 30, 2026 lists RDAP servers for 1,203 of the 1,437 TLDs in the root zone, but only 72 of the 248 two-letter country-code TLDs.

For example, .uk, .fr, .nl, .br, .au, .ca and .ai are in the bootstrap; .de, .io, .co, .jp and .me are not.

You can recount yourself:

curl -s https://data.iana.org/rdap/dns.json \
  | jq -r '.publication, ([.services[][0][]] | length), ([.services[][0][] | select(length == 2)] | length)'
2026-09-30T23:00:03Z
1203
72

For a TLD outside the bootstrap, rdap.org answers with a 404:

curl -s https://rdap.org/domain/denic.de
{"rdapConformance":["rdap_level_0"],"lang":"en","errorCode":404,"title":"No RDAP service is available for this resource"}

For those domains, use the registry’s own lookup: most country-code registries still run a WHOIS server or a web form, and some publish an RDAP service that isn’t registered with IANA yet. Check the registry’s website, which you can find from IANA’s root zone database.

Using RDAP in your own tools

  • Cache the bootstrap file. It changes rarely; refresh it daily rather than per lookup.
  • Respect rate limits. Registries throttle heavy users. Domain expiry dates change only on renewal, so checking each domain once a day is plenty.
  • Treat failures as failures. A timeout, a 404 or an unparseable response tells you nothing about the domain’s expiry. Keep the last good result and report the failed lookup separately, never as “expired”.
  • Look for the redacted extension. RFC 9537 lets servers say which fields they redacted. Servers that use it list redacted in rdapConformance; many, including the registrar above, still use only placeholder text.

Expiry Watch looks up domain expiry over RDAP, checks once a day, and emails at 30, 14, 7, 3 and 1 day before the registration runs out. A lookup that fails is reported as a failed lookup, never as an expiry.

Sources

All sources were checked on October 14, 2026.