RDAP Data Access Policy

Created by Matt W, Modified on Thu, 25 Jun at 1:50 AM by Matt W

Access to domain name registration data through the Registration Data Access Protocol (RDAP)


Document control
Policy ownerKiryl Nestsiarovich, Cybersecurity Officer
Issued byFewmoretaps OÜ (d/b/a Trustname.com)
Version1.0
Effective date24 June 2026
Approved byManagement Board, Fewmoretaps OÜ
Review cycleAt least annually, and on any material change in ICANN policy, the gTLD RDAP Profile, or applicable law
ClassificationPublic


Issuing entity Fewmoretaps OÜ, a private limited company (osaühing) incorporated in Estonia, trading as Trustname.com, an ICANN-accredited registrar (IANA Registrar ID 4318).

  • Estonian commercial registry code: 16354846
  • Registered address: Roseni 13, 10111 Tallinn, Estonia
  • Telephone: +372 6884747
  • Contact for this policy: privacy@trustname.com

In this policy, "Fewmoretaps", "Trustname", "we", "us" and "our" mean Fewmoretaps OÜ trading as Trustname.com.


1. Purpose

This policy explains how Trustname provides access to domain name registration data through the Registration Data Access Protocol (RDAP): what data is available without authentication, what is redacted, and how authorised parties may lawfully obtain non-public data. It gives effect to our obligations as an ICANN-accredited registrar and to Article 28(4) and 28(5) of Directive (EU) 2022/2555 (the NIS2 Directive) as transposed into Estonian law, and is made publicly available. This policy is companion to our Domain Name Registration Data Verification Policy and our Domain Name Registration Data Disclosure Policy / NPRD Disclosure Request Policy.

2. Scope

This policy applies to:

  • all generic top-level domain (gTLD) names sponsored by Trustname, and to applicable country-code TLDs where Trustname provides RDAP;
  • the RDAP service that Trustname operates or procures;
  • both public (unauthenticated) access and access to non-public registration data; and
  • all parties querying the service.

For ccTLDs, the relevant registry's own access policies apply where they differ from this policy.


3. Legal, contractual and technical basis

This policy is to be read together with:

  • the ICANN Registrar Accreditation Agreement (RAA) and the gTLD RDAP Profile (the ICANN RDAP Response Profile and RDAP Technical Implementation Guide);
  • the ICANN Registration Data Policy (effective 21 August 2025), which governs the collection, publication, retention and disclosure of gTLD registration data, and under which gTLD registrars are no longer required to provide the legacy WHOIS (port 43) service for most TLDs following the WHOIS sunset of 28 January 2025;
  • the IETF RDAP standards, including RFC 9082 (query format), RFC 9083 (JSON responses), RFC 7481 (security services / HTTPS), RFC 9224 (finding the authoritative RDAP service — bootstrap), and RFC 9537 (redacted fields);
  • Article 28 of the NIS2 Directive and the Estonian Cybersecurity Act (Küberturvalisuse seadus), as amended; and
  • Regulation (EU) 2016/679 (GDPR) and the Estonian Personal Data Protection Act.


4. RDAP and the retirement of WHOIS

RDAP is the standardised successor to the WHOIS protocol. Unlike WHOIS, which returned unstructured text, RDAP delivers registration data in a structured, machine-readable JSON format over HTTPS, supports internationalised data, and enables differentiated (tiered) access. Since the WHOIS sunset on 28 January 2025, RDAP is the authoritative means of accessing gTLD registration data. Trustname provides RDAP in accordance with the gTLD RDAP Profile.


