ICANN RDAP Explained: The WHOIS Replacement (2026 Guide)

WHOIS was never designed for machine consumption, and after two decades of registrar-specific output formats and a decade of privacy-driven redaction, it no longer works as a data source. ICANN's Registration Data Access Protocol (RDAP) is the standardized replacement: same registration data, delivered as JSON over HTTPS with a consistent schema. This guide explains what RDAP is, what its responses actually contain in 2026 (much less than people expect), how it differs from WHOIS at the protocol level, and how to work with domain-level data at scale when per-domain lookups are not practical.

Key takeaways

• WHOIS is being retired: the protocol returns free text with no guaranteed structure, differs between every registrar, and has no standard authentication, error handling or internationalization.
• RDAP is the ICANN-mandated replacement: defined in RFC 7480-7484, it returns JSON over HTTPS with a documented object model, standard HTTP status codes and a bootstrap registry for finding the right server.
• Structure is the real gain: registrar, creation and expiration dates, name servers, status codes and event records arrive as named fields instead of text that has to be pattern-matched.
• Contact data is mostly gone: RDAP responses for gTLDs are redacted by default. Registrant names, emails and phone numbers are not obtainable at scale through RDAP, and no legitimate tool changes that.
• Per-domain lookup does not scale: RDAP servers are rate limited. Population-level questions ("how many domains in .de run WordPress") need bulk files, not queries.
• Bulk files answer different questions: zone files and enriched per-zone sets give you domain, name servers, MX, IP and detected CMS across whole TLDs, which is the right input for market sizing, infrastructure research and dataset building.

Table of contents

1. ICANN RDAP: the modern foundation for domain data, and why WHOIS is obsolete
2. What RDAP does not give you: redaction, rate limits and scale
3. Where domain-level data is actually useful
4. What WebTrackly provides: bulk domain data packages
5. Data schema: what is inside the CSV
6. Using the catalog API
7. Processing the files locally
8. Common mistakes when working with RDAP data
9. FAQ
10. Conclusion

ICANN RDAP: The Modern Foundation for Domain Data and Why WHOIS Is Obsolete

The internet runs on domains, and understanding who owns them, who manages them, and when they were registered is fundamental to a vast array of online activities, from B2B lead generation to cybersecurity investigations. For decades, the primary tool for this was WHOIS. However, the traditional WHOIS protocol, designed in the early days of the internet, has become a relic, increasingly inadequate for the demands of the modern web. Its free-text, inconsistent output, coupled with evolving privacy regulations like GDPR, has rendered it notoriously difficult to parse programmatically and often incomplete for legitimate business uses. This is precisely why the ICANN RDAP overview WHOIS replacement is not just an upgrade, but a necessity for anyone serious about domain intelligence.

RDAP, or Registration Data Access Protocol, emerged from the Internet Engineering Task Force (IETF) and ICANN as the standardized, next-generation solution. Unlike WHOIS, which often requires a human to interpret varying output formats from hundreds of different registrars, RDAP delivers machine-readable, structured data, typically in JSON format. A query returns a well-defined object: the domain handle, an events array carrying registration, expiration and last-changed timestamps, a nameservers array, a status array using standardized EPP-derived values, and an entities array describing the registrar and any contacts the registry chooses to publish. Every field has a name, a type and a place in the schema, which is exactly what WHOIS never had.

Scale is what makes this matter. Hundreds of millions of domain names are registered globally, and manually checking WHOIS records for even a thousand of them is impractical. Automating it with WHOIS means writing and maintaining parsers for hundreds of unique output formats, a permanent battle against inconsistency and silent format changes. Privacy regulation compounded the problem: after GDPR came into force, registrars began redacting or proxying registrant contact fields in WHOIS output as a matter of routine, and the same redaction carries over into RDAP. The practical consequence is that WHOIS lost most of its remaining value as a contact source, while its parsing problems stayed exactly where they were.

