The SRS - High Level Requirements 18/06/01

The purpose of this paper is to provide a first step in outlining the functional requirements for the SRS for managing .nz domain names. The end product of this work will be a comprehensive statement of the functional requirements of an SRS.

Please note that some issues that will influence the functional requirements, such as the registry charging policy, have yet to be decided.

Comments should be sent to rose.percival@isocnz.org.nz.

The Internet Society of New Zealand is committed to establishing a Shared Registry System for the registration and management of .nz domain names. The SRS Implementation Oversight Committee will oversee this project.

1. Overview

The Internet Society of New Zealand (ISOCNZ) is committed to the implementation of a shared registry system for the management of the .nz ccTLD. The.nz ccTLD is currently managed by a fully owned subsidiary company, NZIRL (trading as Domainz), which operates the registry and is the sole registrar. Accredited and unaccredited resellers and individuals currently access the .nz registry via Domainz, either using an email template or completing standard forms via the Domainz website.

The achievement of a shared registry system for .nz domain requires the implementation of new registry software that enables authorised registrars to interface with the register through a secure means transmitting and receiving XML messages. A web-based "whois" search function is required, complemented by static information pages.

The two key principles that will guide the SRS establishment are:

• To establish a competitive but stable environment, in which registrants' rights are safeguarded; and
• To ensure that the register, as a monopoly provider, is operated in a responsible (technical, legal and fiscal) manner.

2 .nz Domains

Further information can be found on .nz domains at www.domainz.net.nz and www.isocnz.org.nz.

There are approximately 100,000 domains registered in .nz and new registrations are growing at around 5,000/month. There are a number of second level domains, four of which are moderated. The .nz domain space is an open domain, with very few policies or restrictions limiting its use.

New Zealand is generally quick to access and adapt to new technology, including the internet. However, given the relatively small size of the .nz market, the globalisation of business assisted by the internet and the need for the .nz domains to be internationally competitive, the SRS solution must be capable of being operated at a low cost, both for the registry and registrars.

3. Standards

There are a number of minimum requirements that the SRS has to comply with. These include:

• The .nz register has to operate in a manner consistent with New Zealand law, including tax legislation (e.g. GST) and competition law.
• The register must be capable of residing in, and being managed from within New Zealand
• All components must conform with ISOCNZ and international policy. For example, there must be a commitment to upgrade to the IETF Extensible Provisioning Protocol (EPP) once this is finalised.

The SRS must have the following capabilities:

- Persistence - storage and random retrieval of data

- Concurrency - able to support multiple users concurrently.

- Distribution (data replication) - maintenance of relationships across multiple databases

- Integrity - methods to ensure data is not lost or corrupted

- Availability - support for 24 x 7 x 365 operations

- Scalability - unimpaired performance as the number of users, workload volumes or database size increases.

4 SRS Requirements

4.1 The Domain Name

The nature of the .nz SRS means that sufficient registrant contact information is held in the register to determine the true registrant.

It is proposed that the information held against each domain name is as follows. The length of fields is to be consistent with that specified for the current DRS.

• Domain name (registrar provides)
• Designated registrar (registrar provides/amendable)
• Registrant name and contact information (registrar provides/amendable)
• Name servers (multiple, minimum of two, maximum of four)(registrar provides/amendable)
• Administrative contact information (registrar provides/amendable)
• Technical contact information (registrar provides/amendable)
• Registrant authentication field or equivalent (system generated)
• Creation Date and Time (system generated)
• Expiry Date (registrar provides - links to the billing module to calculate fee)
• Registration status (system generated) - registered/available are the two main statuses with various subsets of registered : e.g.
  New name (registered but not yet in the zone)
  Active (current and is published in a zone, can be amended)
  Inactive (can be amended but is not published as no authoritative name servers)
  Locked (may not be modified and is published in a zone)
  Pending transfer
  Pending removal
• Date and Time of Last Successful Update (system generated)

