U-Registry

Overview

U-Registry is the system that allows to perform complete cycle of the .УКР IDN ccTLD registration management. U-Registry consists of the following core components:

• DNS,
• RDDS,
• SRS with EPP support

Special attention was paid to reliability parameters of the system and to system recovery.

Additionally, U-Registry provides billing system, communication system, settings management etc. System is fully translatable and currently supports any language the country of implementation and English.

The core of U-Registry software is a multi-tiered, distributed application primarily implemented on J2EE platform, using PostgreSQL database.

The Stakeholders of IMEIU-Registry are ccTLD/gTLD Registries, Registrars, and Registrants.

We provide the “turn-key” solution that can be implemented completely on Customer’s servers or Customer can use outsourcing service of already installed system.
System can simultaneously serve an unlimited quantity of TLD / IDN TLD

System is designed and built using five-layer architecture:

U-Registry supports multi-level security and access control. Access to the Registry system is allowed via SSL only.

All transactions of all users of the system are logged in real time.

DNS

DNS implementation is based on the proven software BIND. DNS clusters are geographically distributed and connected to different networks (grade C and higher). System prepares the updated zone file based on the database information and passes it to the Primary Hidden DNS server, which in turn distributes the data between the Slave DNS servers. Primary Hidden DNS server does not serve DNS queries from Internet resolvers. Customer can describe own requirements for the DNS system in the document «SLA Agreement for  ccTLD/gTLD registrations» and TCI — the participant of the Consortium — will implemented ones.

DNS zone  file

Our calculations are based on average 400 bytes per domain name in the DNS zone file.   As such,  the size of the zone file for 1,000,000 domains will be up to 382MB.

RDDS (WHOIS service)

U-Registry WHOIS supports a “thick” registry model, which means that the registry contains all the Registrant’s contact information. We believe that this is the realistic approach for future of any WHOIS service upgrade. From another hand it reduces requirements to Registrars and makes data integrity, escrowing, availability the responsibility of the Registry.

Registry is using a distributed network of WHOIS-servers that allow to obtain information about domain names via request to port 43 or web-interface. WHOIS service supports UTF-8 (Unicode) encoding and provides responses to requests both in the original spelling in any languages, as well as in ASCII.

SRS

U-Registry system provides Registrars with EPP interfaces to perform all the necessary operations with domains, hosts and contacts. Description of the supported EPP interfaces is included as a separate document. EPP protocol will be used only by the accredited Registrars; Registrants will not interact directly with the Registry, they have to operate through their Registrar.

Reliability

U-Registry can guaranteed to perform the service level requirements not worse than:

Backup and Data Recovery

In order to maintain availability and integrity of the data, each data center will perform backups of components located in this data enter, that is sufficient to restore its  operations. In addition, backup copies of the data will be periodically transferred to the centralized backup location, as well as saved to non-volatile medium and stored in the reliable offline storage locations. These procedures are critical to maintain registry operations in case of failure or disaster.

Backup and data recovery will be implemented according to the procedures described in the Disaster Recovery Plan (separate document provided).

Data backup is performed by various methods:

• by using RAID arrays;
• periodic dumps of the data;
• periodic creation of a full disk image of the key components of the system;
• saving the database dump file and the zone file daily on the non-volatile storage media.

To provide a fail-safe solution against failure of the main servers, Registry, DNS, WHOIS servers and databases are in real time synchronized with the «hot swap» servers. InfiniBand devices are used to ensure high-speed synchronization.

Depending on the incident, after which data recovery is required, there are several data recovery scenarios:

• roll back on the internal transaction;
• data recovering from database dump;
• restore the node (element) from the disk image;
• restore the database and zone file from non-volatile storage to hot swap servers
• or, as a last resort measure, recreation of the element on the new hardware using previously saved data.

Failure of any part of the system does not stop the operation of other components. For example, if DNS or RDDS (WHOIS) servers have for any reason lost connection with the registration system they will continue to work with a set of cached data obtained before the loss of connectivity. Once the connection is restored, components will right away obtain current data.

The presence of connectivity between the system elements is constantly monitored and each communication failure is the subject of analysis and correction of errors.

Time for a complete renewal of the local registry data (Master DB, DNS DB, RDDS DB) in an emergency, crashes and failures is not more 25 minutes. These normative parameters will be describes in the Disaster Recovery Plan that will be written under Customer requirements.

The following types of redundant solutions are supported:

1. Standby. A standby server is a second server that is located in the same data center and runs in parallel to the master server and can be brought online if the primary production server fails (fail-over server). The standby server contains up to date copy of the databases on the primary server that is replicated in real time. A standby server can also be used when a primary server becomes unavailable due to scheduled maintenance.
2. Backup database servers. This is essentially a standby server that contains up to date copy of the databases on the primary server that is replicated in real time and is located in a different datacenter. System is switched to use backup server in case of disaster when both primary server and standby server (located at the same data center) become unavailable.
3. Spare servers. An additional servers of the same manufacturer and configuration with pre-installed and pre-configured copy of the operating system and environment that can be used if one of the production servers (master or standby) fails.

The combination of the above on-line and off-line techniques to avoid a loss of information and give 100% guarantee of restoring the current state of the database system.