WHOIS vs RDAP: What Changed, What Did Not, and Whether the Command Still Works

I read ten WHOIS vs RDAP comparisons for this piece. Exactly one is both correct and internally consistent, several contradict themselves between body and headline, and not one names the exception that matters. No central authority switched WHOIS off. On 28 January 2025 a contractual obligation expired, a different event with a very different consequence.

What expired was a clause in ICANN's agreements with gTLD registries, and the amendment that ended it wrote down what happens if a registry carries on anyway. Three namespaces were never inside that amendment, and one is .com. A page ranking for this search says the opposite about .com, in a section whose whole subject is exceptions.

So here is what the documents say. What changed on that date and what did not, what RDAP does that WHOIS could not, and why address lookups run on a separate timetable. Then the question you probably came with: does the command still work. Where I could not verify something, I say so.

Author: Sarah Thompson Network Intelligence Analyst

Contracts and registry records are what I read for a living, and this topic is unusually badly served by summaries. Almost every page on it repeats a shutdown that no document describes, because "no longer required" and "no longer available" look identical when you are skimming. So everything below is quoted from the instrument that says it: an ICANN amendment, a registry agreement appendix, an RFC, or a registry's own announcement, carrying whatever date that document carries.

My limits, plainly. I cannot open a TCP connection to port 43 from where I work, so nothing here rests on me testing a server myself. Every claim about what still answers comes from a contract, a published announcement, or a maintainer's own changelog. Where a page carries no date, I say it carries no date. And the most-quoted number on this topic counts servers nobody can list, which I flag at the point I use it.

What Actually Happened on 28 January 2025

An obligation expired. ICANN's Global Amendment took effect on 7 August 2023 and set a WHOIS Services Sunset Date, which ICANN's own summary puts on 28 January 2025, eighteen months later. Before that date a gTLD registry had to run WHOIS. After it, a registry may, and that verb is the whole change.

That summary is careful about scope in a way the coverage is not: "the sunset of certain obligations to provide RDDS via the WHOIS protocols". Certain obligations. Not the protocol, the service or the data.

Read it literally. The clause was not phrased as a removal but time-bounded from the day it was drafted: "Until the WHOIS Services Sunset Date, Registry Operator will operate a WHOIS service available via port 43 in accordance with RFC 3912, and a web-based WHOIS Service at <whois.nic.TLD>...", the sentence then listing the fields. Nobody struck it out. It ran out.

The same amendment has a section for registries that keep going. Section 1.5, "Whois Data Directory Services after the Whois Services Sunset Date", opens: "If Registry Operator continues to offer WHOIS Data Directory Services after the WHOIS Services Sunset Date the following requirements will apply". A contract banning WHOIS would not need that section.

That last row costs people the most time. Domain records and number records sit with different organizations under different contracts, and this amendment touched only the first. If whois 192.0.2.1 stopped behaving, nothing above is your answer.

If any of the layers underneath are new to you, start with the plain-English version of what a public IP address actually is. Next, the exception a page ranking for this gets backwards.

Where WHOIS Is Still Required, and the Claim That Gets It Backwards

ICANN names three, on a different page from the amendment. Its RDAP page for contracted parties says gTLD registries "are no longer required to provide WHOIS services (except for .com, .name, and .post)". The mechanism is scope, not exemption: the amendment reaches only the agreements in its Schedule A, and the oldest namespaces sit on legacy agreements it never reached.

For .com the obligation sits in Appendix 5A of the registry agreement, in the language the amendment time-bounded elsewhere: "Registry Operator will operate a WHOIS service available via port 43 in accordance with RFC 3912 at whois.verisign.net...". Here it carries no sunset clause at all. One honest note: that appendix dates itself by reference, so I can say what it requires and not when that started.

The .name and .post obligations sit in their own legacy agreements. I have not opened those appendices, so I name the pattern rather than quoting clause numbers I have not read.

Now the error, and it is not small. Dynadot's guide, dated 18 May 2026, ranks for this subject and states: "As of January 28, 2025, ICANN no longer requires registries and registrars to maintain WHOIS services for generic top-level domains like .COM, .NET, and .ORG." The .com obligation is one of the three that survived.

What makes it worth naming is where it sits. That page runs a section headed "WHOIS Isn't Fully Dead: The ccTLD Exception Domain Investors Need to Know", using .DE as its example. It went looking for exceptions, found the country-code one, and missed the gTLD exception holding the largest namespace on the internet.

For anyone running a .com WHOIS lookup, nothing changed. For a newer gTLD the answer really is "check, it depends on the registry", and you can confirm that against a live record in seconds. What comes back reads more easily once you know what each protocol returns.