RDAP directly addresses these challenges. It provides a consistent query and response mechanism, offering a standardized structure for domain registration data regardless of the registrar or Top-Level Domain (TLD). This includes information about the domain, its registrar, creation and expiration dates, name servers, and often, more structured contact information (where legally permitted) or at least organizational identifiers. For instance, instead of trying to extract a "registrant email" from a block of text that might be labeled "Admin Contact," "Registrant Email," or "Contact Email," RDAP provides distinct JSON fields for these attributes, making data extraction precise and reliable.

Consider a real-world scenario: a B2B SaaS company specializing in website security wants to identify potential clients running older, less secure hosting environments. With traditional WHOIS, they'd have to scrape thousands of records, manually identify hosting providers from name server entries (which are often obscured), and then attempt to find any contact information, battling redaction all the way. The process is slow, error-prone, and yields low-quality leads.

RDAP fixes the format problem, and only the format problem. It gives you reliable, comparable technical metadata: which registrar sponsors a domain, when it was created and when it expires, which name servers it delegates to, and what administrative status codes apply. That is genuinely useful for infrastructure analysis, for tracking registrar and DNS provider market share, and for spotting domains whose registration or delegation pattern looks unusual. What it does not do is restore the registrant directory that existed before 2018. Any workflow that assumes RDAP will hand back a contact person is built on a false premise, and it will fail on the overwhelming majority of gTLD domains.

The shift to RDAP is an industry standard, documented in RFCs like RFC 7480, 7481, 7482, 7483, and 7484. These define the protocol, query and response structure, and security considerations, ensuring a robust and future-proof foundation for domain data access. By adopting RDAP, ICANN and the internet community are moving towards a more secure, efficient, and machine-friendly way to query and receive registration data, essential for maintaining the stability and utility of the internet. For businesses, this means moving from a manual, guesswork-laden approach to a data-driven, automated strategy for identifying and engaging with their target market. WebTrackly puts this power directly into your hands, transforming raw RDAP data into actionable insights for your sales, marketing, and data teams.

What RDAP Does Not Give You: Redaction, Rate Limits and Scale

It is worth being explicit about the boundaries of the protocol, because a lot of published material about RDAP quietly overstates them.

• Registrant contact data is redacted by default. Under ICANN's registration data policy, gTLD RDAP responses omit or mask registrant, administrative and technical contact details for the general public. A typical response contains a registrar entity with an abuse contact, and a registrant entity whose vCard fields are removed or replaced with a proxy address. There is no public tier that returns the underlying values, and requesting them requires an accredited, purpose-limited disclosure request handled case by case.
• Coverage is uneven across TLDs. RDAP is mandatory for gTLDs. Many ccTLD registries run it voluntarily, some run it with reduced fields, and a few still only offer WHOIS or a web form. The IANA bootstrap registry tells you which server is authoritative for a given TLD, but it cannot tell you what that server will choose to publish.
• Rate limits make bulk lookup impossible. Registry and registrar RDAP endpoints are protected against automated harvesting. Sequential lookups measured in millions of domains are not a supported use of the protocol, and attempting them results in throttling or blocking. This is a design decision, not an obstacle to be engineered around.
• Responses describe registration, not the website. RDAP knows nothing about which CMS a site runs, which CDN sits in front of it, or whether it resolves at all. That information comes from DNS and HTTP observation, which is a separate data collection problem.

These limits determine which questions you can answer with a lookup and which ones require a bulk dataset. Asking "what is the registrar and expiry of this one domain" is a lookup. Asking "how many domains in this zone delegate to Cloudflare name servers" is a dataset question, and no amount of querying will make it a lookup.

Where Domain-Level Data Is Actually Useful

Structured registration and infrastructure data supports a narrower but more defensible set of use cases than the marketing around domain intelligence usually suggests. The three below work with what is genuinely available: technical metadata about domains, not information about the people behind them.

Attack surface and infrastructure research

Target Audience: Cybersecurity service providers, penetration testing firms, incident response teams, threat intelligence analysts.

Problem: Identifying organizations running potentially vulnerable or outdated infrastructure is a manual, time-consuming process. Traditional WHOIS data is too inconsistent and often redacted to effectively map domains to their underlying technology stack or registrar patterns that might indicate risk. Attack surfaces are vast, and proactive identification of targets using specific, exploitable configurations is critical but challenging.

