WHOIS and RDAP lookup: a practical guide to domain registration data

People still say "WHOIS lookup" when they want domain registration data. The familiar term has outlived the protocol's position as the main source for generic top-level domains. Since 28 January 2025, RDAP has been the definitive service for gTLD registration data. A useful lookup guide in 2026 therefore needs to cover RDAP first and legacy WHOIS second.

The distinction matters, but the larger caution is simpler: registration data is not an ownership certificate. A public record may show the registrar, registration dates, nameservers, DNSSEC data, and EPP status codes. It may show a registrant organization or country when publication rules and consent allow it. It often will not identify a person, and it cannot prove who operates a website, who controls a registrar account, or why a domain was registered.

RDAP is now the gTLD starting point

ICANN announced that RDAP would replace the retiring WHOIS services as the definitive source for gTLD registration information on 28 January 2025. ICANN-accredited registrars and gTLD registries had offered RDAP since 2019, so the change was a contractual cutover rather than the launch of a new protocol.

What changed between WHOIS and RDAP

WHOIS, documented in RFC 3912, uses a text request over TCP port 43 and returns free-form text. It has no standard response schema, built-in authentication, reliable internationalization, or transport security. Operators developed local conventions, but clients still had to recognize different labels and error messages.

RDAP is a family of standards rather than a single document. RFC 7480 defines its use of HTTP. RFC 7482 defines query paths for domains, nameservers, IP networks, and autonomous system numbers. RFC 7483 defines JSON responses. RFC 9224 explains how a client finds the authoritative service through IANA bootstrap registries. Calling RFC 9224 the entire RDAP specification misses the parts that define transport, queries, and response objects.

• WHOIS returns operator-specific text; RDAP returns typed JSON objects.
• WHOIS referrals are convention-driven; RDAP uses HTTP links, redirects, and authoritative bootstrap data.
• WHOIS has no protocol-level access control; RDAP can support authenticated and differentiated access.
• WHOIS error text can resemble a normal response; RDAP uses HTTP status codes and structured notices.
• RDAP supports internationalized registration data more cleanly than the ASCII-era WHOIS protocol.

Structured transport does not make every registry's data identical. RDAP standardizes the shape of the response, not the amount of public data an operator must disclose. Registry policy, applicable law, the domain's state, and the source record still determine which fields are present.

What a public registration record can contain

For gTLDs, ICANN's Registration Data Policy sets the publication rules. The policy took effect on 21 August 2025 and was revised on 12 May 2026 for the handling of urgent lawful disclosure requests. It replaced the temporary and interim policy framework that followed GDPR. The public fields below should be read in that current policy context, not as universal promises for every TLD.

Registrar and registry fields

A gTLD response normally identifies the sponsoring registrar, its IANA ID, its URL, and its abuse contact details. The registry operates the top-level domain and maintains the authoritative registry database. The registrar manages the registration for its customer. Knowing the registrar gives you the correct place to start an abuse report, transfer inquiry, or disclosure request, but it says little about the registrant by itself. Large registrars serve millions of unrelated customers.

Creation, update, and expiration dates

The creation date records when the current registration was created. It is not proof that the same person or company has held the domain since that date. A domain can move between registrars without changing its creation date, and a deleted domain can later be registered again with a new creation date.

The updated date is also easy to overread. It means a registration data value changed, but the public record may not tell you which value or why. A nameserver edit, status change, registrar operation, or registry-side update can all affect it. The expiration field is a registry or registrar date associated with the current registration term. Renewal grace periods and registry policy mean the displayed date is not a precise forecast of when a domain will become available to someone else.

Nameservers and DNSSEC

Nameserver values identify the servers delegated to answer authoritatively for the domain. They can reveal a DNS provider, but provider infrastructure is shared. Two domains using Cloudflare, Route 53, or another large service are not necessarily related. Custom nameservers can be a stronger lead, though they still need corroboration from DNS records, certificates, web content, and other evidence.

DNSSEC data indicates whether the registration carries signed delegation material. That is useful for checking the registration side of a DNSSEC deployment. It does not, on its own, prove that every resolver will validate the domain successfully. A complete DNSSEC check also needs the live chain of trust and DNS responses.

Registrant and contact data

