Registration Data and RDAP Policy

01 RDAP and Registration Data

This policy governs the collection, validation, transfer, publication, disclosure, correction, retention, and security of registration data associated with UDR labels. It aligns with ICANN registration-data and RDAP concepts where appropriate, while preserving UDR status as a policy-driven domain registry.

02 Data Elements

UDR may collect or generate data elements needed to operate a registry database and public lookup service.

• Label, extension, parent domain family, registrar, reseller where applicable, status codes, lifecycle events, creation date, update date, expiration date, deletion date, and handles.
• Registrant, organization, administrative, technical, billing, and abuse-contact data where required by registrar channel or policy.
• Nameserver, DNSSEC, DS records, glue where supported, lock status, hold status, dispute status, premium or reserved status, and operational notes.

03 Publication and Redaction

RDAP may publish domain status, dates, nameservers, DNSSEC information, registrar information, notices, and selected contact fields. Personal data may be redacted or replaced with role contacts where publication would be disproportionate, unlawful, or inconsistent with UDR privacy controls.

• RDAP responses may include notices explaining redaction, terms of use, rate limits, accuracy limitations, and abuse-report channels.
• Raw RDAP output remains important for technical users and may be shown alongside human-readable summaries.
• Third-party WHOIS mirrors may cache UDR data. UDR cannot guarantee immediate removal from external indexes.

04 Accuracy and Correction

Registrants and registrars must keep registration data accurate. UDR may investigate inaccurate data, require correction, suspend labels for material inaccuracy, or refuse changes that appear fraudulent or unauthorized.

• Correction requests should include the label, affected data, evidence of authority, and requested update.
• A registrar managing the label should be the first correction channel unless UDR manages the label directly.
• UDR may require verification for email, phone, organization, authority, or sensitive changes.

05 Lawful Disclosure Requests

Requests for non-public registration data must identify the requester, legal basis, specific data requested, purpose, urgency, evidence, and safeguards. UDR reviews requests for proportionality, authenticity, jurisdiction, registrant rights, public interest, and security risk.

• Emergency requests involving imminent harm may receive expedited review.
• UDR may notify the registrant unless prohibited by law or harmful to an investigation.
• UDR may deny, narrow, or redirect requests that are overbroad, unsupported, abusive, or better handled by the sponsoring registrar or a lawful authority.

06 Log Files and Access Controls

UDR keeps logs for RDAP access, API changes, admin actions, registrar commands, disclosure decisions, abuse workflow events, and automation events. Logs protect the registry, support audits, and help reconstruct incidents.

• RDAP and API access may be rate-limited or blocked for scraping, enumeration, abuse, security risk, or terms violations.
• Admin and registrar access should use individual credentials, role-based permissions, and audit trails.

07 Retention and Escrow-style Preservation

UDR retains registration data for active labels and for a reasonable period after deletion, expiration, transfer, or termination to support disputes, abuse history, legal obligations, restoration, billing, and upstream defense. UDR may maintain backups and escrow-style internal copies for continuity, but such copies are not public availability guarantees.