What the data supports: zone-level files let a security team enumerate the domains in a TLD, resolve their delegation and mail infrastructure, and cross-reference detected CMS platforms against known-vulnerable versions. Working from a full zone rather than a sampled list means the denominator is real: you can say how many domains in a zone use a given name server operator or mail provider, rather than how many appeared in whatever sample you managed to collect. RDAP then fills in per-domain registration metadata for the smaller shortlist that comes out of that analysis, which is a volume the protocol can comfortably serve.

What the data does not support: it will not tell you who to contact inside those organizations. Building an outreach list is a separate exercise that has to rely on information those organizations publish about themselves, and it is not something a domain dataset provides.

Market sizing for SaaS founders and product teams

Target Audience: SaaS founders, product managers, market researchers, venture capitalists.

Problem: Validating a new SaaS product idea requires deep market understanding: who are the potential customers, what technologies do they currently use, and how large is the addressable market? Relying on anecdotal evidence or broad industry reports is insufficient. Founders need granular data on technology adoption and underlying infrastructure.

What the data supports: counting. If your product targets WordPress sites, the size of the addressable population is a countable quantity rather than an estimate: across the zones covered here, 21,639,326 domains are detected as WordPress and 607,765 as Joomla. If your product is region-specific, per-zone files let you scope the count to the TLDs that matter. Comparing counts across zones or across snapshots taken at different times shows where a platform is gaining or losing ground, which is a far stronger input to a business case than a vendor's published market share chart.

How to run it: take the enriched set for the zones in scope, count rows by detected CMS and by name server operator, and repeat with a later snapshot when you want a trend rather than a point estimate.

Building datasets for analysis and machine learning

Target Audience: Data scientists, data engineers, researchers, business intelligence analysts.

Problem: Building comprehensive datasets for large-scale analysis, machine learning models, or trend forecasting is hampered by inconsistent data sources. Traditional WHOIS data is unstructured, requires extensive cleaning and parsing, and often lacks the consistency needed for robust data pipelines. Integrating disparate data points from various web sources is complex and time-consuming.

What the data supports: a stable, columnar starting point. Each enriched per-zone file is a CSV with one row per domain and a fixed set of columns, which loads directly into pandas, DuckDB, ClickHouse or a warehouse without a parsing stage. Domain, name servers, MX, IP and detected CMS are all usable as features: hosting and mail provider concentration, delegation patterns, and platform choice are informative signals for classification tasks such as separating parked domains from active sites, or clustering domains by infrastructure operator. Where a registry publishes registration dates, those are included and give the dataset a temporal dimension.

Caveats worth building in: detection is observational and will lag reality for sites that changed recently; a domain present in a zone file is registered but not necessarily serving content; and absence of an MX record means no mail is configured for that name, not that the organization has no mail.

What WebTrackly Provides: Bulk Domain Data Packages

WebTrackly is a catalog of downloadable domain data, not a search interface and not a contact database. There are 1,538 packages in the catalog, organized into four groups.

Coverage across those zones is 279,944,703 domains. The largest single zone is .com at 163,422,083 domains. On the technology side, 21,639,326 domains are detected as WordPress and 607,765 as Joomla. The largest curated dataset, all registered domains, contains 272,614,863 rows.

Delivery is deliberately simple. Every package is a CSV inside a ZIP archive, downloaded immediately after purchase, and the export is generated fresh at the moment of purchase rather than served from a stale pre-built file. One-time purchases start at $3.50. Two subscription plans are available for continuous use: Pro at $29/month covers 50 packages plus 10 datasets and 30,000 API calls, and Enterprise at $99/month covers 200 packages plus 50 datasets and 300,000 API calls.

The catalog is browsable at /packages/, with zone files listed under /zones/, technology-based lists under /domaindata/ and cross-zone compilations under /datasets/. Plan details are on /pricing/.

Data Schema: What Is Inside the CSV

An enriched per-zone package unzips to a CSV with one row per domain and the following columns.

Plain zone file packages contain the domain column only. Technology lists contain the domains on which a given platform was detected.