The information submitted by the registrars will have to be validated - in terms of the minimum/maximum number of characters and type of characters/object and the information provided (e.g. minimum of two name servers, maximum of four). Registrations/amendments that fail the validation rules are to be rejected and returned with the relevant error message specifying the reason.

All contact details are to include the following:

• Name (individual) or
• Organisation name (if applicable), and
• Person acting on behalf of organisation (required if organisation name is provided)
• Email address, and
• Address, and
• Phone number (s), and
• Fax number

4.2 Registrars

Base Functionality

Registrars will want to be able to:

• Send a single/multiple "is it available" request(s) for names without doing a web-based "whois" search
• Create, amend (includes renew),and cancel/discharge domain names
• Register, modify, delete name servers
• Modify contact information for a domain name
• Pull domain names to them due following a transfer of registrar request (validated by the registrant authentication data or equivalent)
• Batch amend registrar administrative/technical, name server changes
• Run query reports on their own activity
• Reset their passwords
• Have a parameter driven grace period facility during which time a request to register a domain name or other billable service can be reversed by the registrar without incurring the fee etc.

They will also require some online help facilities.

The SRS must provide a process whereby a registrar, on instruction from a registrant, can pull a domain name to them as the new registrar. It is preferable that the SRS provides some form of authentication that a new registrar can ask for from the registrant. The SRS should not provide the current registrar the option of approving or rejecting the transfer.

Registrar Details

The register will need to maintain a database of current and past registrars.

The following information about the registrar will be held:

• Registrar name and url* (and link to their website)
• Name server details *
• Technical contact details *
• Administrative contact details *
• Billing contact details * (where these are different to the administrative contact details.)
• Monthly credit limit
• Bank account details *
• Authorisation date
• Expiry date (this depends on the type of regime registrars will operate under)
• Date of cessation/cancellation of authorisation
• Reason for cessation/cancellation ()

Registrars should be able to amend the details held on the register that are marked with an asterisk above. They must be able to globally amend the registrar-specific details required for a domain name registration, (e.g. name server details, technical contact details, registrar name). They should not be required to individually amend the registrar-specific details for every domain name record for which they are the designated registrar. This functionality could also be used for takeovers/mergers/sales of registrar businesses, but there will need to be safeguards to ensure that this does not enable a third party to become a registrar without meeting the minimum requirements established by the ccTLD manager (for example, a consent process, whereby the consent of the ccTLD manager would not be unreasonably withheld).

Registrars Interface with the Register

Registrars will only be able to communicate with the register via a secure session. The registry will provide a software development kit to enable registrars to develop their interface with the register.

A test environment will be provided for registrars to test their interface. Registrars will need to meet minimum technical requirements to ensure that the data passed to and from each function operates correctly, the "is it available" function retrieves the correct information and the update functions maintain the correct information.

It is anticipated that from time to time, there will be upgrades to the register software. The register will support more than one version of the software and registrars will have a minimum of 6 () months from the release of an upgrade before they are required to upgrade their own software. At the time the register enhancements for software upgrades are consulted on (at a minimum with the Standing Committee, but this must include communication with all authorised registrars), a statement will be issued detailing the oldest version of software that will be supported at the time of the rollout of the enhancement.

Registrar Management Reports

Registrars should be able to run queries against the current domain name registrations on the register for which they are the designated registrar. Examples of these are:

• Identify domain name registrations that will expire in the next x days
• Domain names against x name server
• What else

Registrars must be able to access their own account statements and detailed transaction reports but not those of other registrars. Queries may include:

• Current account balance
• Reconcile invoices

Registrars must also be able to request custom reports, that will be run in a batch process for them.

The nature of some of the management report functionality will depend upon the option selected for charging (monthly fee/domain name versus annual registration fee).

4. The Register

Automated Functions

The following are the minimum requirements:

