Proposed Unsponsored TLD Agreement: Appendix C, Part 8 (.name) (2 July 2001)

Part 8 - Other Services

A. Whois

Whois services are described in Appendices O, P, and Q to the Registry Agreement.

B. Landrush Queuing

Landrush queuing is described in Appendix J to the Registry Agreement.

C. Data Escrow

Data escrow services are described in Appendices R and S to the Registry Agreement.

D. Zone File Access

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.
Security

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:

bash$ scp -p ICANN@update.nic.name:name.zone name.zone
ICANN@update.nic.name's password: ********
name.zone 100% |**********************| 1230124 00:12
bash$

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.

• All encryption, integrity, and public key algorithms used are well-known, well-established algorithms.
  
• All algorithms are used with cryptographically sound key sizes that are believed to provide protection against even the strongest cryptanalytic attacks for decades.
  
• All algorithms are negotiated, and in case some algorithm is broken, it is easy to switch to some other algorithm without modifying the base protocol.

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.

FTP

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:

ftp ftp.nic.name
User: ICANN
password: ********
200 Welcome to the .name FTP Server
ftp> get master.name.zone.gz
200 RETR master.name.zone.gz master.name.zone.gz
200 PORT xxx...
Opening BINARY mode connection for master.name.zone.gz (12301 bytes)
200 Transfer complete.
ftp> bye

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.
Should unauthorised access to the data be detected, including but not limited to multiple accesses in the same 24 hour period and incorrect password entry after three login attempts, the account will be suspended until such time as the Registry Operator has sufficient mitigating proof of good conduct from the relevant Appendix N entity.

E. WWW Interface

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.
Public Section

The public section is designed to educate and provide timely information to the public about .name and the Registry Operator.

Registrar Section

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:

• An interface that allows Registrars to administer their domains
  
  • Check
    
  • Query
• An interface that allows Registrars to administer nameservers assigned to domains.
  
  • Check
    
  • Query
• An interface that allows Registrars to administer their contact information
  
  • Search
    
  • Add
    
  • Edit
    
  • Delete
• A report interface that allows Registrars to access information relevant to their account.
• A policy section that will contain contracts, charters and other relevant documents that outline how .name will operate.

Page Updated 03-Jul-2001
(c) 2001  The Internet Corporation for Assigned Names and Numbers. All rights reserved.