This chapter presents the systems and technical facilities that will constitute Global Name Registry’s .org Registry. The first part of this chapter takes a high level view of the Registry and its interfaces, and employs use-case modeling to describe the interactions and operations to ensure that Registry performs on a high level, as well as going on to show the high level network diagrams and hardware topology diagrams.

The second part of this chapter is describing in more detail the logic and processes that are key to operating the Registry. Through sequence diagrams, deployment diagrams and hardware structure, readers can take a comprehensive look into the design of the Registry. While some parts of the Registry system is explained in greater detail in Sections C17.2 to C17.16, C17.1 is meant to be comprehensive and give the reader good insight into how the proposed .org Registry will work.

Thus, Section C17.1 describes the basis for the Registry functionality that:

1. Is a world-wide fully self-operated DNS network, capable of serving more than 200,000 queries per second, or 17.2 billion queries per day. More capacity can be easily added to scale the capacity almost linearly.

2. Contains a centralized Whois source for .org, capable of serving more than 300 queries per second, or 26 million queries per day. More capacity can be easily added to scale the capacity on a roughly linear basis.

3. Features a Registry connected to all ICANN Accredited Registrars through EPP while simultaneously supporting the legacy RRP for their convenience during a long period.

4. Features a Shared Registry System capable of supporting potentially hundreds of Registrars, with up to 1500 database transactions per second, or 129 million transactions per day. The system is designed to be able to add more capacity when necessary.

5. Features updates to the DNS and Whois service contents seconds or minutes after database updates happen.

6. Contains a fully redundant system that can fail over to a disparate location in emergencies without significant loss of service.

1 High level architectural view – the system and its context

The figure below presents the Registry System and the users who utilize the services it offers, or who interact with the Registry System by other means. In this section the users (actors) are described, as well as how they can use the Registry System (use cases). The realization of the Registry System is presented in subsequent subsections according to design, physical deployment, and process.

Figure 1: Use Case top-level diagram

1.1 Actor and use case view – core functionality

The actors presented in Figure 1 directly interact with the core Registry System.

Actor descriptions

The core functionality of the Registry System is centered within the Registry. The Registry administers one or more top-level domains (e.g. .org). All main use cases are in some way involved in the handling of these top-level domains. In the following discussion, we will give a brief description of all the main actors and use cases identified in Figure 1.

Actors:

	Registry: This is the organization responsible for administering one or more top-level domains. By organization we mean the technical as well as organizational infrastructure built to support this business.
	Registrar: A Registrar is an organization acting as a domain buyer on behalf of a Registrant. The Registrar is responsible for the technical maintenance of domains bought from a Registry. Only Registrars may add, edit or delete objects from a Registry.
	Registrant: The Registrant is the actual buyer of a domain. The registrant has no direct contact with the Registry. All actions concerning domains are directed towards a Registrar.
	VeriSign: VeriSign is the registry currently administering the .org top-level domain. The .org TLD is to be transferred a new registry, symbolized by the Registry actor.
	Bank: A financial institution responsible for handling the monetary transactions involved in the process of billing Registrars.
	ICANN: The Internet Corporation for Assigned Names and Numbers (ICANN) is a non-profit, private-sector corporation. ICANN is dedicated to preserving the operational stability of the Internet. ICANN coordinates the stable operation of the Internet's root server system.
	WIPO: The World Intellectual Property Organization will be involved in arbitration between conflicting domain name Registrants under the UDRP.
	External Actor: By External Actor we mean organizations that should receive reports from the Registry, other than ICANN or WIPO.
	Security Firm: The Security Firm is responsible for transporting and handling backup-tapes that are to be transported off-site.
	Escrow Storage: Escrow is a holding of critical data by a trusted third party, the Escrow Storage firm. The data is held to be transferred to an entity external to the Registry in case of special events. The Escrow Storage firm is responsible for storing and protecting the escrowed data and will release the data to the relevant party upon triggering of predetermined conditions.
	DNS-system: The DNS-system is the authoritative name server system for the top-level domain(s) administrated by the Registry.
	Whois-System: A service providing information on registered domains handled by the Registry. The Whois system for .org is currently handled both by the Registry (“thin” part) and the Registrars (“thick” part, where contact information is included).
	Resolving Client: Application using resolving services (e.g. DNS System and Whois System).

Use case descriptions

Reassignment of .org Top-Level-Domain