It is equally important to state what the files do not contain:

• No personal contacts of any kind. No names, no email addresses, no phone numbers, no social profiles.
• No registrant identity data. Registration date is registry-published metadata; the registrant behind a domain is not part of these files.
• No intent, firmographic or company-size signals.
• No traffic, ranking or revenue estimates.

If your requirement is a list of people to contact, these datasets are the wrong input, and no filter or export option will change that.

Using the Catalog API

The API serves the catalog: it lets you discover which packages exist, inspect their metadata and automate purchasing and download. It is not a per-domain lookup endpoint, and there is no query interface that returns individual domain records. Every request carries a bearer token.

List the zone file packages:

curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://webtrackly.com/api/v1/packages/?type=zone"

Search the technology packages:

curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://webtrackly.com/api/v1/packages/?type=technology&q=wordpress"

Fetch the detail record for a single package, including its row count and current price:

curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://webtrackly.com/api/v1/packages/{slug}/"

A typical automation pattern is to poll the catalog for the packages your pipeline depends on, compare the reported row counts against your last ingest, and trigger a fresh download when a zone has grown or shrunk meaningfully. API call allowances are 30,000 per month on Pro and 300,000 per month on Enterprise, which is ample for catalog polling and well beyond what a scheduled pipeline needs. Full endpoint documentation is at /api/.

Processing the Files Locally

The workflow is short: pick a package, buy it, download the ZIP, and process the CSV on your own machine. Because the files are plain CSV, standard command line tools handle the first pass and a columnar engine handles everything after that.

Unzip and look at the shape of the data:

unzip com-enriched.zip
head -3 com-enriched.csv
wc -l com-enriched.csv

For a single-zone file, grep and awk are often enough:

# domains delegating to Cloudflare name servers
grep -i 'ns.cloudflare.com' com-enriched.csv | wc -l

# domains with Google Workspace mail
grep -i 'aspmx.l.google.com' com-enriched.csv | wc -l

For anything analytical, load the CSV into DuckDB. It reads the file in place, so there is no import step:

duckdb -c "
  SELECT cms, count(*) AS domains
  FROM read_csv_auto('com-enriched.csv')
  WHERE cms IS NOT NULL
  GROUP BY cms
  ORDER BY domains DESC
  LIMIT 20;
"

For repeated queries across many zones at once, ClickHouse is the better fit. Create a table with the six columns, load the CSVs, and aggregations over hundreds of millions of rows run in seconds:

clickhouse-client --query "
  CREATE TABLE domains (
    domain String, reg_date Nullable(Date),
    ns String, mx String, ip String, cms String
  ) ENGINE = MergeTree ORDER BY domain"

clickhouse-client --query "INSERT INTO domains FORMAT CSVWithNames" < com-enriched.csv

A note on scale: the all-registered-domains dataset is 272,614,863 rows, so plan for tens of gigabytes uncompressed and use a columnar store rather than a spreadsheet. Individual zone files are much smaller and most of them open comfortably in DuckDB on a laptop.

Common Mistakes When Working With RDAP Data

RDAP is straightforward to query and easy to misread. These are the errors that most often produce misleading conclusions.

1. Mistake: Over-reliance on Direct Contact Information from Raw RDAP.

   • What Goes Wrong: Many users expect RDAP to provide direct, unredacted email addresses and phone numbers for registrants. Due to privacy regulations (like GDPR) and registrar policies, much of this information is often redacted, proxied (e.g., [email protected]), or simply not available directly through RDAP. Relying solely on raw RDAP for contact info will yield extremely low-quality or empty lead lists.
   • Why: ICANN's Temporary Specification for gTLD Registration Data and various national privacy laws mandate the protection of personal data. Registrars comply by redacting or masking contact details.
   • The Fix: treat RDAP as a source of technical metadata and nothing else. Registrar, dates, name servers and status codes are reliable; contact fields are not. If your project needs to reach organizations, that has to come from information those organizations publish themselves, gathered under whatever legal basis applies to your jurisdiction and use case. No domain data product, including this one, supplies registrant contacts, and any vendor claiming to extract them from RDAP is describing something the protocol does not do.

