RDAP Registration Lookup Guide (Domains & IP Addresses)

RDAP (Registration Data Access Protocol) is the modern replacement for the legacy WHOIS protocol. All DataPulse registration tools use RDAP.

Use datapulse_live_rdap for all registration lookups — domains and IP addresses.

datapulse_live_rdap

Supports domain names (including IDN, and emoji or symbol names as registries actually sold them, raw or punycode) and IP addresses (IPv4 and IPv6). A domain is reduced to its registrable name under the full Public Suffix List, private suffixes included, before the lookup: www.Example.COM. is looked up as example.com, www.microsoft.jp.net as microsoft.jp.net, and the response then carries submitted_domain with what you sent. RDAP is the only tool family that removes hostname labels, because registries only know registered names; the DNS tools (datapulse_live_dns, datapulse_dns_dphistory, datapulse_live_domain_health, datapulse_dns_dptechsim, datapulse_dns_neighborhood) canonicalize the spelling and keep the hostname. A single label (localhost, com) is refused, and so is a registrable domain with an underscore (exa_mple.com), which no registry registers; _dmarc.example.com is looked up as example.com. The rules for every tool are in datapulse_help(topic="normalization").

Parameters

Lookup Strategy

For domain queries, the tool uses a two-step strategy:

1. DataPulse API (fast path): Checks the DataPulse database for cached RDAP summary data. Near-instant.
2. Scrape API (fallback): If not found in DataPulse (or if force: true), performs a live RDAP lookup via the Scrape API.

Both sources return the same compact summary format (see Response Format below).

For IP address queries, the tool goes to the Scrape API, which answers from its own cache when it has a recent result (a lookup can be served from a result several weeks old) and otherwise queries the RIR; force: true refreshes. The response format for IP lookups differs from domain lookups.

Response Format

Domain lookups

Both the DataPulse fast path and Scrape API fallback return the same compact summary. Every response uses the envelope {query, type, datetime, results}, where type is "domain" or "ip":

{
  "query": "example.com",
  "type": "domain",
  "datetime": "2026-03-20T18:16:46Z",
  "results": [
    {
      "name": "example.com",
      "researchdate": "2026-02-03T21:07:05Z",
      "ianaid": 3827,
      "registrationdate": "2026-01-30T22:30:36Z",
      "expirationdate": "2027-01-30T22:30:36Z",
      "status": ["client delete prohibited", "client transfer prohibited"],
      "dns": ["ns-cloud-a1.googledomains.com", "ns-cloud-a2.googledomains.com"],
      "abuse_email": "abuse-complaints@squarespace.com",
      "abuse_phone": [{"type": "voice", "value": "tel:1-646-693-5324"}]
    }
  ]
}

Field reference:

The envelope also carries submitted_domain when normalisation changed the name you sent (IDN folded to punycode, a subdomain or trailing dot dropped, a fullwidth homograph folded to ASCII); it is absent when only letter case differed. Note the expiry field is expirationdate here and in the overview’s rdap block, but expiration_date in datapulse_dns_rdap_history and in the overview summary; the two tools come from different DataPulse services and the names are kept as each service publishes them.

IP address lookups

IP lookups use the same envelope with type: "ip"; each result object is a compact network summary. Only network_name, start_address, end_address and researchdate are always present; handle, type, cidr, country, organization, registration_date, last_changed, status, abuse_email, abuse_phone and port43 appear when the RIR publishes them, and the RIRs differ:

• ARIN omits country. Country codes are case-folded to lower case whatever the RIR published (RIPE’s IPv6 objects say ie where its IPv4 objects say NL; both come back as lower case).
• organization is whatever the RIR published as the registrant entity, which for some RIPE objects is a maintainer handle (MNT-…) rather than an organisation name.
• LACNIC puts the prefix in handle and omits cidr.
• AFRINIC and APNIC sometimes publish no abuse contact, so abuse_email/abuse_phone are absent.