This use case represents the process of transferring the .org top level domain from the current registry VeriSign, Inc. to The Global Name Registry, Limited (“GNR”). The process of transferring has both technical as well as non-technical challenges. Focusing on the technical aspects one has to aim at minimizing service down-time due to the physical relocation of the registrar services, and assure 100% data consistency across the transferal –i.e. no information necessary for the proper operation of the registry services must be lost due to the transfer.

At a softer, more non-technical level, there are challenges associated with the infrastructural changes that an operation of this kind represents. More than 100 registrars have to update their registrar systems for use with the new registry. Changes in routines and processes at different organizational levels have to be implemented. The registrars will have to be re-accredited by the new registry and adapt to the major or minor differences between the old and the new registries’ ways of operating. GNR aims to minimize these differences and transition challenges for external parties. The Registry Transition is described in more detail in Section C18 in this .org Proposal.

Object Handling

The Object Handling use case is an abstraction of all operations resulting from interaction between the Registry and a Registrar concerning an object. An object in this context may be a domain, a contact, a DNS server or other information accessible and modifiable by Registrars. See section C17.3 – Database Capabilities, for details regarding object types and their handling. Object Handling is further refined in the following use case diagram:

Figure 2: Detailed view of Object Handling use case

Add Object

This use case describes the process of object registration. It is initiated by a Registrar who seeks to add an object of some kind, typically a domain with associated DNS server and contacts (in case of a thick registry). The activities typically involved in this process are shown in the figure below, which gives a high-level description of the control-flow when adding new objects.

Figure 3: Activity diagram realizing the Add Object use case, activity view

The add domain object operation is a billable transaction and will in addition to the steps identified above trigger the Billing use case.

Modify Object

A Registrar may change information about an object, such as status, expiration date, name servers handling a domain, or contact info. Registrars may only access and update domains they already own. The activities typically involved in this process are shown in the figure below.

Figure 4:Activity diagram realizing the Modify Object use case, activity view

Remove Object

A Registrar may delete an object registered by that Registrar. The activities typically involved in this process are visualized in the following Figure, which gives a high-level description of the control-flow when deleting domains.

Figure 5:Activity diagram realizing the Remove Object use case, activity view

Transfer Domain

A domain object may be transferred between two Registrars. This may only happen if the Registrant owning the domain gives the new Registrar permission to take over the domain in question, or in the case of UDRP arbitration or otherwise conflict handling/arbitration by the Registry.

The transfer process is to a certain extent protocol-dependant. The RRP and EPP protocols each support the Transfer in a different way. As an example, under EPP, each object is assigned a password which must be used to complete a Transfer. More information on RRP, EPP, and transfer handling can be found in Sections C17.2 (RRP and EPP implementations), C22 (RRP to EPP migration) and C17.3 (database and business rules).

The activities typically involved in the Transfer process are shown in the following figure.

Figure 6:Activity diagram realizing the TransferDomain use case, activity view

Buy Domain

This use case is an abstraction of the process a Registrant undertakes when applying for a domain. The Registrant asks the Registrar to carry through the use case Insert New Domain for a given domain. Therefore, Buy Domain is a use case that only indirectly utilizes the Registry System. The communication with the Registry System is restricted to accredited Registrars.

The Registrant may use the WHOIS service provided by the Registry to check if a domain name is taken or not. The only way a client may apply for a domain is through a Registrar. The only situation a Registrant will be in direct contact with a Registry is in case of domain name dispute (see the Complaint use case).

GNR strives to inform potential Registrants globally about the benefits of buying a domain for their own purposes. Through direct marketing practices and co-marketing activities with Registrars and promotions, GNR seek to increase growth of the TLD it operates. A fuller discussion of proposed GNR marketing activities for .org can be found in Section C38 and other parts of this .org Proposal.

Billing

The prime principle of registrations is that the domain name registrations are prepaid, although GNR also grants Registrars a $1000 credit limit.

The Billing use case is a triggered by billable operations (See Sections C25-C27) initiated by a Registrar. The Registry System debits the amount associated with the operation from the Registrar’s Registry account. The Financial Controller, as part of the Registry, handles billing and administers the flow of assets and invoices. The Bank handles the monetary transactions involved.

When a registration is completed, the Registrar’s account balance is debited with the price of one registration. Registrations continue as long as the balance is positive, or the credit limit is exceeded, after which further billable operations will be denied.

Once a month, the Registrar is billed with the amount necessary to restore their credit balance. This amount can be chosen by the Registrar himself and can vary from month to month.

Registrar Account Administration

This use case involves all administration of the individual Registrar accounts. Standard operations as shown in the figure below are supported.

Figure 7 Detailed view of Registrar Account Admin use case