2. Mistake: Ignoring the Nuances of RDAP Status Codes.

   • What Goes Wrong: RDAP provides detailed status codes (e.g., clientDeleteProhibited, serverHold, pendingDelete). Misinterpreting these can lead to targeting domains that are not active, are in dispute, or are about to expire. For example, targeting a pendingDelete domain for a sales pitch is a waste of time.
   • Why: These codes indicate the current administrative state of a domain. They are critical for understanding its availability and stability.
   • The Fix: learn the EPP status vocabulary that RDAP reuses. clientTransferProhibited is a normal lock and says nothing negative about a domain; serverHold means the domain is not being published in DNS; pendingDelete means it is in the deletion cycle and will drop shortly; redemptionPeriod means it has already expired and can still be restored by its registrant. Decide explicitly which statuses your analysis includes, and record that decision alongside your results so the numbers can be reproduced.

3. Mistake: Assuming Data Freshness is Universal and Instantaneous.

   • What Goes Wrong: Believing that all RDAP data is real-time and universally updated across all registrars simultaneously. While RDAP is designed for programmatic access, registrars have varying update cycles, and propagation delays can occur.
   • Why: Domain registration data flows through multiple parties (registrant, registrar, registry). Updates aren't always instantaneous across the entire ecosystem.
   • The Fix: treat every dataset and every lookup as a snapshot with a timestamp, and store that timestamp with the data. Bulk files reflect the state of a zone at the moment the export was generated; RDAP reflects the state of one domain at the moment of the query. Neither is a live feed. For trend work this is an advantage rather than a limitation, since comparing dated snapshots is what makes a trend measurable in the first place.

4. Mistake: Neglecting Rate Limits and Fair Use Policies.

   • What Goes Wrong: Aggressively querying RDAP servers directly or through a platform's API without regard for rate limits can lead to IP bans, temporary blocks, or service degradation. This is especially true if attempting to scrape raw RDAP.
   • Why: RDAP servers, like any public API, are protected against abuse. Even WebTrackly's API has rate limits to ensure fair usage for all customers.
   • The Fix: do not attempt bulk enumeration over RDAP. Reserve lookups for cases where you need current, authoritative detail on a specific domain, implement exponential backoff and honour Retry-After headers when you do, and use bulk files for anything population-scale. Trying to reconstruct a zone through per-domain queries is both slower and less complete than downloading the zone.

5. Mistake: Misinterpreting "Registrar" vs. "Hosting Provider".

   • What Goes Wrong: Confusing the entity that registered the domain (Registrar, found in RDAP) with the entity that hosts the website's content (Hosting Provider, found via DNS/IP lookups). A domain registered with GoDaddy might be hosted on AWS, and vice-versa.
   • Why: These are distinct services. A registrar manages the domain name itself, while a hosting provider serves the website files.
   • The Fix: keep the two attributes in separate columns and never infer one from the other. The registrar comes from RDAP. The hosting and mail providers are inferred from the name server, MX and IP columns of a bulk file. A zone file will show you, for example, that a domain delegates to Cloudflare name servers while its A record points at a completely different provider, which is exactly the kind of distinction that gets lost when the two concepts are merged.

6. Mistake: Ignoring Legal and Ethical Compliance (GDPR, CCPA, Acceptable Use).

   • What Goes Wrong: Using extracted data, especially contact information, without regard for privacy regulations or the acceptable use policies of data providers. This can lead to legal penalties, reputational damage, and account termination.
   • Why: Data privacy laws are strict. Even if data is publicly available, its collection and use must comply with regulations like GDPR and CCPA.
   • The Fix: know which legal regime applies to the data you hold. Domain, name server, MX, IP and detected CMS are technical attributes of infrastructure, not personal data about identifiable individuals, which is why bulk domain files are comparatively straightforward to work with. The moment you combine them with information about people, you are processing personal data and the full weight of GDPR, CCPA and equivalent regimes applies. Keep that boundary visible in your own pipeline rather than discovering it during an audit.

