RDAP: The Successor to WHOIS (And Why You Should Stop Suffering with the Past)
I was building a WHOIS tool for my Web Tools project when I ran into a major problem: WHOIS itself.
The premise is simple: query port 43 on a server, send a string, and wait for a response. The problem? The response is never the same from one system to another, and you have to keep patching your RegEx to make it work. There is no real standard. Registro.br formats it one way, Verisign another, APNIC yet another.
Who hasn't written a monitoring script that broke just because the registry changed the phrase "Domain Expiry Date:" to "Registry Expiry Date:"? Trying to normalize this output with sed, awk, and RegEx is a nightmare that no one should have to deal with in 2025.
Fortunately, WHOIS is (slowly) dying. The successor is already among us. It's called RDAP (Registration Data Access Protocol), and unlike its grandfather from the 80s, it was built for machines, not for humans staring at monochrome terminals.
A Bit of History
This didn't pop up yesterday. The technical community had been tired of the mess on port 43 for a long time:
2012: The IETF starts moving and creates the WEIRDS working group (yes, that was the actual name) to modernize this.
2015: The RFCs are born (7480 and friends). The standard was set.
2019: ICANN drops the gavel. It became mandatory for registrars and registries of gTLDs (.com, .net, etc.) to implement RDAP.
In other words, we should have been using this for a while now.
What is wrong with port 43?
WHOIS is a plain-text based protocol. It has no native support for internationalization (try querying domains with Chinese characters or emojis on legacy WHOIS and watch the magic fail), no standardized authentication, and worst of all, no data structure. Everyone does whatever they want, however they want, and whoever consumes the system has to fend for themselves.
RDAP solves this by bringing registration data queries into the 21st century. In practical terms:
It's HTTP(S): No more obscure ports that corporate firewalls block. It runs on port 443.
It's JSON: Finally! Structured data that any modern language (JS, Python, Go, Rust) handles easily.
Supports Redirection: The server can send you to the correct authoritative source using standard HTTP headers.
Hands-on: WHOIS vs RDAP
Let's see this in practice. Let's say I want to inspect Cloudflare's 1.1.1.1 IP block.
In the old way, you run whois 1.1.1.1 and get a wall of text. You have to visually "parse" where the address starts, where the abuse contact is, etc.
In RDAP, it's just a REST call.
curl -X GET [https://rdap.apnic.net/ip/1.1.1.1](https://rdap.apnic.net/ip/1.1.1.1)The result is clean, predictable JSON:
{
"rdapConformance": [
"history_version_0",
"nro_rdap_profile_0",
"cidr0",
"rdap_level_0"
],
"notices": [
{
"title": "Source",
"description": [
"Objects returned came from source",
"APNIC"
]
},
{
"title": "Terms and Conditions",
"description": [
"This is the APNIC WHOIS Database query service. The objects are in RDAP format."
],
"links": [
{
"value": "https://rdap.apnic.net/ip/1.1.1.1",
"rel": "terms-of-service",
"href": "http://www.apnic.net/db/dbcopyright.html",
"type": "text/html"
}
]
},
{
"title": "Whois Inaccuracy Reporting",
"description": [
"If you see inaccuracies in the results, please visit: "
],
"links": [
{
"value": "https://rdap.apnic.net/ip/1.1.1.1",
"rel": "inaccuracy-report",
"href": "https://www.apnic.net/manage-ip/using-whois/abuse-and-spamming/invalid-contact-form",
"type": "text/html"
}
]
}
],
"country": "AU",
"events": [
{
"eventAction": "registration",
"eventDate": "2011-08-10T23:12:35Z"
},
{
"eventAction": "last changed",
"eventDate": "2023-04-26T22:57:58Z"
}
],
"name": "APNIC-LABS",
"remarks": [
{
"description": [
"APNIC and Cloudflare DNS Resolver project",
"Routed globally by AS13335/Cloudflare",
"Research prefix for APNIC Labs"
],
"title": "description"
},
{
"description": [
"---------------",
"All Cloudflare abuse reporting can be done via",
"[email protected]",
"---------------"
],
"title": "remarks"
}
],
"links": [
{
"value": "https://rdap.apnic.net/ip/1.1.1.1",
"rel": "self",
"href": "https://rdap.apnic.net/ip/1.1.1.0/24",
"type": "application/rdap+json"
}
],
"status": [
"active"
],
"type": "ASSIGNED PORTABLE",
"ipVersion": "v4",
"endAddress": "1.1.1.255",
"startAddress": "1.1.1.0",
"objectClassName": "ip network",
"handle": "1.1.1.0 - 1.1.1.255",
"entities": [
{
"roles": [
"registrant"
],
"events": [
{
"eventAction": "registration",
"eventDate": "2017-08-08T23:21:55Z"
},
{
"eventAction": "last changed",
"eventDate": "2023-09-05T02:15:19Z"
}
],
"links": [
{
"value": "https://rdap.apnic.net/ip/1.1.1.1",
"rel": "self",
"href": "https://rdap.apnic.net/entity/ORG-ARAD1-AP",
"type": "application/rdap+json"
}
],
"vcardArray": [
"vcard",
[
[
"version",
{
},
"text",
"4.0"
],
[
"fn",
{
},
"text",
"APNIC Research and Development"
],
[
"kind",
{
},
"text",
"org"
],
[
"adr",
{
"label": "6 Cordelia St"
},
"text",
[
"",
"",
"",
"",
"",
"",
""
]
],
[
"tel",
{
"type": "voice"
},
"text",
"+61-7-38583100"
],
[
"tel",
{
"type": "fax"
},
"text",
"+61-7-38583199"
],
[
"email",
{
},
"text",
"[email protected]"
]
]
],
"objectClassName": "entity",
"handle": "ORG-ARAD1-AP"
},
{
"roles": [
"abuse"
],
"events": [
{
"eventAction": "registration",
"eventDate": "2011-04-12T17:56:54Z"
},
{
"eventAction": "last changed",
"eventDate": "2025-11-18T00:26:57Z"
}
],
"remarks": [
{
"description": [
"[email protected] was validated on 2021-02-09"
],
"title": "remarks"
}
],
"links": [
{
"value": "https://rdap.apnic.net/ip/1.1.1.1",
"rel": "self",
"href": "https://rdap.apnic.net/entity/IRT-APNICRANDNET-AU",
"type": "application/rdap+json"
}
],
"vcardArray": [
"vcard",
[
[
"version",
{
},
"text",
"4.0"
],
[
"fn",
{
},
"text",
"IRT-APNICRANDNET-AU"
],
[
"kind",
{
},
"text",
"group"
],
[
"adr",
{
"label": "PO Box 3646\nSouth Brisbane, QLD 4101\nAustralia"
},
"text",
[
"",
"",
"",
"",
"",
"",
""
]
],
[
"email",
{
},
"text",
"[email protected]"
],
[
"email",
{
"pref": "1"
},
"text",
"[email protected]"
]
]
],
"objectClassName": "entity",
"handle": "IRT-APNICRANDNET-AU"
},
{
"roles": [
"administrative",
"technical"
],
"events": [
{
"eventAction": "registration",
"eventDate": "2023-04-26T00:42:16Z"
},
{
"eventAction": "last changed",
"eventDate": "2024-07-18T04:37:37Z"
}
],
"links": [
{
"value": "https://rdap.apnic.net/ip/1.1.1.1",
"rel": "self",
"href": "https://rdap.apnic.net/entity/AIC3-AP",
"type": "application/rdap+json"
}
],
"vcardArray": [
"vcard",
[
[
"version",
{
},
"text",
"4.0"
],
[
"fn",
{
},
"text",
"APNICRANDNET Infrastructure Contact"
],
[
"kind",
{
},
"text",
"group"
],
[
"adr",
{
"label": "6 Cordelia St South Brisbane QLD 4101"
},
"text",
[
"",
"",
"",
"",
"",
"",
""
]
],
[
"tel",
{
"type": "voice"
},
"text",
"+61 7 3858 3100"
],
[
"email",
{
},
"text",
"[email protected]"
]
]
],
"objectClassName": "entity",
"handle": "AIC3-AP"
}
],
"cidr0_cidrs": [
{
"v4prefix": "1.1.1.0",
"length": 24
}
],
"port43": "whois.apnic.net"
}Look at that. No crazy parsing. If I want to know the name of the entity, I access $.entities['0'].vcardArray[1][1][3]. Done.
Note the use of jCard (vCard in JSON) for contact data. It's a standard within a standard, which makes integration with CRM or ticketing systems much easier.
A lifesaver here is the events field. In WHOIS, dates come in random formats (DD-MM-YYYY, MM/DD/YYYY, YYYY.MM.DD). In RDAP, everything is ISO 8601 (YYYY-MM-DDTHH:MM:SSZ). If you’ve ever had to wrangle timezones and date formats in automation scripts, you know this is pure gold.
The universe beyond IP and Domain
A lot of people think WHOIS/RDAP is just for checking "who owns this site" or "where is this IP coming from," but the RDAP protocol broadens that horizon. The URL structure is standardized to query pretty much any object on the internet:
Domains:
GET /domain/example.com— The classic.IPs:
GET /ip/1.1.1.1— Supports IPv4 and IPv6.Entities:
GET /entity/GOOGL-123— Want to know the person or org behind a specific handle? This is the place.Nameservers:
GET /nameserver/ns1.example.com— To debug DNS delegation issues.Autnum (ASNs):
GET /autnum/13335— Essential for those working with BGP and routing. You can see the technical and abuse contacts for an entire Autonomous System with a single request.
This turns RDAP into a powerful tool not just for "curiosity," but for security automation and Network Engineering. You can write a script that detects a DDoS attack, extracts the attacker’s IP ASN via RDAP, grabs the abuse email from the JSON (which comes structured inside entities with the abuse role), and generates an automated report. Try doing that with raw WHOIS text and good luck.
The Magic of Bootstrap (The Power of Redirects)
Here is where things get interesting. The big technical question is usually: "How do I know which URL to call for a random IP or an obscure TLD?"
In old WHOIS, your client needed a hardcoded list or had to guess. In RDAP, there is the concept of Bootstrap, but the real trick is how the protocol handles redirects.
IANA maintains giant JSON files mapping who owns what. But you don't have to download that and implement the logic if you don't want to. You can use a "query router".
A brilliant example is the rdap.org service. It acts as smart middleware. Look at the flow:
You send the request to it:
GET https://rdap.org/domain/google.comIt queries the IANA table internally.
It sees that
.combelongs to Verisign.It does not proxy. It returns an HTTP 302 Found with the header
Location: https://rdap.verisign.com/com/v1/domain/google.com.Your HTTP client (curl, axios, requests) automatically follows the redirect and fetches the JSON from the official source.
This massively simplifies your tool's architecture. You point everything to one place and let the HTTP protocol do the dirty work of taking you to the correct server. It's elegant and eliminates the need to maintain local routing databases.
Error Codes That Make Sense
Another huge advantage for tool developers: HTTP Codes.
If a domain doesn't exist:
WHOIS: Returns text like "No match", "Not found", "Domain not found", depending on the sysadmin's mood that day.
RDAP: Returns HTTP 404.
If you are being rate-limited (blocked due to excess queries):
WHOIS: The connection drops, or you get an angry text message.
RDAP: Returns HTTP 429 (Too Many Requests).
This drastically simplifies error handling logic in automation scripts.
Conclusion
WHOIS served its purpose. It comes from an era when the internet fit into a phone book. But for modern operations, security automation, and SRE, it is a dinosaur.
If you are building internal tools, verification bots, or just need reliable data about ASNs and domains, forget the past. RDAP is faster, supports HTTPS, and speaks the language of the web.
For those who want to test it right now without installing anything, try querying a Brazilian domain directly in your browser or via terminal (note the -L to follow the redirect if necessary):
curl -L -H "Accept: application/rdap+json" [http://rdap.org/domain/youtube.com.br](http://rdap.org/domain/youtube.com.br)Or use this tool I built (still in beta) to see the magic happen.
Your monitoring scripts will thank you.
Comentários
0Nenhum comentário ainda. Seja o primeiro!