• Automated database backups/checks etc (to industry best practice standards or better)
• Automatic change of status on the meeting of certain criteria (the Registry must have the ability to amend the criteria). As an example. automatic expiry of registrations that have met their expiry date and placement of these domain names in a pool where they will remain as "pending removal" for a period of x days. At the end of x days, the register needs to change the status of these names to available.
• Automatic notification to a registrar
  - when another registrar pulls a domain name to them on the instructions of a registrant
  - when a domain name for which they are the designated registrar is about to expire - at 60 days prior to expiry, 30 days, 10 days (the number of days being a parameter that is able to be changed by the registry) (able to be turned off or on at the registrar's option)
  - when the domain name for which they are the designated registrar is transferred to the "registered - pending removal" pool.
  - when the domain name for which they are the designated registrar is transferred from the "registered - pending removal" pool to "available".
• The system will perform validation on the data wherever this is specified for that field.
• Others

Audit Log and Reproduction of the Data

All changes to the data in the register is required to be tracked and logged, regardless of whether they are changed at the front end or the back end database. All changes are to be date and time stamped, and identified by the registrar/systems administrator. The register must be able to reproduce the registrant details attaching to a domain name at any point in time, including the administrative and technical contact details. There is a need for a high level of surety in reproduced results. Therefore, data is never to be deleted from the register.

Lapsed, "deleted" or expired registrations are to be withheld from public view (through the "whois " window), but are held within the database (possibly archived at some future point in time). Where a domain name registration has lapsed, the name is to be held in a pool for a period of x months, at which time it can be uplifted again by a registrar acting for the registrant. After x months, the domain name becomes available for re-registration by another registrant. The database therefore needs to be able to cope with this re-registration, while maintaining the requisite records of the history of that domain name in its prior registration.

The audit trail must be network wide.

Security

All data in the register must be secured against damage, loss or unauthorised access. The main requirement is that of integrity, both of the data held on the register and who is able to access this to change it.

The security must include user profiles to enable the registry to grant or deny access privileges to registrars, database users and database administrators.

Each registrar will have to go through some form of authorisation gate, that establishes that the registrar is appropriately authorised to access the registry database. Each registrar must only be able to access domain name records for which they are the designated registrar The system needs to run validation checks to authenticate the registrar ID and other details (what).

It is proposed that there is a registrant authentication field for each domain name, and this becomes in effect part of the security information required to amend data relating to that domain name on the database. The register will need to automatically change this field immediately after a registrar, on instruction from the registrant, "pulls" the domain name from another registrar. The register will need to notify the new registrant authentication field to the newly designated registrar. (Or is there a simpler way to do this)

The security for the system should conform to industry best practice standards current at the time of implementation. For example, there must be provision for network-based intrusion detection.

4.4 The Registry

Database Management

Registry staff must be able to:

• Create, suspend, disable or modify registrars
• Grant or deny access privileges to any user
• Assign, modify and remove rights to register specific second level domain names to registrars
• Access all registration data to modify (e.g. to carry out a court's instructions). The system must log the activity and the user ID (registry) in the same way as it does for registrar initiated amendments.
• Cancel, hold or lock a domain name
• Generate an email and/or letter to registrants where their registrar fails/is disabled etc with a list of other registrars
• Set criteria, which when met, will automatically cancel domain names
• Set criteria, which when met, will prevent domain names being cancelled
• Generate lists of domain names which meet user set criteria
• Generate bulk transactions
• Do a manual zone push
• Run routine and ad hoc management reports (e.g. Record registrations for any specified period)

Systems Management

The minimum requirements are:

• All hardware, software and network components are to be the subject of operations and management contracts which will seek to ensure continuous 24 x 7 x 365 support (99.5 - 99.9% availability), maintenance and replacement when required.
• Connectivity must be provided through a secure, robust and efficient WAN.
• All components of the DNS server system and network are to be secured to prevent theft or corruption of domain name records. This must include secure routing, firewalls and switches. An "invisible" primary server, which can only be accessed by the secondaries, must be maintained. This means that if any secondary is hacked or tampered with, it can easily be recreated from the primary.
• Proactive monitoring of all hardware, software and network components to immediately identify and locate failures, errors and security breaches.
• Sufficient resource in all hardware, software and network components to accommodate significant expansion of the DNS and expected technology innovations such as DNSSEC and Ipv6.
• Remote management of network components, supported by robust authentication of the user.

Invoicing/Billing

The billing module must be able to:

• Invoice for regular and one-off charges, generate GST (and non-GST) invoices, statements and reminder notices; to accept manual (cheques) and electronic payments (direct debits and credit cards); to issue receipts; to reconcile receipts with charges; to manage debtors processing and to create general ledger transactions.
• Reverse and waive charges in a way that does not affect the registration status of a domain name
• Split out new registrations and renewals (if this pricing structure is maintained)
• Generate standard and ad hoc reports
• Generate files to send to registrars to enable them to reconcile the invoice with their own transaction records.
• Generate duplicate invoices for a specified period for a designated registrar.

The interaction between the billing module and the registration database must be such that the following does not occur in the SRS environment:

• If an invoice is raised prior to the current registration expiring, the renewal fee should not be treated as a debt from the date the invoice is raised rather than when the registration expires
• The anniversary date should not be set to the following year (as though the renewal has been completed) on the raising of the renewal invoice.

Management Reports

Reporting and statistical reports required include:

• Total registrations/designated registrar
• Number of new registrations by date registered/registrar/zone/status and combinations of these
• Number of domain names transferred by date of transfer/registrar/zone and combinations of these
• Number of domain names cancelled by date of cancellation/registrar/zone/length of registration
• Others to be specified.

Performance Data

The registry and office of the ccTLD manager must be able to obtain data relating to the performance of the register, including % availability over a specified time period.

Enquiry logging, tracking and performance reporting will be required by the office of the ccTLD manager to measure the performance of the registry.

4.5 The DNS Component

The following is required:

• A secure primary DNS database holding unique domain name records, which is updated from the .nz registry database at user defined intervals (at a minimum, twice daily but more frequent updates are required)
• The primary DNS database must be hidden so that it can only be written to from the .nz registry (during zone pushes) and can only be read from the secondary DNS servers)
• A series of secondary DNS databases, which direct domain names to the appropriate name servers on an uninterrupted 24 x 7 basis must be maintained. These must be spread geographically to provide an optimum response time for global access.
• The secondary servers must allow controlled zone transfers in accordance with the policy.
• A full audit trail of all pre- and post-change DNS records must be maintained. Must be able to recreate the zones for any given day, either from the BIND records, or the registry, or both.

4.6 Web-Based Access

This is to be limited to a whois function to check domain availability and/or contact details for the current registrant and static information pages.

Whois

The public require access to real-time who is search via the web.

If the name is already allocated, the details of the registrant should be displayed. (What should be displayed - all the current information contained on the register Currently do not display the expiry date which would be essential if there are multiple registration/renewal periods available. Currently display a modified date but it does not necessarily relate to the expiry date and cannot assume that the public know it is for one year only.)

Static Pages

These must be well designed and easy to navigate. Authorised registry staff must be able to update, amend, add, delete information from the static pages in a timely fashion.

The information on these pages will include:

• A list of all authorised registrars (with links to their home pages)
• A list of current second level moderators, including contact details (links to email)
• Current policy about domain names in .nz, dispute resolution etc
• Frequently asked questions
• Links to other relevant pages (e.g. office of the ccTLD manager)

Information on updates to the website must be maintained including the ID of person making the change, date and time of change, before and after versions of the change (the "before" should not be easily visible)

4.7 Other

ccTLD manager

This office must be able to view all data under its TLD management.

Housekeeping

All technical documentation must be updated to reflect design changes, be versioned and be supported by a read me document that documents the changes since the last version. All draft documentation must be annotated as such.

Transition

There will be significant transition issues to work through, particularly relating to the transfer of registrants to authorised registrars. A seamless, low risk migration of the relevant domain name data from the pre-SRS system to the SRS will be required.

Last Updated : 18 June 2001