Generic Top-Level Domain (gTLD) Registry Agreements
Proposed Unsponsored TLD Agreement: Appendix C, Part 8 (.name)
Part 8 - Other Services Whois services are described in Appendices O, P, and Q to the Registry Agreement. Landrush queuing is described in Appendix J to the Registry Agreement. Data escrow services are described in Appendices R and S to the Registry Agreement. Zone file access is provided by the Registry Operator under Subsections 3.9.1 and 3.9.2 to the Registry Agreement. See also the Zone File Access Agreement set forth in Appendix N to the Registry Agreement. General Specification The Registry Operator will undertake to provide the full DNS zone files for the .NAME Registry via FTP and SCP (details of which are in the following sections). This zone file data will be refreshed at least once in every 24 hour period. Authorised users (as per Appendix N) will have access to this data and are permitted to retrieve it no more than once every 24-hour period. (This limitation does not apply to ICANN.) The zone files are to be generated by the update server and compressed using GNU gzip to reduce transmission times. The zone files are retrieved from the master name server using an AXFR (Authoritative Zone Transfer) request, and are then compressed on the update server to conserve space. When the full set of compressed zone files have been generated, they will be transferred to the FTP service ready for download. Reporting All successful zone file generation attempts will be logged with the date and time of completion. The total size of all zone files (before compression) will also be stored in this log entry, for statistics tracking purposes. Unsuccessful generation will be logged with reason for failure, date and time, and will also notify the Registry Operator technical staff using email and SMS. Each authorised user as indicated in Appendix N will be issued a user ID and password. The zone file data is considered sensitive, and unauthorised access is to be discouraged. Security precautions vary depending on the method of access; see the FTP and SCP service sections below for more information on this. The Registry Operator does recommend that the SCP service be used in preference to FTP, due to the extra security afforded by the former service. SCP Specification The Registry Operator will provide an SCP service to permit authorised users to access the zone file. Zone file data will be provided in a compressed format complying with the GNU gzip standard. SCP is the Secure Copy application provided as part of SSH, the Secure Shell system designed by SSH Communications Security. It offers a secure link between two internet-connected systems, used for transferring sensitive data, and the protocols are well-documented and are in the process of continued revision by the IETF. The underlying protocols and structure for SCP are common throughout the SSH application suite; the SCP application is a simple implementation of a comprehensive secured communication system. It is a revised version of the standard Unix copy command, "cp", which uses the SSH architecture to transmit data across an unsecured link. A correctly configured system with an SSH daemon installed will be able to receive files from a similarly configured system, using the SCP command, with sufficient protection from outside snooping. For further information, including draft RFCs and whitepapers on SSH, go to: http://www.ssh.com/tech/archive/secsh.html. This connection method provides greater security than a standard FTP connection and is the recommended method for zone file retrieval. Operational Parameters A typical SCP session on a Unix shell would resemble the following:
Since SSH implementations vary between vendors and platforms, full instructions on using the SCP service are beyond the scope of this document. Reporting Each connection attempt will be logged with date and time information, including the IP address of the client and the username and password provided. The log will also include an indication of the success or failure of the connection and a status report for the file transfer. Any unauthorised attempt to access the SCP service will be logged in the usual way, however if more than two unsuccessful attempts are made then the notification procedure will be initiated. This will distribute email and SMS alerts to the relevant personnel Security SCP is inherently more secure than standard FTP, since key exchange is transmitted encrypted, and an asymmetrical key algorithm is used for the key negotiation process. SCP also has the advantage of simplicity, unlike FTP, which has many unnecessary features for this purpose which could make it vulnerable to a range of well-known attacks. An implementation of SSH is available for most platforms, and open source versions exist which are readily adapted to any platform with some semblance of POSIX compliance. As stated in the SSH draft RFC: The primary goal of the SSH protocols is improved security on the Internet. It attempts to do this in a way that is easy to deploy, even at the cost of absolute security.
The protocol does provide good mechanisms for replacement encryption methods if a flaw is found in a current protocol. The extensibility of the SSH system leaves an open upgrade path, and the Registry Operator believes that SSH is the most appropriate method for transmitting secure data across the internet. Specification The Registry Operator will provide an FTP service complying with a subset of the current File Transfer Protocol standard (currently RFC959). Some features that pose security risks, obsolete backwards-compatibility issues, or non-essential functions which are deemed by the Registry Operator to be superfluous to the purpose of providing access to the zone files, will not be implemented. FTP access is for the sole reason of obtaining the zone file data as defined in Appendix N, and as such is not a common service. Most internet end-users will be unable to access this FTP service, and would have no interest in doing so. The Registry Operator does not recommend the use of FTP to retrieve zone files; SCP provides better security, see the SCP section for more details. The zone files will be stored on an FTP server, the canonical DNS name of which is defined in Appendix X, in the root directory. The base .NAME zone file will have the file name "master.name.zone.gz", and further zone files for the .NAME zone will be named similarly. These files are GZIP-compressed zone data as defined in the "Zone File Access Provision" section. No other files will be accessible from this FTP service. Example An example FTP session would be of this form:
Reporting Each transaction is to be recorded in a secure log, together with an indication of success or failure of the operation. Transaction details will comprise IP address of source request, dialogue between client and server, user ID and password supplied, and success or failure of zone file transfer. This information is to be transmitted to the main site logs for later permanent storage. Each zone file transfer to the FTP service will also be logged. This log should therefore contain one entry per 24-hour period, describing the successful transfer of the GZIP-compressed zone file to the FTP service ready for transmission. Security The Registry Operator recommends that the session password be encrypted according to the provisions of RFC 2228, since RFC959 FTP is potentially insecure across an open network channel such as the Internet. Goals The goals of the .name website are to communicate openly and efficiently with the public, Registrants, ICANN and any other interested parties. It will provide Registrars with the information they require to operate efficiently. Site Structure The Registry Operator website will be composed of a publicly accessible section and a section devoted exclusively to the Registrars. It will be available at http://www.nic.name and other URLs selected at Registry Operator's discretion. The Registrar section will only be accessible to Registrars, and will have a login screen with a username and password to verify Registrar identity. The Registrar section will be hosted as a secure site using SSL to provide privacy and security for the Registrars. The design shown in this document is for example purposes only and the Registry Operator reserves the right to make changes. Significant functionality and policy changes will be handled according to the procedures for revisions in the Registry Agreement. The public section is designed to educate and provide timely information to the public about .name and the Registry Operator. The Registrar section will provide the Registrars with a one-stop service for the most used operations. The functions that the Registry Operator has identified as key to increasing Registrar efficiency include but will not be limited to:
Comments concerning the layout, construction and functionality of this site should be sent to webmaster@icann.org.
|