RDAP vs WHOIS: What One Was Built To Do and the Other Was Not

RDAP is a REST API. You send an HTTPS request to a documented URL path and get back JSON with named fields from a published data model. WHOIS opens a TCP connection to port 43, sends a string, and returns text laid out however that server likes. Every other difference follows.

The axis people care about most is redaction, and precision helps: redaction is policy, not a protocol feature. Both return what the registry decided to publish. RDAP only adds a clean way to express an authenticated request, the basis for differentiated access. ICANN's separate Registration Data Request Service, for nonpublic gTLD data, is on a clock too: its pilot ended in November 2025 and the Board directed ICANN to "continue RDRS operations for up to two additional years".

There is a measured answer to a question none of the ten asks. A 2024 paper from Grenoble Alpes and CNRS, "WHOIS Right? An Analysis of WHOIS and RDAP Consistency", compared 164 million records across 55 million domains: "7.6% of the observed domains still present inconsistent data on important fields like IANA ID, creation date, or nameservers".

It goes further on nameservers. Where the two records shared none in common, it checked which matched live DNS: "In 78.5% of cases, the DNS data corresponded to the nameservers provided by the RDAP record". Read that as a tiebreaker, not an accuracy score: it was measured only on the disagreements.

That gives you a cheap check when a record looks stale. Pull the nameservers straight from DNS and compare, and how a name turns into an address covers the step underneath. RDAP is the better-engineered protocol. That is not the same as WHOIS being dead, and the specification says so better than I can.

The Protocol Nobody Deprecated, Criticized By Its Own Specification

The IETF has never deprecated WHOIS. RFC 3912 appeared in September 2004, obsoleting RFC 954 and RFC 812, and the IETF Datatracker records its status today as "RFC - Draft Standard (September 2004)", with nothing obsoleting it and nothing updating it. On paper, WHOIS sits exactly where it sat twenty-two years ago.

That label is a fossil, and the IETF's own word is blunter than mine. RFC 6410 cut the standards track from three tiers to two in October 2011, calls it "the abandoned Draft Standard maturity level", and says anything already there "will retain that classification, absent explicit actions". Nobody has acted on RFC 3912 since.

Here is the strange part, and none of the ten pages uses it. The specification criticizes the protocol it specifies, in its own Security Considerations section.

It opens: "The WHOIS protocol has no provisions for strong security." Then: "WHOIS lacks mechanisms for access control, integrity, and confidentiality." One sentence and a paragraph break later: "The absence of such security mechanisms means this protocol would not normally be acceptable to the IETF at the time of this writing."

A standards-track document saying its protocol would not normally be acceptable to the body publishing it. The same RFC is as blunt about encoding: "The WHOIS protocol has no mechanism for indicating the character set in use." And it draws the conclusion itself: "This inability to predict or express text encoding has adversely impacted the interoperability (and, therefore, usefulness) of the WHOIS protocol."

RDAP's core, by contrast, is Internet Standard STD 95: RFC 7480, RFC 7481, RFC 9082, RFC 9083 and RFC 9224. If you have seen RFC 7482, 7483 or 7484 cited, those are obsolete, replaced by 9082, 9083 and 9224. Of the ten pages I read, two cite the current numbers and none names STD 95.

And RDAP is still growing. RFC 10037, published on 28 August 2026, adds DNS time-to-live values to RDAP responses. WHOIS has had no new specification since 2004.

So the scoreboard: WHOIS is unmaintained, RDAP is a full Internet Standard. Neither tells you where to send a query, which is the part that breaks.

Finding the Right Server, Which Is the Part That Actually Breaks

This is where WHOIS fails in practice, unglamorously: nothing in RFC 3912 tells a client which server to ask. Clients solved that with a hand-maintained table of TLDs to hostnames. When a registry turns its server off, the table is wrong and the client cannot tell.

RDAP fixed exactly this, the underrated half of the standard. RFC 9224 defines the RDAP bootstrap registry, which IANA publishes as a fetchable file, so a client resolves the base URL at query time. The domain file at data.iana.org/rdap/dns.json was last modified on 16 September 2026, with companion files for AS numbers and addresses.

Bootstrapping also explains a breakage that looks like an outage and is not. If a registry stops advertising its WHOIS server in the IANA records, every client that found it that way fails while the server may still be listening. The other reason a lookup breaks has nothing to do with domains.

Addresses and AS Numbers Are on a Completely Different Clock

If you look up addresses and AS numbers rather than domains, the 2025 date does not apply. Those records belong to the five regional internet registries, which hold no ICANN registry agreement, and their port 43 services run today. One has proposed an end date. The rest have published nothing.

