NIS2, RDAP, and the Two Layers of Domain Registration Data
Domain registration data has changed substantially in under a decade. After GDPR took effect, personal details disappeared from most public lookup results, while RDAP replaced the protocol behind those lookups. NIS2, the EU's second network security directive, now sets rules for data accuracy and access to nonpublic records.
Together, these changes have split registration data into two practical layers: a gated identity layer and a public event layer. DomainKits works only with the second: registrations, nameserver changes, status shifts, expirations, deletions.
WHOIS to RDAP, in brief
WHOIS was a plain-text query on port 43, with no standard response format, requester authentication or internationalization. Each registry formatted responses its own way. RDAP, standardized by the IETF in 2015, replaced it with structured JSON over HTTPS, uniform queries, authoritative service discovery and support for differentiated access. The same protocol can return different levels of detail to different requesters.
ICANN-accredited registries and registrars have offered RDAP since 2019. On January 28, 2025, RDAP became the definitive source for gTLD registration data, and the obligation to run the old port 43 service ended, apart from limited contractual exceptions. Some operators still run WHOIS voluntarily, and country-code registries set their own timelines.
Since GDPR took effect in 2018, most registrars have redacted personal fields from public lookup results by default. Whether a contact field appears depends on applicable law, operator policy and the registrant's choices. Output therefore varies by operator and extension: a field visible in one response may be redacted in another. RDAP supports this kind of differentiated output.
What NIS2 requires for registration data
NIS2 is Directive (EU) 2022/2555, in force since January 2023. Member states were due to transpose it into national law by October 17, 2024. Most of the directive covers cybersecurity obligations for critical sectors and incident reporting; domain registration data is addressed in Article 28.
For TLD registries and entities providing domain registration services, Article 28 requires, in outline:
- Accurate databases. Registration data must be collected and kept complete and accurate in a dedicated database.
- Verification. Registries and registrars must have policies and procedures, including verification procedures, to keep that data accurate.
- Publication of non-personal data. Registration data that is not personal data must be published without undue delay after registration.
- Access requests. Lawful, substantiated requests from legitimate access seekers must be answered without undue delay, and in any event within 72 hours.
The directive does not provide a closed list of legitimate access seekers. Its recitals mention competent authorities, incident response teams and parties acting against fraud and abuse, while national law determines how the standard is applied. Operators must publish their disclosure policies and procedures.
NIS2 does not undo GDPR or put personal registration data back on public display. It requires verification procedures, published disclosure policies and timely responses to lawful requests.
Separately, ICANN launched the Registration Data Request Service in late 2023 as a standard request path for nonpublic gTLD data. Its two-year pilot ended in November 2025, and RDRS continues to operate while ICANN works on a longer-term system. Registrar participation remains voluntary.
NIS2 is a directive, not a regulation. Each member state writes it into national law, and implementation details differ by country. The requirements above describe the directive; the enforceable rules are those in the relevant national law.
How the two layers differ
The identity layer contains the names and contact details behind a registration. Registries and registrars hold this data. RDAP can support differentiated access, but actual requests may run through RDRS, a registrar's disclosure process or procedures established under national law. Under Article 28, a lawful and duly substantiated request must receive a response within 72 hours. The deadline applies to the reply, not the outcome; disclosure still depends on the request's legal basis.
The event layer describes the domain itself: when it was created, its status codes and nameservers, and when it expires or drops. Practical domain research uses this data to find registrations around a keyword or brand, track nameserver and status changes, and monitor expirations without relying on registrant identity.
Where DomainKits sits
DomainKits operates entirely in the event layer: it tracks what happens to domains, not who owns them.
What the dataset covers:
- 250M+ gTLD domains and 128M+ ccTLD domains across 1,200+ extensions, updated daily
- Six lifecycle stages: newly registered, active, expired, grace, redemption, deleted
- Record-level events: creation dates, expiration dates, nameserver changes, status changes
The entire product line uses this data. Lifecycle search covers newly registered, active, expired and deleted names; monitoring follows registrar, nameserver and status changes; trend views are built on registration events. None of it requires knowing anything about the people behind the names.
Identity requests belong with registrar disclosure or abuse desks, RDRS, and procedures established under applicable national law. DomainKits covers the detection step: what gets registered, what changes, and what expires.
DomainKits does not collect, store or return registrant names, postal addresses, email addresses or phone numbers. Public records vary by extension, but the domain lookup tools return non-personal record data only. There is no gated identity tier.