Timestamps are returned as the RIR published them (ARIN uses a -05:00 offset where the others use Z, and precision varies), so parse them rather than comparing strings.

Lookup errors

When a lookup fails (domain does not exist, TLD has no RDAP server, timeout), the tool returns an error carrying the API’s HTTP status and its response body verbatim. Common failure causes:

• Domain does not exist (NXDOMAIN)
• TLD has no RDAP server (some ccTLDs — this is an RDAP protocol limitation, not a DataPulse coverage gap; ccTLD domains are fully covered by search, history, and clustering tools)
• IP address not allocated or not found in RIR database
• Registry/RIR rate limiting or timeout

Caching Behavior

• DataPulse database is checked first for domain queries. Data freshness depends on the DataPulse research schedule.
• Use force: true to skip the DataPulse cache and force a fresh live lookup via the Scrape API.
• A forced live lookup does not add an observation to datapulse_dns_rdap_history; history is the collector’s own crawl schedule.
• The single tool and datapulse_live_rdap_bulk use different caches: the single tool answers from the DataPulse database when it can, while bulk consults only the Scrape API’s own 90-day cache (so cached in a bulk receipt is usually nonzero) and queues a job for anything not in it. A domain the single tool answers from the DataPulse database can therefore be researched again by a bulk submission.
• When diagnosing why a domain is missing from listings, always use force: true — clients need current registry status, not a cached snapshot. See datapulse_help(topic="why_missing").

Bulk Lookups

For bulk RDAP lookups (up to 1000 domains or IPs per request), use datapulse_live_rdap_bulk. Supports mixed queries — domains and IP addresses can be submitted together. This is async — returns job receipts, not results. Retrieve individual results afterward by calling datapulse_live_rdap(query=...) for each query; completed lookups return the cached result instantly.

Every item is validated before anything is sent. A malformed or blank query, a single label, an underscore domain or a reserved address is reported in rejected_local and the rest of the batch still goes through; a query repeated in the batch is submitted once and listed in duplicates; domains are reduced to the registrable name exactly as the single tool does. The receipt for six inputs:

{
  "accepted": 1, "rejected": 0, "cached": 2,
  "batch_id": "f47ac10b-...",
  "submitted": [
    {"index": 0, "query": "example.com", "domain_hash": "a379a6f6...", "job_id": "550e8400-...", "cached": false},
    {"index": 2, "query": "8.8.8.8", "domain_hash": "838c4c25...", "cached": true},
    {"index": 5, "query": "xn--bcher-kva.com", "domain_hash": "9c1d...", "cached": true}
  ],
  "rejected_items": [],
  "rejected_local": [
    {"index": 1, "query": "127.0.0.1", "error": "invalid query \"127.0.0.1\": 127.0.0.1 is a loopback address and has no RIR registration"},
    {"index": 4, "query": "not a domain!!", "error": "invalid query \"not a domain!!\": ..."}
  ],
  "duplicates": [{"index": 3, "query": "WWW.Example.COM.", "first_index": 0}],
  "job_ids": ["550e8400-..."], "domain_hashes": ["a379a6f6...", "838c4c25...", "9c1d..."], "errors": []
}

Every input is accounted for: accepted + cached + rejected + len(rejected_local) + len(duplicates) equals the number of items you passed (1 + 2 + 0 + 2 + 1 = 6).

• submitted[].index is the position in your domains array; query is the normalised form that was sent; domain_hash is the hex SHA-256 of that query and the key datapulse_live_rdap answers from. The name is historical: for an address it is the hash of the address text (the same value datapulse_live_rdap uses), not of any domain. job_id and cached come from the API’s per-item report and are absent when it sends none; nothing is inferred from the flat job_ids list. submitted is what was sent, not what was accepted: an item the API refuses stays listed, without a job_id, and also appears in rejected_items.
• accepted, cached and rejected are the API’s own counts over the items that were sent. rejected_items (index, query, error) lists what the API refused, with its code.
• rejected_local (index, query, error) lists what was refused before the request, with the reason. These are not counted in rejected, because the API never saw them. To find every failure, read both lists.
• domain_hashes and job_ids are the API’s flat lists in its own order (addresses included, under the same historical name); use submitted to map anything back to an input.
• errors holds only the API’s own rejection codes. Since every item is validated first, it is [] unless the API refused something that passed validation; do not read an empty errors, or rejected: 0, as “nothing was rejected” — check rejected_local.