The current Registration Data Policy requires registrars to collect core registrant data, but collection does not mean unrestricted publication. Personal data may be redacted when required by law, and operators may apply redaction in other circumstances allowed by the policy. A registrant organization can be published when the registered name holder agrees to publication. Technical contact fields are optional under the current policy, and registrars may delete older administrative contact data after satisfying the policy's collection requirements.

When a public record says that a value is redacted, do not interpret the absence as suspicious behavior. Redaction is common and may follow law or operator policy. ICANN directs eligible requesters seeking nonpublic gTLD data to its Registration Data Request Service for participating registrars, or to the sponsoring registrar's own disclosure process. Access is assessed under the applicable rules; RDAP support does not automatically give an authenticated user private contact data.

A current RDAP example

The following excerpt came from Verisign's authoritative RDAP service for example.com at 00:52 UTC on 10 July 2026. The timestamp matters because registration data changes. The example is deliberately short, retaining the fields most useful for interpretation.

{
  "objectClassName": "domain",
  "handle": "2336799_DOMAIN_COM-VRSN",
  "ldhName": "EXAMPLE.COM",
  "status": [
    "client delete prohibited",
    "client transfer prohibited",
    "client update prohibited"
  ],
  "events": [
    {"eventAction": "registration", "eventDate": "1995-08-14T04:00:00Z"},
    {"eventAction": "expiration", "eventDate": "2026-08-13T04:00:00Z"},
    {"eventAction": "last changed", "eventDate": "2026-01-16T18:26:50Z"},
    {"eventAction": "last update of RDAP database", "eventDate": "2026-07-10T00:52:10Z"}
  ],
  "nameservers": [
    {"ldhName": "ELLIOTT.NS.CLOUDFLARE.COM"},
    {"ldhName": "HERA.NS.CLOUDFLARE.COM"}
  ],
  "secureDNS": {
    "delegationSigned": true
  }
}

This response shows a registered domain, three client-side restrictions, a registration date, an expiration value, a last-changed event, two delegated nameservers, and signed DNSSEC delegation. It does not identify a website operator or establish who has access to the registrar account. Example.com is reserved for documentation under RFC 2606, but that fact comes from the reservation policy, not from guessing at the registrant based on the RDAP fields.

How to read EPP status codes

EPP status codes describe a domain's allowed operations and lifecycle state. Codes beginning with client are set by the registrar. Codes beginning with server are set by the registry. Pending and period codes describe operations or grace periods in progress. A code tells you what state exists, not the cause. For example, clientHold means the registrar has told the registry not to activate the domain in DNS, but the public code does not say whether the reason is payment, validation, abuse handling, a court order, or an administrative mistake.

• ok: No prohibitions or pending operations apply. It normally appears alone.
• clientTransferProhibited: The registrar blocks transfer to another registrar.
• clientDeleteProhibited: The registrar blocks deletion of the registration.
• clientUpdateProhibited: The registrar blocks updates to the domain object.
• clientHold: The registrar has asked the registry not to activate the domain in DNS.
• serverTransferProhibited: The registry blocks transfer. The public code does not reveal the reason.
• serverHold: The registry has not activated the domain in DNS.
• pendingTransfer: A registrar transfer request is being processed.
• redemptionPeriod: The registrar requested deletion, but restoration may still be possible during the registry's redemption period.
• pendingDelete: The registration is in the deletion path after the applicable restoration window or cancellation of a restore request.
• autoRenewPeriod: The registry automatically extended the registration after the expiration date and an auto-renew grace period is active.

Locks are useful protection, but the word lock needs care. Client prohibitions can be routine registrar locks. Server prohibitions may come from a registry lock service or another registry action. Seeing several prohibitions together does not tell you who requested them or whether a security incident occurred. If a status affects a domain you manage, contact the sponsoring registrar with the exact code and timestamp.

A defensible lookup workflow

A good registration-data review starts by recording the source and lookup time. An authoritative RDAP response, a registrar-provided record, and a cached normalized API response are different forms of evidence. Without the timestamp, a later investigator cannot tell whether a discrepancy reflects a real change or two observations made at different times.

1. Normalize the domain, including its internationalized form, before comparing records.
2. Record the lookup source, protocol, and time.
3. Confirm the sponsoring registrar and note the abuse or disclosure route if the task may require contact.
4. Read all status codes as a set and avoid assigning a cause that the record does not state.
5. Compare creation, update, and expiration values, keeping their limits in mind.
6. Treat nameservers and DNSSEC as technical registration signals, not attribution evidence.
7. Note which contact fields are public, redacted, or absent without assuming why.
8. Corroborate important conclusions with live DNS, certificates, website disclosures, account records, contracts, or legal documentation.