ARIN put a road map out for consultation in an announcement dated 14 August 2026, opening on the scale: "ARIN currently maintains four directory information protocols: Whois-RWS, RWhois, Whois (Port 43), and RDAP." Its own framing is a proposal, not a decision: "ARIN proposes retiring use of older protocols in favor of RDAP as our single, standardized directory service."

The proposed dates run Whois-RWS "on or after 1 July 2027", RWhois "dependent on migration tool release date, but no sooner than 1 January 2028", and Whois (Port 43) "on or after 1 January 2029". Port 43 gets the longest runway: it "carries a high volume of queries" and "remains heavily used by cybersecurity professionals, researchers, law enforcement, and many other types of organizations". ARIN proposes "a two-year sunsetting window".

Now the part most coverage will get wrong. On 15 September 2026 ARIN said the consultation had closed and that it would report next steps at ARIN 58, its meeting on 22 and 23 October 2026. No outcome is published as I write. Treat 2029 as a proposal with a decision date, and if you read this after October 2026, check what ARIN decided.

There is a technical reason for the lag, and the IETF named it. RFC 9910, "Registration Data Access Protocol (RDAP) Regional Internet Registry (RIR) Search", January 2026, opens on the gap: "there are various search options related to IP addresses, IP prefixes, and Autonomous System Numbers (ASNs), which are provided by RIRs via their WHOIS services, but for which there is no corresponding RDAP functionality". The IETF, eight months ago, confirming RIR WHOIS did what RDAP could not.

I looked for a retirement date at RIPE NCC, APNIC, LACNIC and AFRINIC and found none published. That is an absence of a finding, not a finding of absence. ARIN is the only registry to put a date in front of its community, and one proposal is not "the registries are retiring port 43".

Which registry an address belongs to, and the region that implies is the field to read first when attributing an address, because it names whose rules and whose timeline apply. Which leaves the question everybody arrived with.

So Does the Command Still Work in 2026

Mostly yes, and where it stopped working the record is public. I have not tested these servers, so everything below comes from a dated, named source rather than a terminal of mine.

The clearest evidence is a bug report. The monitoring plugin check-whois filed issue 758 on 8 August 2025, naming .info. Its opening line is the useful part: "Two days ago this plugin (and the standard whois client distributed with many Linux distros) began failing to perform WHOIS queries for generic top-level domains (gTLD)".

The other half of the trail is the client. The whois package Debian and Ubuntu ship is maintained by Marco d'Itri, and its changelog records the cleanup. Version 5.6.5, 13 October 2025: "Removed the .pro TLD server." Version 5.6.6, 16 February 2026: "Removed the .info, .mobi, .travel and .فلسطين (.xn--ygbi2ammx, Palestinian Territory) TLD servers."

Two details matter. The .info removal in February 2026 is the downstream fix for the August 2025 breakage, so a server going away and the client noticing took half a year. Neither release added RDAP, because the client has none: its manual page calls it a client that "searches for an object in a RFC 3912 database".

That ccTLD figure needs its caveat. It is the most-quoted number here and routinely quoted wrong. ICANN principal engineer Andy Newton wrote on the IETF blog on 19 February 2026 that "approximately 60% of ccTLDs have deployed RDAP, a 12% increase since January 2025". His own sentence qualifies it: the count includes "stealth" servers absent from the IANA bootstrap files, so no public list reproduces it.

And that was February. The same sentence reports a twelve percent rise in a year, so the share without RDAP is probably lower now. For whatever remains, WHOIS is the only option there is.

One of those dates is behind you. Nominet has two for .uk: from August 2026 its IANA records stop advertising the WHOIS server, which Nominet says "may affect some WHOIS clients that rely on locating the WHOIS server", and the protocol retires on 9 February 2027. Its advice meanwhile: "In the short term you can configure your WHOIS client to use the server 'whois.nic.uk'."

Newton's traffic figures fill in the rest. WHOIS queries fell from roughly 122 billion a month in January 2025 to around 49 billion by August, gTLD RDAP queries rose from around seven billion to 65 billion, and RDAP passed WHOIS in June 2025. Both still carry tens of billions a month. Not a dead protocol.

What to Change, and by When

Underneath all of it, the WHOIS vs RDAP story is a contract story in a protocol costume. One clause expired for one category of domain, the oldest namespaces were never in it, and the number registries never were. A protocol criticized in its own specification still carries tens of billions of queries a month. Pages calling it replaced describe an intention, not an event.

The habit worth building is checking the date on whatever you read, this page included. How WHOIS history services keep snapshots of records that have since changed is the companion piece, and finding the server behind a domain name is the lookup that comes next. The protocol matters less than which registry you ask and what it owes you.