Interpreting Registration Data

Domain Status Codes

Best practice: All three client*Prohibited statuses should be present.

Lock depth as an ownership signal. The status array is also one of the better available signals for who runs a domain, because it reflects a configuration the owner chose. Corporate portfolios typically carry the three client*Prohibited codes plus the three registry-level server*Prohibited codes, which retail registrars generally do not offer. A lone client transfer prohibited is the default on nearly every retail registration — it is the absence of a posture rather than a posture. When you need to judge whether a brand-carrying domain belongs to that brand, diff its status array against a domain the brand certainly owns; lock depth is more reliable than the registrar name, which misreads acquisitions, regional offices, and legacy registrations. See datapulse_help(topic="brand_adjacent").

In the RDAP summary, status codes appear in the status array (e.g., ["client transfer prohibited", "client delete prohibited"]). In WHOIS, they appear as Domain Status: lines.

Dates

Registrar

The ianaid field is the IANA-assigned registrar ID. Use datapulse_dns_registrar(iana_id=...) to look up registrar details.

Nameservers

The dns array contains the authoritative nameservers. These should match NS records from DNS. Mismatches indicate:

• Recent migration (propagation delay)
• Misconfiguration
• Potential hijacking

GDPR Impact

Post-2018, most registrars redact contact information. The RDAP summary provides the registrar’s abuse contact (abuse_email, abuse_phone) but individual registrant details are typically not available.

In practice this means RDAP responses contain registrar data, not registrant (owner) data. abuse_email/abuse_phone are the registrar’s abuse desk — not the domain owner’s contact — and must never be presented as the registrant. One case looks like an exception and is not: some registries let an organisation act as its own registrar (Nominet “tags” under .uk, for example, so bbc.co.uk shows nominet.admins@bbc.co.uk). The field is still the sponsoring registrar’s published contact; that the registrar and the registrant are the same organisation is a fact about the registration, not a registrant lookup. There is also no reverse-WHOIS: neither DataPulse nor public RDAP can search registrations by registrant email, name, or organization. For the full explanation and alternative approaches, see datapulse_help(topic="registrant_lookup").

TLD-Specific Notes

.com / .net (Verisign)

• Full RDAP support
• Most complete data for major registrars

.org (PIR)

• Good data quality

.io (Identity Digital)

• Often heavily redacted
• Privacy services common

.co.uk (Nominet)

• Standard RDAP format
• “Data validation” indicates verified registrant

.eu (EURid)

• Very restricted
• Often requires web lookup

TLDs without RDAP

Some ccTLDs have no RDAP server; .de (DENIC) is the best-known example — DENIC publishes only a web WHOIS. datapulse_live_rdap returns an error for these (“No RDAP servers found for …”).

Important: This is a limitation of the RDAP protocol, not of DataPulse data coverage. DataPulse maintains one of the most comprehensive domain databases available (400M+ domains across all TLDs including ccTLDs). Domain search (datapulse_dns_searchlabels), DNS history (datapulse_dns_dphistory), infrastructure similarity (datapulse_dns_dptechsim), and cluster analysis (datapulse_dns_neighborhood) all cover ccTLD domains. Only live RDAP registration lookups are affected by missing RDAP servers.

For how that corpus is built — the PSL+1 unit of analysis, full PSL registry coverage (ICANN, non-ICANN, and ccTLD registries), wildcard-aware collection, discovery sources, and the active-and-functioning quality gate that decides what is admitted — see datapulse_help(topic="methodology").