RDAP History

The datapulse_dns_rdap_history tool returns every RDAP observation DataPulse has taken of a domain — registrar, abuse contact, status, nameserver and registration-date data over time — straight from the DataPulse API.

Overview

Live RDAP (datapulse_live_rdap) shows the current registration state. RDAP history shows how that state has changed over time. It is the right tool for:

• Detecting registrar transfers — diff ianaid across consecutive results entries. A change means the domain moved between registrars.
• Abuse-contact provenance — when an abuse complaint references an abuse_email or abuse_phone that no longer matches live RDAP, this tool shows when the contact changed and what it used to be.
• Long-term infrastructure shifts — pairs naturally with datapulse_dns_dphistory (DNS history) for a full timeline.

datapulse_dns_rdap_history

Parameters

Example Usage

{
  "domain": "etauk-gov.com"
}

Response Format

The DataPulse API’s RDAP envelope. results holds every observation, newest first (researchdate descending), so results[0] is the newest scheduled crawl and the last entry is the oldest. Crawls are sparse — a few observations a year for a typical domain — and datapulse_live_rdap with force=true does not add one: live lookups and history are separate datasets. name, dns, status and registrant_cc are case-folded; every list stays in the order the API sent it:

{
  "query": "/dpdb/v1/rdap/etauk-gov.com",
  "datetime": "2026-09-16T14:23:33.859720623Z",
  "server_id": "alpha03",
  "results": [
    {
      "name": "etauk-gov.com",
      "researchdate": "2026-03-29T09:30:09.331513107Z",
      "ianaid": 625,
      "registrationdate": "2025-04-27T13:41:40Z",
      "expiration_date": "2027-04-27T13:41:40Z",
      "last_changed": "2026-03-25T13:22:29Z",
      "status": [
        "client transfer prohibited"
      ],
      "dns": [
        "ns1cmt.name.com",
        "ns2fgp.name.com",
        "ns3cpr.name.com",
        "ns4cfn.name.com"
      ],
      "abuse_email": "abuse@name.com",
      "abuse_phone": [
        {
          "type": "voice",
          "value": "tel:7202492374"
        }
      ]
    },
    {
      "name": "etauk-gov.com",
      "researchdate": "2025-04-29T02:38:33.656626304Z",
      "ianaid": 625,
      "registrationdate": "2025-04-27T13:41:40Z",
      "expiration_date": "2026-04-27T13:41:40Z",
      "last_changed": "2025-04-27T13:41:40Z",
      "status": [
        "client transfer prohibited"
      ],
      "dns": [
        "ns1cmt.name.com",
        "ns2fgp.name.com",
        "ns3cpr.name.com",
        "ns4cfn.name.com"
      ],
      "abuse_email": "abuse@name.com",
      "abuse_phone": [
        {
          "type": "voice",
          "value": "tel:7202492374"
        }
      ]
    }
  ]
}

query, datetime and server_id describe this API response (the request path, when it was answered, which API node answered), not the domain. The domain you send is reduced to its registrable name under the full Public Suffix List, private suffixes included — www.bücher.com. is looked up as xn--bcher-kva.com, www.microsoft.jp.net as microsoft.jp.net — and submitted_domain then carries what you sent; it is absent when only letter case differed. Whether the API holds a record for a private-suffix name is the API’s decision; the tool never reduces further. This and the other RDAP tools are the only ones that remove hostname labels; the DNS tools canonicalize the spelling and keep the hostname. A registrable domain with an underscore (exa_mple.com) is refused, because no registry registers one; _dmarc.example.com is looked up as example.com. See datapulse_help(topic="normalization").

Observation Fields

Each entry in results is the RDAP state observed on its researchdate:

An entry with error set is a failed collection, not a fact about the domain: its registration fields are empty. Skip it when diffing. Detect failures by error alone — never by ianaid == 0, which is also what every successful observation of a name under a registry without IANA registrar IDs carries.

A domain the API has never observed answers with the API’s own 404, returned as an error carrying that status and the response body verbatim; that is an answer, not an outage. Names under registries without RDAP (some ccTLDs) look the same.

Use Cases

Detecting Registrar Transfers

The defining use case. Walk the results array (newest first) and compare ianaid between consecutive entries:

results[0].ianaid = 1910   (Cloudflare)   ← current
results[1].ianaid = 625    (Name.com)
                   ─── transfer between observations

Resolve IANA IDs to registrar names with datapulse_dns_registrar.

Abuse Contact Provenance

When investigating a takedown that references an abuse contact that no longer appears in live RDAP, scan abuse_email and abuse_phone across the observations to find when (and to what) the contact was changed. Registrar transfers usually rotate the abuse contact at the same time.

Bulk Registration Correlation

Combine with datapulse_dns_regclusters (find candidate cluster) and datapulse_dns_neighborhood (find related domains by infrastructure) to build a picture of a campaign’s registrar choices over its lifetime.

Pairing with DNS History

datapulse_dns_dphistory shows nameserver, web-hosting ASN and MX changes. datapulse_dns_rdap_history shows registrar/abuse changes. Querying both for a single domain gives a two-track timeline that is hard to fake: a registrar transfer accompanied by a DNS overhaul looks very different from a routine nameserver swap.

Related Topics

• history — Historical DNS records (DNS, MX, NS, ASN over time)
• registrar — Resolve IANA IDs to registrar names
• regclusters — Bulk registration clusters by registrar
• neighborhood — Find related domains via shared infrastructure
• rdap — Live (current) RDAP lookup