C17.4. Zone file generation. Procedures for changes, editing by registrars, updates. Address frequency, security, process, interface, user authentication, logging, data back-up.

The Zone Update Service is responsible for retrieving DNS data from the Registry Database and populating these changes to the Registry Name Servers.

Unity Registry understands the importance of the requirements that the zone file be maintained with the highest degree of Data Integrity, security and validity and hence have identified and developed a set of procedures that enforce:

• the Unity Registry database and zone files are and stay synchronized
• updates are transferred efficiently and effectively in a timely manner
• all Zone Updates conform to RFC 2136

Change Process:

Changes to the DNS records contained within the registry are completed by Registrars through the use of the EPP, “thin” EPP or RRP Protocol. These protocols provide the registrars with the ability to add, remove and change the contents of the zone file. Authentication is provide in the implementation of the EPP and RRP protocols.

Name Server Architecture:

Unity Registry will follow the model of AusRegistry and use  a Stealth Primary Name Server.  This Name Server cannot be seen by the public, and is updated the instant a registrar makes any changes which result in a required DNS update. The required change is written to a DNS update queue contained within the database, this then triggers the zone update daemon that is waiting to service the queue whenever any requests are fed into it to be serviced. These updates are propagated to Nominum (our nominated DNS provider) via BIND 9 and standard IXFR mechanisms. The Registrars communicate all their updates to Unity Registry via the use of the RPP or EPP protocol.  (Refer to the diagram below.)

The Unity Registry .org zone file is to be maintained by the Zone Update Daemon.  Through other services of the registry, registrars are able to update the relevant DNS information associated with their domains at any time.  This update will result in a Dynamic Update request being added to the dynamic update queue in the database. It is the zone update daemons responsibility to await for a signal from the database, awaken and then service this queue and translate those requests into dynamic update request as per the DNS protocol (RFC-2136)

These dynamic updates allow Unity Registry to apply updates, create new domains and remove old ones, to the zone file dynamically and instantly rather than having to rebuild the zone file from scratch at specified intervals and then restart the name server software, which if there was any error in the writing of the zone file would result in the name server not restarting. If an erroneous or improper DNS update request is received by the Name Server it will simply return an error code and reject the update request, however it will still continue to function and these would not cause the machine to crash. It also allows the zone update tool to more accurately find the source of the problem with the zone information and possibly even attempt some self correction, or at least able to identify the fact that inconsistencies are present the moment they appear, and notify the relevant people via the alert system making for an intelligent and fast solution to updating DNS that avoids the messy regeneration of zone files. Should the need arise tools exist that allow Unity Registry to build an entire zone file from scratch off the database. Each dynamic update request results in a corresponding IXFR request being sent to all the secondaries thus allowing Unity Registry to facilitate the update and propagation of zone changes quickly and efficiently.

When a zone update is necessary, the Unity Registry Database places a zone update message on a message queue which contains all the information required for the update.  The zone update receives and interprets these messages then makes the appropriate dynamic update to the stealth Primary Name Server.  (Refer to the Diagram below.)

Security

The Unity Registry Name Server and Zone Update Tool will reside behind firewall and will not be seen by the public.  The Name Server will be configured to only propagate changes to known registered secondaries (i.e. the Nominum update server) which must have a valid TSIG key that matches the one in the Name Server. This is a different TSIG key than the one that is required to send the dynamic updates to the name server thus guaranteeing that the only server possibly sending update requests to our server is our update server on an internal IP address.

Redundancy

Unity Registry will have a backup Stealth Name Server which is configured as a secondary to the primary server. The primary is monitored and as soon as it goes down, monitor scripts change the secondary into a primary and allow it to take over the IP address of the now faulty Primary. This ensures that dynamic update requests are now received by the new server and the Nominum name server is able to still receive updates.