Only ICANN accredited Registrars may be given an account. All existing ICANN accredited Registrars will be invited to also become .org Registrars. There will be no restriction to the number of Registrars.

Registrars that are given an account must also be certified by the Registry. This to assure that the Registrars’ systems are compatible with the Registry System. See section 1.2.1 Overview of Registry design for more details on the OT&E system.

Registrars will have a running relationship to the Registry, mostly for billing and credit purposes. Credit for registrations can be updated at any time.

Reporting

GNR provides a number of reports to ICANN on the status of the Registry, to Registrars on their respective statuses, and to the general public.

Most reports are automatically generated by the Reporting system and are distributed by means of FTP or mail.

Complaints over Registration rights

The Registry will not perform arbitration of disputes. UDRP disputes and other forms of arbitration between Registrants in general will be handled by a third party, e.g. WIPO.

Backup

Backups are taken periodically and transported off-site by a security company. See Section C17.7 for further descriptions of Backup.

Escrow

Approximately once a month a copy of the registry database will be sent to a secure storage place offsite. There is also a separate Whois escrow intended for future use.

DNS Update

A DNS Update is triggered by an operation from the Registrar. When an operation on an object is executed in the Core SRS, the Registry System will propagate the changes to affected Resolving Services through the Update Handler. We use BIND9, developed by ISC, which supports the DNS extensions necessary to allow Incremental Zone Transfers (IXFR). At each regional site there is a stealth master DNS server, which will be dedicated to doing updates to the slave DNS servers with the AXFR and/or IXFR mechanisms of DNS.

Secure network connections between main and regional sites and use of point-to-point authentication and integrity checking according to RFC2845 (also referred to as TSIG) is employed to ensure that the data arrives at the intended destination without tampering or sniffing on the way.

Whois Update

The Whois Update use case is quite similar to the DNS Update use case. The Whois use case is triggered by the operation on an object in the Core SRS that in turn has to be reflected in the Whois system. These operations may concern domains, contacts, name servers, registrars, or other objects that may exist in Whois system.

Whois updates are distributed to the regional Whois system(s) by the Update Handler.

1.2 Registry Systems Overview – A Design view

1.2.1 Overview of Registry design

The design view of the Registry System encompasses the systems and collaborations that form the vocabulary of the solution. This view primarily supports the functional requirements of the system, meaning the services that the system should provide to its end users.

The figure below shows a high-level system view of the Registry System. The packages are systems within the Registry System dependent on each other and are responsible of implementing distinct services. The figure is a logical presentation of the Registry System.

Figure 8: High-level system view, static view

A brief description of each of the packages:

Registrar Systems. The systems held by the registrar at the registrar’s site are enabled to communicate with and operate against the Registry System. These systems will not be elaborated in more detail in this document, but it is worth noting that the transition to a new registry for most registrars will imply changes into their systems. See Section C18 for further discussion regarding the transition process and its implication for registrars.

Registrar Interface: The registrar systems’ interface to the Registry System. Registrars use either the Registrar-Registry Protocol (RRP) or the Extensible Provisioning Protocol (EPP) for communication with the Registry System.

OT&E : Each Registrar must prior to operations in the SRS demonstrate basic functional skills in the Operational Test & Evaluation (Ot&E) Environment. This environment is functionally identical to the SRS, with the exception that no data in the OT&E will result in changes to resolution services or similar. All data in the OT&E only reside in the OT&E database and are used for the purpose of training Registrars to operate in the SRS. Operators can age data, delete data and replace data in the OT&E as part of the Registrar training.

Core SRS is the central unit of the Registry System, where the business logic and the authoritative database are held. The Core SRS is the most critical part of the system, on which all other systems in the Registry System are dependent.

System Monitoring: The system that provides facilities to supervise the Registry System and its operations, as well as Error Handling.

Billing: The system managing billing of billable operations performed by the registrars.

Reporting : The reporting system creates and manages reports to ICANN, Registrars and third parties.

Automated Consistency Validation is a system verifying that information provided by the Resolving Services are consistent with information stored in the Authoritative Registry Database in the Core SRS. This advanced feedback system allows GNR to update resolution services in real time.

Offsite Logging is a system providing archive logs from all transactions performed.

Offsite Escrow: The system providing the escrow of the Authorative Registry Database in the Core SRS at a secure, offsite location.

Update Handler. A system responsible for routing and distributing changes made to the Authoritative Registry Database in the Core SRS to the parts of the Registry System and Resolving Services that are to receive the changes on a near real-time basis.

