rfc2832.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                      S. Hollenbeck
Request for Comments: 2832                                 M. Srivastava
Category: Informational                 Network Solutions, Inc. Registry
                                                                May 2000


          NSI Registry Registrar Protocol (RRP) Version 1.1.0

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This document describes a protocol for the registration and
   management of second level domain names and associated name servers
   in both generic Top Level Domains (gTLDs) and country code Top Level
   Domains (ccTLDs). This protocol was developed by the Network
   Solutions Registry for use within the Shared Registration System and
   is being published "as-is" to document the protocol implementation
   developed by the Network Solutions, Inc. Registry.

   Internet domain name registration typically involves three entities:
   a registrant who wishes to register a domain name, a registrar who
   provides services to the registrant, and a registry that provides
   services to the registrar while serving as the authoritative
   repository of all functional information required to resolve names
   registered in the registry's TLDs.  This document describes a
   protocol for registry-registrar communication only.  The protocol
   does not provide any registrant services.

   This document is being discussed on the "rrp" mailing list.  To join
   the list, send a message to <[e-mail]> with the
   words "subscribe rrp" in the body of the message. There is also a web
   site for the mailing list archives at
   <http://www.NSIRegistry.net/maillist/rrp>.

Conventions Used In This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [MUSTSHOULD]. Further,



Hollenbeck & Srivastava      Informational                      [Page 1]

RFC 2832            NSI Registry Registrar Protocol             May 2000


   the term "implicit attribute" refers to an entity attribute whose
   value is derived either from another attribute or is dependent on an
   established RRP session.

   In examples, "C:" represents lines sent by the registrar client and
   "S:" represents lines sent by the registry server.

   The term "System" is used in this document to collectively refer to
   this protocol and the software and hardware that implements the
   protocol.

Table of Contents

   1. Introduction .................................................    3
   2. Security Services ............................................    4
   2.1 Connection Security .........................................    4
   2.2 System Data Security ........................................    5
   3. Connection Model .............................................    5
   4. Protocol Description .........................................    6
   4.1 Request Format ..............................................    7
   4.2 Response Format .............................................    8
   4.3 Protocol Commands ...........................................    8
   4.3.1 ADD .......................................................    8
   4.3.2 CHECK .....................................................   11
   4.3.3 DEL .......................................................   12
   4.3.4 DESCRIBE ..................................................   14
   4.3.5 MOD .......................................................   14
   4.3.6 QUIT ......................................................   16
   4.3.7 RENEW .....................................................   17
   4.3.8 SESSION ...................................................   18
   4.3.9 STATUS ....................................................   18
   4.3.10 TRANSFER .................................................   21
   5. Response Codes ...............................................   23
   5.1 Response Code Summary .......................................   23
   5.2 Command-Response Correspondence .............................   28
   6. Domain Status Codes ..........................................   29
   6.1 Domain Status Code Description ..............................   30
   7. Formal Syntax ................................................   30
   8. Internationalization .........................................   35
   9. Known Issues .................................................   35
   10. Security Considerations .....................................   37
   11. IANA Considerations .........................................   37
   12. References ..................................................   37
   13. Acknowledgments .............................................   38
   14. Authors' Addresses ..........................................   38
   15. Full Copyright Statement ....................................   39





Hollenbeck & Srivastava      Informational                      [Page 2]

RFC 2832            NSI Registry Registrar Protocol             May 2000


