Alias Domains and Registrar Records: What the Evidence Proves

What counts as standards-based proof of domain control?

Standards-based proof of domain control requires an action that only a controller can perform, such as provisioning a DNS record or an HTTP resource.

The supported proof standard is active. A controller completes an action that depends on control of the domain name; the documented examples are provisioning a DNS record under the domain or an HTTP resource under the domain.

This page does not turn passive registrar-record similarity into this control test. A resemblance between records is not a substitute for the controller-only action described by the standard, and this page makes no inference about common control, ownership, or identity from such a resemblance.

• Proof requirement: an action that can be performed only with control of the domain name.
• Documented examples: provisioning a DNS record or an HTTP resource under the domain.
• Evidence boundary: passive record similarity does not establish the controller-only action.

Which registration-data fields and flows are supported, and what can this evidence say about RDAP?

The registration-data policy says registrars MUST collect or generate defined domain, registrar, status, registrant, contact, and expiration data, with country-applicability and policy qualifiers; they also MUST make specified registry transfers when an appropriate legal basis and data-processing agreement exist and MUST submit an escrow copy of defined data. This page does not establish how RDAP works or which response fields it exposes.

The collection requirement covers the domain name; registrar Whois server, URL, identity, IANA ID, and abuse contacts; domain status; registrant name, street, city, state or province, postal code, country, phone, and email; and the registrar registration expiration date. State or province and postal code are required only when applicable to the country or territory. A registrar Whois server is required only when the Registrar Accreditation Agreement or an ICANN Consensus Policy requires it.

The registry-transfer rule is narrower and conditional. A registrar MUST transfer the registrant name, street, city, country, phone, and email to the Registry Operator when an appropriate legal basis exists and a data-processing agreement is in place.

The escrow rule says a registrar MUST submit an electronic copy of the domain name, registration expiration date, registrar IANA ID, and the listed registrant contact data to an ICANN-approved data escrow agent. State or province and postal code need not be transferred when they are unavailable for the applicable country or territory.

These policy rules describe collection, registry transfer, and escrow. This page states no RDAP mechanism or response-schema fact, so it does not describe how RDAP works or which fields an RDAP response exposes.

• Collection: defined domain, registrar, status, registrant, contact, and expiration data, subject to the stated applicability and policy qualifiers.
• Registry transfer: registrant name, street, city, country, phone, and email when an appropriate legal basis and a data-processing agreement are in place.
• Escrow: an electronic copy of the domain name, expiration date, registrar IANA ID, and listed registrant contact data to an ICANN-approved data escrow agent.
• RDAP boundary: this page does not establish the mechanism or response fields.

What can domain-control proof and registration records establish about an alias-domain linkage?

This page does not establish that passive registrar or RDAP similarity proves common control, ownership, or identity across domains; an active controller-only action instead satisfies the supported domain-control proof standard, while the registration-data policy defines collection, registry-transfer, and escrow obligations.

The two evidence surfaces answer different questions. The domain-control standard requires an action that can be completed only with control of the domain name. The registration-data policy requires defined fields to be collected or generated and requires defined data flows under stated conditions.

This page does not join those facts into an alias-linkage test or establish that similar registrar or RDAP records prove common control, ownership, or identity across domains. A similarity-based linkage conclusion therefore remains outside this page's supported claims.

For a broader guide to reducing search visibility, see How to be hard to Google without hiding from life.

• Active proof: a controller-only action, such as provisioning the documented DNS-record or HTTP-resource example.
• Registration-data policy: defined collection, registry-transfer, and escrow obligations with stated conditions and qualifiers.
• Unsupported conclusion: passive registrar or RDAP similarity as proof of common control, ownership, or identity.

What retention obligation survives the end of sponsorship or an inter-registrant transfer?

A registrar MUST retain the data elements needed for the Transfer Dispute Resolution Policy for no less than 15 months after its sponsorship of the registration ends or after an inter-registrant transfer.

The supported retention rule is narrow. It applies to the data elements necessary for the Transfer Dispute Resolution Policy, sets a floor of no less than 15 months, and names two triggers: the end of the registrar's sponsorship of the registration and an inter-registrant transfer.

This rule does not establish a general deletion or erasure outcome. This page does not state that deleting a domain causes, prevents, or delays erasure generally, so no broader conclusion is drawn from the transfer-dispute retention floor.

• Purpose: data elements necessary for the Transfer Dispute Resolution Policy.
• Duration: no less than 15 months.
• Triggers: the end of registrar sponsorship or an inter-registrant transfer.
• Evidence boundary: no general claim about deletion or erasure.