The DNRS project provides an open source version of the 'New Zealand Shared Registry System' (NZ-SRS) - a computer system for managing a domain name registry. The NZ-SRS was developed in 2002 to manage the New Zealand (.nz) domain name space and was released under the GPL Open Source License on 30 January 2004
The NZ-SRS is software (client and servers) that is most likely to be of use for managing a country TLD and allows the registration, by authorised registrars, of domain names and modification of information associated with that name on the register.
A specification of the NZ-SRS and a detailed description of the communication protocol used by the system have been published as an Internet-Draft on the Internet Engineering Task Force (IETF) web page.
The NZ-SRS protocol uses messages in an XML format for system requests and responses. The protocol is available in DTD, Relax NG and XSD. All three version are part of the download packages. Individual parts of the protocol are covered in depth throughout the Internet-Draft.
The NZ-SRS works in a connection−oriented fashion with no session state. The registrar sends a request to the registry containing commands to be executed by the NZ-SRS. The result of processing these commands is returned as the response. Each registrar request receives a response containing the result of processing all of the requests in a single request.
A Public Key Infrastructure (PKI) is used to manage issues of security, authentication of requests and responses and non−repudiation of actions. This is achieved by signing a checksum of the XML message with the sender’s private key, using a SHA1 checksum 1.3.
The NZ-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 NZ-SRS to function with a single front-end and a single back-end (possibly both running on the same machine).
The NZ-SRS software has been tested on Debian GNU/Linux. However it should also run on other GNU/Linux distributions.
The software requires Perl. The web servers use Apache and the backend database is Postgres. For tested versions and required/recommended modules please check the INSTALL pdf on the Documentation page.
There are five main components to the NZ-SRS software:
|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.
|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.
An additional component is the scheduled jobs daemon which is distributed in the back-end bundle. It 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).
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 read-only transactions. This is achieved by running these front-ends in 'maintenance' mode.
Registrar Implementation Kit and User Interface
The RIK (Registrar Implementation Kit) is a sample implementation of a registrar client developed by NZRS and can be used for testing the configuration of the NZ-SRS or as a template for other implementations of the DNRS. The RIK can be found on the NZRS website.
A browser based client user interface is available for download on the same website as the RIK, which can also be used to test the DNRS implementation.