1. Introduction

   This document describes the specifications for the NSI Registry
   Registrar Protocol (RRP) version 1.1.0, a TCP-based, 7-bit US-ASCII
   text protocol that permits multiple registrars to provide second
   level Internet domain name registration services in the top level
   domains (TLDs) administered by a TLD registry. RRP is specified using
   Augmented Backus-Nauer Form (ABNF) as described in [ABNF]. Note that
   all ABNF string literals are case-insensitive and the examples
   provided in this document may use mixed case to improve readability.

   RRP was developed by the Network Solutions, Inc. Registry under the
   auspices of the Shared Registration System program. The protocol was
   initially deployed in April 1999 as part of a test bed implementation
   of the Shared Registration System with five registrars. Additional
   registrars began using the protocol in July 1999. The operational
   experiences of both the registry and the registrars identified
   several "lessons learned" which have been documented here as "Known
   Issues".

   This document provides both a description of a protocol and notice of
   learned operational issues that may be useful as first steps in
   developing a standards track domain registration services protocol.
   This document and the protocol it describes may be modified in the
   future based on continued operational experience and community
   reaction.

   The registry stores information about registered domain names and
   associated name servers. A domain name's data includes its name, name
   servers, registrar, registration expiration date, and status. A name
   server's data includes its server name, IP addresses, and registrar.
   A registrar MAY perform the following registration service procedures
   using RRP:

   - Determine if a domain name has been registered.
   - Register a domain name.
   - Renew the registration of a domain name.
   - Cancel the registration of a domain name.
   - Update the name servers of a domain name.
   - Transfer a domain name from another registrar.
   - Examine the status of domain names that the registrar has
     registered.
   - Modify the status of domain names that the registrar has
     registered.
   - Determine if a name server has been registered.
   - Register a name server.
   - Update the IP addresses of a name server.




Hollenbeck & Srivastava      Informational                      [Page 3]

RFC 2832            NSI Registry Registrar Protocol             May 2000


   - Delete a name server.
   - Examine the status of name servers that the registrar has
     registered.

   All RRP commands include features to provide idempotency.  That is,
   the effect of each command is the same if the command is executed
   once or if the command is executed multiple times. This property is
   extremely useful in situations when a command is retried due to an
   error condition that results in a missed command response and a
   command retry is attempted. Command retries will be caught by the
   System and rejected with an appropriate error response code. Command
   parameters that do not provide idempotency will be explained fully as
   part of the appropriate command description.

2. Security Services

   RRP provides only basic password-based registrar authentication
   services.  Additional security services, including privacy and
   registrar authentication using public key cryptography, are provided
   through other System features.

2.1 Connection Security

   Each RRP session MUST be encrypted using the Secure Socket Layer
   (SSL) v3.0 protocol as specified in [SSL]. SSL provides privacy
   services that reduce the risk of inadvertent disclosure of
   registrar-sensitive information, such as the registrar's user
   identifier and password.

   SSL supports mutual authentication of both the client and server
   using signed digital certificates. The Shared Registration System
   implemented by the NSI Registry requires digital certificates issued
   by a commercial certification authority for both registrar clients
   and public registry RRP servers. Both the registrar client and the
   public registry RRP server are authenticated when establishing an SSL
   connection. Further, a registrar MUST be authenticated when
   establishing an RRP connection via the RRP SESSION command by
   providing a registrar user identifier and password known only to the
   registrar and the System. Registrars may change their session
   password at any time using the RRP SESSION command.

   The SSL protocol is not an IETF Standards Track protocol. The
   Transport Layer Security protocol, specified in [TLS], is a Standards
   Track protocol that provides SSL v3.0 compatibility features.







Hollenbeck & Srivastava      Informational                      [Page 4]

RFC 2832            NSI Registry Registrar Protocol             May 2000


2.2 System Data Security

   The System stores information about the registered domain names and
   their name servers.  Only the current registrar of a registered
   domain name is authorized to query it, update its name servers, and
   cancel or renew it. Any registrar can request a transfer of a domain
   name and its associated name servers from another registrar to the
   requesting registrar. Only the current sponsoring registrar can
   receive and explicitly approve or reject domain transfer requests.

   Only a name server's registrar can query, update, and delete it.  In
   general, name servers must be registered through the current
   registrar of the name server's parent domain name, though an
   implementation MAY allow use of name servers registered in other TLDs
   without specifying IP addresses or requiring parent domain
   registration. Use of ccTLD name servers for a gTLD domain name is one
   such example.

   Name servers are implicitly transferred by the System when their
   parent domain name is transferred. In addition, a name server cannot
   be deleted if it is hosting domain names.