This approach is less dramatic than trying to identify an owner from one lookup, and it produces better work. Registration data is strongest when answering narrow questions: which registrar sponsors the domain, which lifecycle restrictions apply, what dates are published, and which nameservers are delegated. Broader attribution needs broader evidence.

What the DomScan tools actually do

WHOIS Lookup

DomScan's WHOIS Lookup returns structured WHOIS and RDAP registration data for one domain. The service normalizes useful fields such as registrar, dates, nameservers, status, DNSSEC, and available contact or privacy indicators. RDAP is preferred where supported, with traditional WHOIS used for specific compatibility paths. A normalized response makes application code easier, but it does not create data that the source did not publish.

RDAP Lookup

DomScan's RDAP Lookup exposes the current raw RDAP object inside a DomScan response envelope. The API supports domains by default and accepts explicit query types for IP networks and autonomous system numbers. It preserves the authoritative object rather than presenting the result as a global ownership record. Use `GET /v1/rdap?query=example.com` for a domain, `type=ip` for an IP or CIDR, and `type=autnum` for an ASN.

Domain Profile

The Domain Profile provides a normalized registration profile. It covers registrar information, registration dates, status, nameservers, DNSSEC, events, and available privacy or contact fields. The profile uses authoritative RDAP when available and can use traditional WHOIS as a fallback. It is not the endpoint for live DNS records, hosting detection, technology detection, or reputation scoring. Those are separate tools and APIs.

WHOIS History

The WHOIS History page queries DomScan's observation log. It is not a global historical WHOIS archive. A qualifying fresh, successful, RDAP-backed single-domain request to `/v1/whois` or `/v2/whois` can record at most one normalized snapshot per domain per UTC day. Cached responses, bulk lookups, history reads, and traditional-WHOIS-only fallbacks do not add snapshots.

Stored comparisons cover registrar name, expiration value, nameservers, status, DNSSEC, transfer lock, and privacy or redaction detection. The snapshots do not contain registrant identity or contact history and do not prove an ownership change or registrar transfer. The returned summary describes only the requested observation window, up to the endpoint's limit, not every event that may ever have occurred.

Domain Monitor

Domain Monitor checks registration availability, expiration information, and registration status for domains on a user's watchlist. It can notify users about availability and expiration-related changes. It does not monitor arbitrary WHOIS field changes, DNS configuration, nameservers, certificates, or website content. Use the dedicated DNS, SSL, and history tools when those signals matter.

Where registration data helps

For domain operations, registration data can catch an unexpected registrar, a missing transfer lock, a hold that removed the domain from DNS, or an expiration date that needs attention. These checks are most reliable when compared with the organization's registrar account and renewal records. A public lookup should support internal records, not replace them.

During an abuse investigation, the registrar and abuse contact provide a route for reporting a suspicious domain. Creation dates and status codes can add chronology. Nameservers may reveal shared infrastructure worth examining. None of those facts identifies the actor behind a phishing page. Provider infrastructure is shared, contact data is often redacted, and a compromised legitimate domain can host abuse without a new registration.

For an acquisition or due-diligence review, a lookup can confirm that a domain is registered, show the public expiration value, and identify the sponsoring registrar. It cannot establish that the seller has authority to transfer the name. Verify control through the registrar account, an approved transfer process, contracts, escrow, and appropriate legal review. The same caution applies to merger inventories: public registration data is a useful cross-check, not the title record for a digital asset.

Common mistakes

• Calling every registration lookup WHOIS without recording whether the source was RDAP or port 43.
• Treating a registrant organization, privacy service, nameserver, or registrar as proof of the website operator.
• Assuming an updated date identifies the field that changed.
• Reading an expiration date as the exact moment a domain will become available.
• Assigning a legal, billing, or abuse cause to a hold when the status code gives no reason.
• Using shared provider nameservers as standalone evidence that domains have a common registrant.
• Describing a limited observation log as a complete archive of past registrants or ownership.

A current lookup is a snapshot of published registration data. Read the source, timestamp, fields, and omissions together. That is enough to answer many operational questions, and it also makes clear when the evidence stops.