Skip to main content

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?

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.

Comments

    Domain Name System
    Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."