SRS

SRS Component Overview

• front-end web server
  
• front-end replication
  
• back-end web server
  
• back-end replication
  
• WHOIS daemon.

These have been split into three bundles, one for front-end, one for back-end, and one for WHOIS. There is also a fourth bundle containing common libraries required by all components.

Bundle File Name Components are:
srs-frontend-x.x.x.tar.gz Front-end web server, front-end replication
srs-backend-x.x.x.tar.gz Back-end web server, back-end replication
srs-whois-x.x.x.tar.gz WHOIS daemon
srs-lib-x.x.x.tar.gz Common Libraries.

The SRS is designed to be run with one (active) front-end web server, and three or more back-end web servers. However, it is possible for the SRS to function with a single front-end and a single back-end (possibly both running on the same machine). More details are below.

Front-end Web Server Component

The front-end web-server receives requests from a client, performs some basic validation, and passes it on to the front-end replication. It then waits for the front-end replication to return a response, and then returns that response to the client. The software runs on Apache with mod_perl. (see INSTALL docs in the frontend bundle for version details).

Front-end Replication Component

The front-end replication receives requests from the front-end web server, and distributes them to each of the active back-ends. It then waits to receive a response from the back-ends, and compares each of the responses. If the responses all match, it returns the response to the front-end web server. If one or more responses disagree, an error message is returned to the front-end web server.

This component is middle-ware; that is, it can be easily replaced by something much simpler (if, for example, only a single back-end was required).

This software runs as a standalone daemon.

Back-end Web Server Component

The back-end web server receives transactions from the front-end replication, and processes them, making changes to the database as necessary. It then constructs a response, and returns it to the front-end replication. The software runs on Apache with mod_perl. (see INSTALL docs in the back-end bundle for version details).

Back-end Replication Component

The back-end replication monitors the back-end database on a server. When it finds new updating transactions, it notifies other back-ends. If the other back-end has this transaction, it replies with a hash of the transaction data, which is compared between servers. If the transaction does not exist on the other back-end, it requests the transaction data, and processes it. This software runs as a standalone daemon.

WHOIS Server Component

The WHOIS server is a SRS client that receives standard WHOIS requests (RFC 954), sends them to the SRS front-end, waits for a response, and then returns the response to the client. This software runs as a standalone daemon.

Other Components

RIK: The RIK (Registrar Implementation Kit) is available from the NZRS website (http://nzrs.net.nz). This is a sample implementation of a registrar's client, and is useful in testing the configuration of the SRS.

Scheduled Jobs: The scheduled jobs daemon is distributed in the back-end bundle. This runs the various scheduled jobs, including Renew Domains, Release Domains, and Build DNS Zone Files. In many cases, the daemon issues transactions to the SRS (such as Domain Updates). The daemon can run on one or more of the back-end servers (any transactions missed by the back-ends not running the daemon will be recovered through the back-end replication).

Architecture

There are several different ways the above components can be deployed. The recommended configuration is to run one server as a dedicated front-end (that is, running the front-end web-server, and front-end replication software) and three or more servers as dedicated back-ends (running the back-end web-server and back-end replication). The WHOIS server can be run either on the front-end machine, or on a separate machine with http access to the front-end web-server. It is recommended that the back-end web-servers be accessible only from the front-end.

It is possible to run with one back-end server, or even to run all components on a single server. However, such configurations will reduce the reliability and security of the system.

It is not possible to run multiple front-ends simultaneously. This is due to the fact that race conditions could occur when updating transactions for the same domain are sent to two front-ends simultaneously. It is possible to run additional front-ends that allow only read transactions. This is achieved by running these front-ends in 'maintenance' mode.