Good Practices for the Registration and Administration of Domain Name Portfolios (Part II)

Continuing with our series on good practices for managing domain registrations (you can read the first post here), I'd like to provide some insight into the domain registration practices of large organizations. In general, they exhibit positive characteristics; they provide valid email addresses for their Whois contacts, configure resilient name resolution service, and utilize EPP status codes to mitigate domain name hijacking.

Many organizations and government entities follow domain registration practices and recommendations such as those outlined in documents published by ICANN's Security and Stability Advisory Committee (SSAC), such as SAC044 and SAC040, in order to mitigate the risk that their domain names be misused or exploited.

However, it is also fair to say that mitigation efforts for certain risks are not always present. Organizations should be aware of the risks their domain names face, and adjust their existing registration practices to provide a more secure environment for their own businesses, as well as a safer and stable online experience for their customers. We encourage them to periodically review their domain registrations and include domain name and overall DNS management within their risk management programs.

In this post, we'll refer to good practices related to who the actual registrant and the administrative contact should, and should not, be.

Who is the actual registrant?

Every domain name is registered pursuant to a registration agreement between a registrant and a sponsoring registrar. In this screenshot, you can see two fields that identify who the registrant is as they are listed in the WHOIS output of the domain name icann.org.

Referring to corporate registrations, if the Registrant Organization field lists the name of an existing legal entity, that legal entity will be considered the registrant of the domain name. However, when the Registrant Organization field is empty, or when the name listed in it does not correspond to an actual legal entity (like 'Domain Admin', for example), the actual registrant will be whomever is listed in the Registrant Name field.

This situation happens sometimes when employees register names for their employers and don't include the appropriate information in the corresponding fields. They may leave Registrant Organization blank, or include the name of their department and their own name in the field reserved for Registrant Name, turning themselves into the actual registrants of their company's domains. In these cases, organizations face the risk of having the registrations disputed by their employees, who can claim the rights to the domains and attempt to transfer them away, on the basis that the particular organization is not a party to the agreement between the registrar and the registrant.

With this risk in mind, as a matter of good practice organizations should make sure that their legal name is listed in the Registrant Organization field, and that a role-based or department-based name is listed in the Registrant Name field.

Third party registrant or administrative contact.

On another hand, and I'd like to note very clearly that this does NOT constitute legal advice (you should always seek appropriate legal advice when drafting or reviewing contracts), organizations sometimes allow third parties, like their hosting provider, web developer or law firm, to be listed as the registrant of their domains. This is generally not considered a good practice. When an organization outsources the management of its domain portfolio, it should ideally still be listed as the registrant of the domain, regardless of whether the portfolio manager is listed as the domain's administrative, technical or billing contact.

Allowing a third party to be the registrant of an organization's domains means that the organization will NOT be the registrant of record. This might allow that third party to challenge the registration in terms of transferring the domains away to a different registrar and deprive the organization and its employees, customers and business partners of use of the domains – at least until after the organization retains legal counsel, pays legal fees, initiates the corresponding procedures, whether they are administrative, such as a UDRP or URS, or judicial in the appropriate jurisdiction. And even after all that, there's no guarantee that the organization will actually succeed in the proceedings.

Now, with regards to having the portfolio manager listed as the administrative or technical contact, a good practice is to establish a (separate) contractual relationship between the organization and that third party (remember, this is a description of a good practice, NOT legal advice). From a technical and security operations standpoint, it is good practice to include provisions in the contract that assign the authority to manage the domain name, including the ability to, for example, transfer the domain name to a different registrar per the organization's instructions, renew or allow the domain to expire, change name server records, set domain status, or change contact data. That contract could also specify the circumstances under which the administrative or technical contact would be allowed or obligated to modify any aspect of the registration or the operation of the domain name.

Part of this good practice includes adding provisions in that agreement that provide the operational measures that the administrative and technical contacts should implement or execute in order to protect the organization's domain names, including those deemed appropriate in response to security incidents, like distributed denial of service attacks against the domain's nameservers, server compromise that leads to content being hosted without the registrant's authorization, unauthorized creation of subdomains, or even the unauthorized modification or addition of zone records. These operational measures can include, for example, filing reports with the corresponding registrar or with law enforcement in the appropriate jurisdictions. Finally, as with every contract, it could also define the sanctions for situations in which the party listed as administrative or technical contact violate their obligations in regards to administration of the domain names.

Again, this section does not constitute legal advice, so it is up to you to seek appropriate legal advice while considering ways to address these good practices from the technical, operational and contractual standpoints.

In future posts, we'll refer to good practices related to EPP status codes (what is an EPP status code?), nameservers, and other aspects to keep in mind when managing domain registrations.