Registry Advantage SoftwareArchitecture

Registry Advantage has developed a proprietary Shared Registry System based on a three-tier software architecture that supports:

  • Multiple levels of redundancy
  • High performance and rapid updates (near real-time propagation of DNS changes)
  • Rapid recovery after a failure
  • Sustained performance even during failures
  • Extendibility to allow rapid implementation of new applications (e.g. VeriSign’s RRP)

The software architecture supports multiple server clusters for the SRS, DNS and Whois servers that can reside at several geographic locations. A master server cluster contains configuration information for all other clusters (which are called satellites). The master is responsible for keeping distributed logs, issuing warnings to operators, caching updates to minimize database load, initializing new servers in the other clusters, and distributing updates to DNS and Whois satellite servers. In the event of catastrophic master failure, the satellite clusters will still continue to function. This master-satellite arrangement (as illustrated in Figure 1) provides for independent operation to ensure fault tolerance, while centralizing management tasks to aid scalability.

Figure 1 : Master-Satellite Relationship


Figure 2 shows the three-tier software architecture for Registry Advantage’s Shared Registry System. (Note that it does not show the “clients” for SRS, DNS and Whois, which might be defined as a separate tier.)



Figure 2: Software Architecture 


The database layer, represented by the Oracle DBMS, receives registry data from a variety of applications, which can be customized based on the needs of a particular TLD.  Currently, Registry Advantage supports all of the following server applications that make updates to the database layer:


  • SRS (Shared Registry System) – A generic term referring to any protocol that allows automated new registrations and changes to be sent from registrars to the registry back-end system. The current Registry Advantage supports two: its own Simple Registration Protocol (SRP) and the Extensible Provisioning Protocol (EPP), based on IETF draft version 6. The SRP protocol is similar to VeriSign’s RRP in that it is a simple plaintext protocol making use of whitespace to delimit protocol elements.  For each SRS protocol, Registry Advantage provides a Registrar Toolkit to registrars so that they can more easily implement the protocol and connect to our systems.
  • Account Management Interface (AMI) – A secure web-based system that allows registrars to log in and update registration data as well as generate reports.


For the .org TLD, Registry Advantage will provide registrars with access to the SRS using both the RRP and EPP protocols, as well as a web-based Account Management Interface. 

Recent updates to registry data are retrieved from the Oracle DBMS by the master satellite, which caches these updates to subsequently send to the DNS and Whois satellite servers. The satellite servers contact the master on a periodic basis (e.g., once every minute) to inform the master as to their status and request new updates. Any updates to DNS or Whois information are sent to the satellite servers at this time.

As Figure 2 also shows, Registry Advantage runs a secondary cluster of BIND servers in the case of massive catastrophic failure. A batch process called the “Generator” extracts zone updates from the Oracle DBMS and passes them to the BIND servers.

Underlying Software Framework

[The remainder of this attachment is the subject of a confidentiality request from dotOrg Foundation.]