5. How to access the RDAP service

  • RDAP endpoint. Trustname's RDAP service is available at https://rdap.trustname.com/ (confirm/replace with the exact base URL registered in IANA's Registrar RDAP bootstrap). The authoritative endpoint for any domain can also be located through the IANA RDAP bootstrap (RFC 9224) or an aggregator such as rdap.org.
  • Query format. Queries follow RFC 9082, for example …/domain/EXAMPLE.COM. Responses are returned as JSON per RFC 9083 over HTTPS (RFC 7481).
  • Web lookup. A human-readable lookup is also available at https://trustname.com/whois.
  • Notices. RDAP responses include the notices and links required by the gTLD RDAP Profile, including the ICANN RDDS Inaccuracy Complaint Form (https://icann.org/wicf), EPP status code information (https://icann.org/epp), and our abuse contact.


6. Public (unauthenticated) access — data returned and redaction

The public RDAP record returns the registration data that is not personal data, published without undue delay after registration in accordance with Article 28(4) NIS2 and the Registration Data Policy. This typically includes:

  • the domain name and domain handle/ID;
  • status (EPP status codes);
  • registration, expiration and last-updated dates;
  • the sponsoring registrar and IANA Registrar ID;
  • the abuse contact (email and telephone);
  • name servers and DNSSEC delegation status; and
  • the required RDAP notices and links.

Redaction of personal data. Personal data is redacted from the public record in accordance with the GDPR and the Registration Data Policy, using the redaction mechanism in RFC 9537 and the ICANN RDAP Response Profile. In particular:

  • contact details of natural-person registrants and contacts (name, email, telephone, postal address) are redacted; where available, an anonymised or form-based means of contacting the registrant may be provided;
  • the Registrant Organization field is published only where the registrant has provided the required consent;
  • registration data of legal persons that does not constitute personal data may be published.


7. Differentiated access and access to non-public data

RDAP is capable of differentiated (tiered) access. However, there is currently no globally mandated authentication and authorisation mechanism for RDAP at the registrar level (the Standardised System for Access/Disclosure (SSAD) has not been implemented). Accordingly:

  • Trustname does not operate a public, self-service authenticated RDAP tier that returns non-public personal data automatically.
  • Access to non-public registration data is provided through Trustname's disclosure-request process to legitimate access seekers upon lawful and duly substantiated requests, assessed under the GDPR. Trustname replies to such requests within 72 hours of receipt as required by Article 28(5) NIS2, and handles urgent requests (imminent threat to life, of serious bodily injury, to critical infrastructure, or of child exploitation) on the expedited basis set out in our Disclosure Policy. The procedure, required content, and criteria are set out in our Domain Name Registration Data Disclosure Policy / NPRD Disclosure Request Policy.
  • ICANN Registration Data Request Service (RDRS). Trustname's participation in the voluntary RDRS is [opted in / not opted in — confirm]. Where Trustname participates, requests submitted via RDRS are processed in accordance with the disclosure requirements referenced above.

If and when ICANN implements a standardised authentication and access mechanism for RDAP, this policy will be updated to reflect it.


8. Acceptable use, rate limiting and prohibited uses

RDAP access is provided for lawful purposes only. The following are prohibited:

  • high-volume, bulk or automated harvesting of registration data;
  • use of the data to enable, facilitate or send spam, unsolicited communications, or mass solicitations (by email, telephone or otherwise);
  • compiling, repackaging, redistributing or reselling the data; and
  • any query activity that places an unreasonable burden on the service or attempts to circumvent access controls.

Trustname applies rate limiting to the RDAP service and may throttle, suspend or block queriers that exceed reasonable limits or engage in abusive or prohibited use (for example, returning an HTTP 429 response). Registration data is provided on a near-real-time basis and is subject to change.


9. Accuracy and maintenance

The data served through RDAP is collected, validated and verified in accordance with our Domain Name Registration Data Verification Policy. Suspected inaccuracies are handled under that policy and may be reported through the ICANN RDDS Inaccuracy Complaint Form referenced in Section 5.


10. Data protection (GDPR)

  • Publication of non-personal registration data is carried out in accordance with Article 28(4) NIS2; personal data is redacted from the public record as described in Section 6.
  • Our processing of personal data in registration data is described in our privacy notice and is carried out in accordance with the GDPR and the Estonian Personal Data Protection Act, applying data minimisation, purpose limitation and security.
  • Disclosure of non-public personal data occurs only through the disclosure process described in Section 7, subject to a GDPR necessity and balancing assessment. Data subjects may exercise their rights as described in our privacy notice.


11. Privacy and proxy registrations

For domains that use Trustname's two-tier privacy or a proxy service, the public RDAP record displays the details of the privacy/proxy service (provided by our independent proxy partners) rather than the registrant's personal details. Trustname continues to collect, verify and hold the accurate underlying registrant data, which is disclosed only lawfully through the disclosure process in Section 7. Use of a privacy or proxy service does not affect Trustname's obligations to publish non-personal data, to maintain data accuracy, or to provide lawful access.


12. Service availability and security

The RDAP service is provided over HTTPS (RFC 7481) and is subject to the technical and organisational security and availability measures described in our information-security framework, consistent with our obligations as an ICANN-accredited registrar and, where applicable, under the Estonian Cybersecurity Act.


13. Roles and responsibilities

  • Cybersecurity Officer (Kiryl Nestsiarovich) — owner of this policy; responsible for its implementation, maintenance and review.
  • Technical / operations team — operates the RDAP service, redaction, rate limiting and availability.
  • Abuse / legal function — handles requests for non-public data under the Disclosure Policy.
  • Management Board — approves this policy and oversees compliance.


14. Review and governance

This policy is reviewed at least annually and whenever there is a material change in the gTLD RDAP Profile, the ICANN Registration Data Policy, the RDAP standards, or applicable law (including NIS2 transposition measures and the GDPR). Material changes are approved by the Management Board, version-controlled, and re-published.


15. Public availability and contact

This policy is published on the Trustname.com website so as to be directly and permanently accessible.

Queries about RDAP access, and requests for non-public registration data, may be directed to: Fewmoretaps OÜ (d/b/a Trustname.com)— privacy@trustname.com — Roseni 13, 10111 Tallinn, Estonia — +372 6884747.


Annex A — Public RDAP response: published vs redacted

FieldPublic (unauthenticated) RDAP
Domain name / handlePublished
Domain status (EPP codes)Published
Registration / expiration / last-updated datesPublished
Sponsoring registrar + IANA IDPublished
Abuse contact (email, phone)Published
Name serversPublished
DNSSEC delegation statusPublished
Registrant name / email / phone / address (natural person)Redacted (RFC 9537); contactable means may be provided
Registrant OrganizationPublished only with registrant consent
Legal-person data that is not personal dataMay be published
Privacy/proxy-protected registrationsPrivacy/proxy details shown; underlying data via disclosure process


Annex B — Key references

  • ICANN Registration Data Policy (effective 21 August 2025) and gTLD RDAP Profile (RDAP Response Profile; RDAP Technical Implementation Guide).
  • ICANN Registrar Accreditation Agreement (RAA).
  • IETF RFC 9082, RFC 9083, RFC 7481, RFC 9224, RFC 9537.
  • NIS2 Directive (EU) 2022/2555, Article 28; Estonian Cybersecurity Act.
  • GDPR (Regulation (EU) 2016/679); Estonian Personal Data Protection Act.
  • ICANN RDDS Inaccuracy Complaint Form (icann.org/wicf); EPP status codes (icann.org/epp).


Annex C — Document history

VersionDateAuthorSummary
1.024 June 2026Kiryl Nestsiarovich, Cybersecurity OfficerInitial issue.


Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select at least one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article