Avoiding these mistakes keeps RDAP-based analysis defensible: correct about what the protocol reports, explicit about what it omits, and honest about the difference between a snapshot and a live view.

FAQ

Q: What exactly is RDAP and how is it different from WHOIS?
A: RDAP (Registration Data Access Protocol) is the modern, standardized replacement for the outdated WHOIS protocol. The key difference is that RDAP provides structured, machine-readable data (typically in JSON format), while WHOIS outputs free-text, inconsistent information that varies widely by registrar. This structured format makes RDAP data much easier to parse, analyze, and integrate into automated systems. RDAP also offers enhanced security features and internationalization support, making it superior for programmatic access and global domain intelligence.

Q: Can I get registrant names, emails or phone numbers from RDAP?
A: No, not at any useful scale. gTLD RDAP responses are redacted by default under ICANN policy, and most registries return a proxy or empty value for registrant contact fields. Disclosure exists only as an accredited, purpose-limited request process handled case by case. WebTrackly's datasets do not contain personal contacts either: domain, registration date where published, name servers, MX, IP and detected CMS are the full extent of what the files carry.

Q: Does WebTrackly offer a per-domain lookup or a search interface?
A: No. The product is a catalog of downloadable packages. You select a package covering the zone, technology or compilation you need, purchase it, and download a CSV inside a ZIP. There is no interface for querying an individual domain and no filtered search over the underlying rows; the filtering happens on your side, after download.

Q: What formats and delivery are available?
A: Every package is delivered as a CSV inside a ZIP archive, downloadable immediately after purchase. The export is generated at the moment of purchase, so it reflects the current state of the data rather than a pre-built file of unknown age. The API returns catalog metadata as JSON.

Q: How large are the datasets?
A: Coverage is 279,944,703 domains across 716 zones. The .com zone alone accounts for 163,422,083 domains. The all-registered-domains dataset contains 272,614,863 rows. Technology lists are smaller and more focused: 21,639,326 domains for WordPress, 607,765 for Joomla.

Q: What does the catalog API do?
A: It exposes the package catalog. GET /api/v1/packages/?type=zone lists zone packages, GET /api/v1/packages/?type=technology&q=wordpress searches technology packages, and GET /api/v1/packages/{slug}/ returns the detail record for one package. Requests are authenticated with an Authorization: Bearer YOUR_API_KEY header. Allowances are 30,000 calls per month on Pro and 300,000 on Enterprise.

Q: What does it cost?
A: One-time package purchases start at $3.50. For ongoing use there are two plans: Pro at $29/month, which covers 50 packages plus 10 datasets and 30,000 API calls, and Enterprise at $99/month, which covers 200 packages plus 50 datasets and 300,000 API calls. Details are on the pricing page.

Q: How should I load a file this large?
A: Unzip it and query it with a columnar engine. DuckDB reads CSV in place and handles a single zone file comfortably on a laptop; ClickHouse is the better choice when you want repeated aggregations across many zones or the full cross-zone compilation. Spreadsheets are not a realistic option at these row counts.

Conclusion

The move from WHOIS to RDAP is a genuine improvement, but a narrow one. It solves the format problem: registration metadata now arrives as JSON with a documented schema, standard HTTP semantics and a bootstrap registry that tells you where to ask. It does not solve the access problem, and it was never intended to. Registrant contact data was removed from public registration records by policy, and RDAP faithfully reproduces that decision.

What this means in practice is that domain data is technical data. Registrar, dates, name servers, mail configuration, resolved addresses and detected platforms are all real, comparable and available at scale. Questions framed in those terms are answerable with precision. Questions that assume a directory of registrants are not answerable at all, by any tool.

If your work needs population-level answers about domain infrastructure, bulk files are the practical route: pick the zone, technology list or compilation you need from the package catalog, download the CSV, and analyse it locally with tools you already control.

Related Resources

• Package Catalog — 1,500+ downloadable domain databases
• Zone Files by TLD — .com, .net, .de and 700+ more
• Curated Datasets — all registered domains, MX servers, e-commerce
• Pricing — one-time purchases from $3.50