Preparing an Operational and Technical Plan

This article provides additional detail on preparing an operational and technical plan as it relates to the procedure to delegate or transfer a country-code top-level domain (ccTLD).

General overview

Our role is to review whether the proposed manager will perform its tasks with a satisfactory level of operational and technical competency. We primarily do this by asking a requestor to provide a technical and operational plan describing how the proposed manager will manage the domain.

It is recognised that the requirements for operating a ccTLD vary significantly by country. The operational approach for a small country with limited number of domains will be very different from a registry that maintains millions of registrations and has committed to providing a high-level of uptime, 24×7 support, and an automated registration interface such as an EPP-based registry.

The review process is not intended to enforce a particular approach on all requestors. We review the planning assumptions made against the proposed set up of the operation. We apply our understanding of industry norms, to consider if the assumptions are reasonable and if the proposed operation is likely to satisfy those assumptions. If the assumptions or plans appear unreasonable, we will make additional enquiries to the requestor to better understand the proposal.

Considering this assessment approach, a key part in developing a plan is documenting the assumptions and policy constraints that apply to the operation. For example, some of the questions to consider would be: What are the number of projected domains within the ccTLD that need to be managed? How many transactions are expected to be processed? What are the service-level obligations (for uptime, responsiveness, etc.) that the registry is committed to? What are the specific policy requirements that the registry is required to implement?

If the plans provided do not document such assumptions, or do not provide a sufficient level of detail so that the proposed operations can be understood, we may not be able to properly assess the technical and operational capacity of the proposed manager.

Requestors should be aware the plans are not just limited to the technical systems, but also to other resourcing of the proposed management of the domain. Plans should include explanations of the software, hardware, network architecture, staffing, expertise and facilities of the proposed manager.

Specific suggestions

In light of the general advice, some of the specific elements the requestor should consider providing include:

  • description of the organisation’s structure, key personnel (financial and business officers, and other relevant management employees), and an overview of overall staffing;
  • information on the proposed administrative and technical contacts for the domain, including their identities, contact details, and roles within the organisation;
  • description of the proposed manager’s relevant Internet management and registry operations experience;
  • information on the technical capabilities of the manager, including the technical plan for registry and DNS operations, and a description of the physical configuration of the registry, along with technical facilities;
  • assurance that relevant policies will be in place to govern the operation of the domain, as to not jeopardize or compromise the security and stability of the DNS;
  • indication that security plans and procedures will be in place, including database and physical security for the operation of the domain;
  • indication that plans exist to cope with the requirements of scaling registry operations as required;
  • a description of the domain registration model, such as whether a registry-registrar model, or direct interaction with the registry;
  • indication that the requesting organisation has sufficient Internet connectivity and services capable to provide connectivity, redundancy and resiliency;
  • description of the configuration and plan for the name server constellation that will support name resolution for the domain;
  • description of the registry’s interfaces with the community (such as technical APIs, help desk, etc.), and how they will be maintained;
  • information on how zone data will be generated and how public WHOIS services will be provided;
  • information on resiliency provisions, including how system outages and other disasters will be defended against, as well as system recovery and escrow procedures in the event of disasters;
  • indication that processes and plans are in place to ensure operations are in line with global standards, relevant RFCs, and best practices; and
  • description of the timelines and strategies relating to deployment of the registry technical platform and staffing of the registry, if the registry is not already fully commissioned.

On authoritative name server infrastructure

It should be assumed there is an expectation that the authoritative name service, as a whole, must always be available for any top-level domain.

The configuration of the name servers for a top-level domain should be sufficiently well designed to assure constant availability against any adverse event. This includes major denial-of-service attacks and unforeseen disasters in the country. Even though registration activity may be impaired by such events, the name server infrastructure should be designed such that the ability to resolve the top-level domain’s zone should never be impacted.

Requestors should consider geographically and topologically diverse infrastructure that is not dependent on specific networks in order to achieve this goal. The advent of anycast-based approaches to name server deployment makes this more viable than it may have been in the past.

Document last revised 2024-04-30.