3. Connection Model

   IANA has assigned TCP port 648 for RRP use. All RRP implementations
   MUST provide RRP services over SSL on TCP port 648. An RRP server
   MUST return a banner in the following format to confirm that a
   connection has been established:

   <registry name> RRP Server version <version><crlf>
   <server build date and time><crlf>

   Each line ends with carriage return and line feed characters. The
   server build date and time string includes the day, month, date, time
   (specified in hours, minutes, and seconds), the local time zone, and
   the four-digit year. A dot (".") in column one on a line by itself
   marks the end of banner text.

   Example

   A registrar successfully establishes a connection with the NSI
   Registry on TCP port 648:

   S:NSI RRP Server version 1.1.0
   S:Mon Oct 25 20:20:34 EDT 1999
   S:.





Hollenbeck & Srivastava      Informational                      [Page 5]

RFC 2832            NSI Registry Registrar Protocol             May 2000


4. Protocol Description

   A typical RRP session will go through a number of states during its
   lifetime.  Figure 1 illustrates the possible states of an RRP server.

   Initially, the server waits for a client connection and
   authentication (PRE).  All client connections MUST be authenticated.

                                      |
                                      |
                                      v
                             +-----------------+   Timeout
                             |   Waiting for   |-------------------+
   Authentication Succeeded  |      Client     |                   |
                   +---------|  Authentication | Authentication    |
                   |         |      (PRE)      |-----+  Failed     |
                   |         +-----------------+     |             |
                   |                                 |             |
                   V                                 V             |
             +-----------+     Succeeded    +--------------------+ |
             |Waiting for|<-----------------|    Waiting for     | |
             |  Command  |----------+       |Authentication Retry| |
             |   (WFC)   |  Timeout |       |       (WFR)        | |
             +-----------+          |       +--------------------+ |
                 |   ^              |           |         |        |
                 |   |              |   Timeout |         | Failed |
         Request V   |Response      |           |         |        |
             +-----------+          |           V         V        V
             | Executing |          |          +--------------------+
             |  Command  |          +--------->|    Disconnected    |
             |   (EXE)   |-------------------->|       (DIS)        |
             +-----------+          QUIT       +--------------------+

                Figure 1: RRP Server Finite State Machine

   If the authentication fails, the server gives the client another
   chance to identify itself (WFR). If the authentication fails again,
   the server disconnects (DIS).  Otherwise, the server waits for a
   request from the client (WFC).  Upon receiving a request, the server
   executes it and responds to the client with the result (EXE). The
   server then waits again for another request from the client (WFC). If
   the client sends a QUIT command, the server ends the session and
   disconnects (DIS). To keep its state in sync with that of the server,
   the client SHOULD wait for a response from the server before sending
   another request on the same connection.  The following table
   summarizes these states:





Hollenbeck & Srivastava      Informational                      [Page 6]

RFC 2832            NSI Registry Registrar Protocol             May 2000


        PRE     Waiting for client connection and authentication
        WFR     Waiting for authentication retry
        WFC     Waiting for a command from an authenticated client
        EXE     Executing a command
        DIS     Disconnected

   The WFR and WFC states MAY time out. An implementation SHOULD define
   inactivity timeout periods for these states based on System-specific
   factors, including (but not limited to) resource availability and
   security risk. In the absence of other factors, a default timeout
   period of 10 minutes SHOULD be used. The server MAY disconnect if the
   server is in one of these states and no message is received from the
   client during the timeout period.

4.1 Request Format

   An RRP request nominally consists of a command name, an entity block,
   command options, and an end-of-command delimiter. Command options and
   entity blocks collectively define command parameters and their
   specification is order independent; examples provided in this
   document specify entity blocks before command options.

     CommandName [EntityBlock] [CommandOptions] EndOfCommand