Resolving Services: The resolving services encompass public services like Whois look-ups and DNS resolving services. A local Update Handler is responsible for propagating messages to local message consumers, i.e. the DNS system and the Whois system.

What follows is a set of focused views intended to present some critical aspects of the Registry System at a high-level of abstraction. Subsequent subsections will go into greater detail at a lower system level when such details are not described in other sections.

1.2.2 Real time and asynchronous communication between Registry Systems – a latency focus

This subsection is focusing on message paths in the system and associated latency in the Registry System. This is visualized in the figure below. The primary cause of latency in the system is the use of message queues. Message queues are used throughout the system to facilitate scalability, robustness, congestion control, and separation of concern among system components.

Figure 9: Diagram illustrating latency in the Registry System

From an Internet-availability and stability point of view there are two message paths that deserve special attention: the path (A) associated with the process of updating objects, starting with a registrar issuing a request (e.g. new domain request) and ending in the updating of the affected resolving services (e.g. DNS and Whois). The second path (B) is related to the first, but takes as its starting point the committed transaction in the Core SRS resulting from the registrar’s original request and ends in the validation of the changes made in the resolving services.

Path A – Registrar System à Resolving Service - latency introducing steps
*Sender*	*Receiver*	*Latency*
Registrar system	Core SRS	No latency. Synchronous communication
Core SRS	Update Handler	Potential point of latency. The Core SRS contains a process (Update Message Generator) that is responsible for propagating committed transactions from the Authoritative Registry Database to the update handler. In situations with near congestion load on the Authoritative Registry Database the Update Message Generator may delay its polling for new transactions to reduce the overall Core SRS load.
Update Handler	Resolving Services	Potential point of latency. The update handler holds a queue for incoming messages reflecting changes in Core SRS, and outgoing queues for each message consuming system component (e.g. DNS, Whois). Depending on consuming components’ throughput capacity messages may be delayed at this stage.

Path B – Core SRS à Resolving Service - latency introducing steps
*Sender*	*Receiver*	*Latency*
Core SRS	Automated Consistency Validation	Potential point of latency. The Core SRS never sends anything to the ACV, but the ACV pulls information out of the QA database. Since it bases its process on the messages in the message queue of the Update Handler, there may be the same latency in this process as for the Core SRS-Update Handler path.
Automated Consistency Validation	Resolving Services	Potential point of latency. The Automated Consistency Validation process will start trying to verify the consistency of the resolving services affected by the message in question after a initial minimum delay (to give the resolving services time to process the message). On resolving error, the system will wait for an additional period time before retrying. This process is repeated until a maximum probable path A latency limit is reached. To sum up: the Path B latency will never be less than the Path A latency. One has to define a maximum probable latency for Path A as a threshold for when update messages not reflected in Resolving Services are to be treated as lost.

The other paths illustrated in the figure above can be partitioned into synchronous communication and batched communication.

Synchronous communication

Path

Core SRS à System Monitoring.

The monitoring system provides real time information about system statuses, not only for Core SRS but also for all other systems that have monitoring extensions.

Core SRS à Billing.

Billable operations are immediately reflected in the billing system

Batched communication
*Path*	*Batch Interval*
Core SRS à Offsite Escrow. The Core SRS uploads the escrow files to the Offsite Escrow storage at a regular interval	Every day, at given hour
Core SRS à Offsite Logging. Core SRS logs are transferred offsite at regular intervals	Continuous and in addition, monthly batch checking
Core SRS à Reporting Analyses are collected, and reports are generated at regular intervals.	Monthly

1.2.3 Component security, vulnerability, and recovery – a QoS focus on the Registry Systems

GNR operations teams and customer support teams are the most important feedback loops internally in GNR to protect the registry system. Problems can be detected at many levels but with very few (and non-critical) exceptions, historically, problems have been detected by GNR testing, quality control processes or operational problem detection and monitoring.

In addition to this problem detection, GNR has committed effort to ensure a reliable and secure system. The items list below enumerates such efforts (See Section C17.9 and Section C17.14 for further descriptions):

Security

· Registrar security and authentication

· Data Protection Procedures

· Software security procedures

· Software diversity

· Hardware encrypted communications with Registrars and external DNS servers

· Firewalls

· Intrusion Detection Systems

· Encrypted channels to protect network

· Jump points

· Alert systems

· Log and monitoring systems

· Assured Asynchronous communication with MQ

Environmental security

· Facility security including access control, environmental control, magnetic shielding and surveillance

· Human Security policies

· Security of offices and employees<