idnits 2.17.1 draft-hollenbeck-rrp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 35 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 78 instances of too long lines in the document, the longest one being 17 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A request to delete a domain name SHOULD cause the deletion of all name servers that are children of the domain name being deleted. The name servers SHOULD be deleted if they are not actively hosting other domains. A domain MUST not be deleted if it has child name servers hosting other domains. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A name server MUST not be deleted if it is hosting domains. Deleting such domains or name servers is prohibited because their deletion WILL result in orphaning the hosted domains. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 532 Domain names linked with name server The name server is hosting active domains. This error occurs when a registrar is trying to delete a server that is the name server for active domains. The registry MUST not allow the registrar to delete this server. All of the domain names using this server MUST be modified to use a different name server before the name server can be deleted. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 540 Attribute value is not unique A supplied attribute value is not unique. This occurs when the registrar is adding a domain name that already exists in the registry, a server that already exists in the registry, or an IP address that is already being used by another server in the registry. Another possibility occurs when performing domain modifications and the registrar is adding a server that is already in the list of servers for the domain name or setting a domain name to a status to which it is already set. The RRP STATUS command MAY be used to determine current domain name status before attempting to change the status. When modifying or adding a name server, the IP address of the name server might not be unique. The registry MUST not allow IP addresses to be used by more than one server. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 1999) is 8893 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'EntityBlock' is mentioned on line 275, but not defined == Missing Reference: 'CommandOptions' is mentioned on line 275, but not defined ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2050 (ref. 'ALLOCATION') (Obsoleted by RFC 7020) -- Possible downref: Non-RFC (?) normative reference: ref. 'SSL' ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Scott Hollenbeck 2 Internet-Draft Manoj Srivastava 3 Category-to-be: Informational Network Solutions, Inc. Registry 4 Expires: June 2000 December 1999 6 Registry Registrar Protocol (RRP) Version 1.1.0 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document describes a protocol for the registration and management 32 of second level domain names and associated name servers in both Top 33 Level Domains (TLDs) and country code Top Level Domains (ccTLDs). This 34 protocol was developed by the Network Solutions Registry for use 35 within the Shared Registration System and is being published "as-is" 36 with the goal of eventual publication as an Informational RFC. 38 Internet domain name registration typically involves three entities: a 39 registrant who wishes to register a domain name, a registrar who 40 provides services to the registrant, and a registry that provides 41 services to the registrar while serving as the authoritative 42 repository of all functional information required to resolve names 43 registered in the registry's TLDs. This document describes a protocol 44 for registry-registrar communication only. The protocol does not 45 provide any registrant services. 47 This document is being discussed on the "rrp" mailing list. To join 48 the list, send a message to with the words 49 "subscribe rrp" in the body of the message. There is also a web site 50 for the mailing list archives at 51 . 53 Conventions Used In This Document 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in [MUSTSHOULD]. Further, 58 the term "implicit attribute" refers to an entity attribute whose 59 value is derived either from another attribute or is dependent on an 60 established RRP session. 62 In examples, "C:" represents lines sent by the registrar client and 63 "S" represents lines sent by the registry server. 65 The term "System" is used in this document to collectively refer to 66 this protocol and the software and hardware that implements the 67 protocol. 69 Table of Contents 71 1. Introduction ................................................. 3 72 2. Security Services ............................................ 4 73 2.1 Connection Security ......................................... 4 74 2.2 System Data Security ........................................ 4 75 3. Connection Model ............................................. 5 76 4. Protocol Description ......................................... 5 77 4.1 Request Format .............................................. 6 78 4.2 Response Format ............................................. 7 79 4.3 Protocol Commands ........................................... 7 80 4.3.1 ADD ....................................................... 7 81 4.3.2 CHECK ..................................................... 9 82 4.3.3 DEL ....................................................... 11 83 4.3.4 DESCRIBE .................................................. 12 84 4.3.5 MOD ....................................................... 13 85 4.3.6 QUIT ...................................................... 14 86 4.3.7 RENEW ..................................................... 15 87 4.3.8 SESSION ................................................... 16 88 4.3.9 STATUS .................................................... 16 89 4.3.10 TRANSFER ................................................. 19 90 5. Response Codes ............................................... 20 91 5.1 Response Code Summary ....................................... 20 92 5.2 Command-Response Correspondence ............................. 25 93 6. Domain Status Codes .......................................... 26 94 6.1 Domain Status Code Description .............................. 27 95 7. Formal Syntax ................................................ 27 96 8. Internationalization ......................................... 32 97 9. Known Issues ................................................. 32 98 10. Security Considerations ..................................... 34 99 11. IANA Considerations ......................................... 34 100 12. References .................................................. 34 101 13. Acknowledgments ............................................. 34 102 14. Authors' Address ............................................ 34 103 15. Full Copyright Statement .................................... 35 105 1. Introduction 107 This document describes the specifications for the Registry Registrar 108 Protocol (RRP) version 1.1.0, a TCP-based, 7-bit US-ASCII text 109 protocol that permits multiple registrars to provide second level 110 Internet domain name registration services in the top level domains 111 (TLDs) administered by a TLD registry. 113 RRP was developed by the Network Solutions, Inc. Registry under the 114 auspices of the Shared Registration System program. The protocol was 115 initially deployed in April 1999 as part of a test bed implementation 116 of the Shared Registration System with five registrars. Additional 117 registrars began using the protocol in July 1999. The operational 118 experiences of both the registry and the registrars identified several 119 "lessons learned" which have been documented here as "Known Issues". 121 This document provides both a description of a protocol and notice of 122 learned operational issues that may be useful as first steps in 123 developing a standards track domain registration services protocol. 124 This document and the protocol it describes may be modified in the 125 future based on continued operational experience and community 126 reaction. 128 The registry stores information about registered domain names and 129 associated name servers. A domain name's data includes its name, name 130 servers, registrar, registration expiration date, and status. A name 131 server's data includes its server name, IP addresses, and registrar. A 132 registrar MAY perform the following registration service procedures 133 using RRP: 135 - Determine if a domain name has been registered. 136 - Register a domain name. 137 - Renew the registration of a domain name. 138 - Cancel the registration of a domain name. 139 - Update the name servers of a domain name. 140 - Transfer a domain name from another registrar. 141 - Examine the status of domain names that the registrar has registered. 142 - Modify the status of domain names that the registrar has registered. 143 - Determine if a name server has been registered. 145 - Register a name server. 146 - Update the IP addresses of a name server. 147 - Delete a name server. 148 - Examine the status of name servers that the registrar has registered. 150 All RRP commands include features to provide idempotency. That is, 151 the effect of each command is the same if the command is executed once 152 or if the command is executed multiple times. This property is 153 extremely useful in situations when a command is retried due to an 154 error condition that results in a missed command response and a 155 command retry is attempted. Command retries will be caught by the 156 System and rejected with an appropriate error response code. Command 157 parameters that do not provide idempotency will be explained fully as 158 part of the appropriate command description. 160 2. Security Services 162 RRP provides only basic password-based registrar authentication 163 services. Additional security services, including privacy and 164 registrar authentication using public key cryptography, are provided 165 through other means. 167 2.1 Connection Security 169 Each RRP session MUST be encrypted using the Secure Socket Layer (SSL) 170 v3.0 protocol as specified in [SSL]. SSL provides privacy services 171 that reduce the risk of inadvertent disclosure of registrar-sensitive 172 information, such as the registrar's user identifier and password. 174 SSL supports mutual authentication of the client and server. The 175 client and server SHOULD both be authenticated using SSL when 176 establishing an RRP session. Further, a registrar MUST be 177 authenticated when establishing an RRP connection via the RRP SESSION 178 command by providing a registrar user identifier and password known 179 only to the registrar and the System. 181 The SSL protocol is not an IETF Standards Track protocol. The 182 Transport Layer Security protocol, specified in [TLS], is a Standards 183 Track protocol that provides SSL v3.0 compatibility features. 185 2.2 System Data Security 187 The System stores information about the registered domain names and 188 their name servers. Only the current registrar of a registered domain 189 name is authorized to query it, update its name servers, and cancel or 190 renew it. Any registrar can initiate a transfer of a domain name and 191 its associated name servers from another registrar. 193 Only a name server's registrar can query, update, and delete it. In 194 general, name servers must be registered through the current registrar 195 of the name server's parent domain name, though an implementation MAY 196 allow use of name servers registered in other TLDs without specifying 197 IP addresses or requiring parent domain registration. Use of ccTLD 198 name servers for a gTLD domain name is one such example. 200 Name servers are implicitly transferred by the System when their 201 parent domain name is transferred. In addition, a name server cannot 202 be deleted if it is hosting domain names. 204 3. Connection Model 206 IANA has assigned TCP port 648 for RRP use. All RRP implementations 207 MUST provide RRP services over SSL on TCP port 648. 209 4. Protocol Description 211 A typical RRP session will go through a number of states during its 212 lifetime. Figure 1 illustrates the possible states of an RRP server. 213 | 214 | 215 v 216 +-----------------+ Timeout 217 | Waiting for |-------------------+ 218 Authentication Succeeded | Client | | 219 +---------| Authentication | Authentication | 220 | | (PRE) |-----+ Failed | 221 | +-----------------+ | | 222 | | | 223 V V | 224 +-----------+ Succeeded +--------------------+ | 225 |Waiting for|<-----------------| Waiting for | | 226 | Command |----------+ |Authentication Retry| | 227 | (WFC) | Timeout | | (WFR) | | 228 +-----------+ | +--------------------+ | 229 | ^ | | | | 230 | | | Timeout | | Failed | 231 Request V |Response | | | | 232 +-----------+ | V V V 233 | Executing | | +--------------------+ 234 | Command | +--------->| Disconnected | 235 | (EXE) |-------------------->| (DIS) | 236 +-----------+ QUIT +--------------------+ 238 Figure 1: RRP Server Finite State Machine 240 Initially, the server waits for a client connection and authentication 241 (PRE). All client connections MUST be authenticated. If the 242 authentication fails, the server gives the client another chance to 243 identify itself (WFR). If the authentication fails again, the server 244 disconnects (DIS). Otherwise, the server waits for a request from the 245 client (WFC). Upon receiving a request, the server executes it and 246 responds to the client with the result (EXE). The server then waits 247 again for another request from the client (WFC). If the client sends a 248 QUIT command, the server ends the session and disconnects (DIS). To 249 keep its state in sync with that of the server, the client SHOULD wait 250 for a response from the server before sending another request on the 251 same connection. The following table summarizes these states: 253 PRE Waiting for client connection and authentication 254 WFR Waiting for authentication retry 255 WFC Waiting for a command from an authenticated client 256 EXE Executing a command 257 DIS Disconnected 259 The WFR and WFC states MAY time out. An implementation SHOULD define 260 inactivity timeout periods for these states based on System-specific 261 factors, including (but not limited to) resource availability and 262 security risk. In the absence of other factors, a default timeout 263 period of 10 minutes SHOULD be used. The server MAY disconnect if the 264 server is in one of these states and no message is received from the 265 client during the timeout period. 267 4.1 Request Format 269 An RRP request nominally consists of a command name, an entity block, 270 command options, and an end-of-command delimiter. Command options and 271 entity blocks collectively define command parameters and their 272 specification is order independent; examples provided in this document 273 specify entity blocks before command options. 275 CommandName [EntityBlock] [CommandOptions] EndOfCommand 277 A command name specifies the type of an RRP request. A command is a 278 word or abbreviation terminated by a carriage-return linefeed (crlf) 279 sequence. 281 CommandName 283 An entity block specifies the data in an RRP request. It consists of 284 attribute name-value pairs specifying the entity and all of the 285 attributes of the entity. Each attribute name-value pair starts with 286 the attribute name, followed by a colon, the attribute value, and is 287 finally terminated by a carriage-return linefeed sequence. Entity 288 blocks are optional for some requests. 290 entityName:entityValue 291 attributeName:attributeValue 293 Command options specify control parameters for an RRP request. A 294 command option starts with a dash, followed by the option name, a 295 colon, the option value, and is finally terminated by a carriage- 296 return linefeed sequence. 298 -commandOptionName:commandOptionValue 300 An EndOfCommand delimiter specifies the end of an RRP request. It 301 consists of a dot (".") in column one followed by a carriage-return 302 linefeed sequence. 304 . 306 4.2 Response Format 308 An RRP response starts with a three-digit response code, followed by a 309 space, an ASCII text description of the response, a carriage-return 310 linefeed sequence, and zero or more attribute name-value pair lines. 311 An RRP response is terminated by a dot in column one followed by a 312 carriage-return linefeed sequence. 314 ResponseCoderesponseDescription 315 [attributeName:attributeValue] 316 . 318 4.3 Protocol Commands 320 Implementations of RRP commands MUST provide "all or nothing" success 321 and failure operation. Failed command execution MUST leave the System 322 in the same state it was in before the command was attempted and 323 failed. 325 All RRP commands include features to provide idempotency. Command 326 features that are not idempotent are explained fully as needed as part 327 of the appropriate command description. 329 4.3.1 ADD 331 This command allows a registrar to register a domain name or a name 332 server in the System. 334 4.3.1.1 Registering a Domain Name 335 The request to register a domain name MUST contain the following data: 337 - The "EntityName" parameter set to value "Domain". 338 - Fully qualified second level domain name in the "DomainName" parameter. 340 The request to register a domain name MAY contain 1 or more, and a 341 maximum of 13, fully qualified name servers hosting the domain name in 342 multiple instances of the "NameServer" parameter. The name servers 343 MUST have already been registered in the registry. Implementations MAY 344 allow specification of name servers associated with domains registered 345 in other TLDs. For example, an implementation MAY allow use of ccTLD 346 name servers for gTLD domain name registration. 348 The request to register a domain name MAY contain the initial 349 registration period in years for the domain being registered in a 350 single instance of the "Period" parameter. The System MUST provide a 351 default initial registration period in years if the "Period" parameter 352 is not provided. The acceptable year values for the "Period" parameter 353 are implementation specific. 355 The System will register the domain name to the registrar for the 356 period specified by the registrar. If the registrar does not specify a 357 registration period, a System-specified default value MUST be used for 358 the initial registration period. If the domain name is successfully 359 registered, the System MUST return the registration expiration date in 360 the "RegistrationExpirationDate" attribute in the response. 362 Authorized User: All registrars MAY use the ADD command to register 363 domain names. 365 Examples 367 A registrar registers a domain name without specifying name servers: 369 C:add 370 C:EntityName:Domain 371 C:DomainName:example.com 372 C:-Period:10 373 C:. 374 S:200 Command completed successfully 375 S:RegistrationExpirationDate:2009-09-22 10:27:00.000 376 S:status:ACTIVE 377 S:. 379 A registrar registers a domain name using previously-registered name servers: 381 C:add 382 C:EntityName:Domain 383 C:DomainName:example2.com 384 C:-Period:10 385 C:NameServer:ns1.example.com 386 C:NameServer:ns2.example.com 387 C:. 388 S:200 Command completed successfully 389 S:RegistrationExpirationDate:2000-09-22 10:27:00.000 390 S:status:ACTIVE 391 S:. 393 4.3.1.2 Registering a Name Server 395 The request to register a name server MUST contain the following data: 397 - The "EntityName" parameter set to value "NameServer". 398 - Fully qualified server name of the name server in the "NameServer" 399 parameter. 401 If the name server being registered is the child of a registered 402 domain name, the name server registration request MUST include one or 403 more, and a maximum of 13, name server IP addresses in multiple 404 instances of the "IPAddress" parameter. Name servers associated with 405 domains registered in other TLDs SHOULD NOT be specified with IP 406 addresses to reduce the possibility of duplicating DNS NS records for 407 the name servers in multiple zone files. 409 The registrar MUST register the name server in the System before using 410 it to host domain names. Further, the name server MUST be registered 411 through the same registrar that is the current registrar of its parent 412 domain name. The System MAY allow any registrar to use the name server 413 to host domain names. 415 Authorized User: All registrars MAY use the ADD command to register 416 name servers. 418 Examples 420 A registrar registers a new name server in an existing domain name: 422 C:add 423 C:EntityName:NameServer 424 C:NameServer:ns1.example.com 425 C:IPAddress:198.41.1.11 426 C:. 427 S:200 Command completed successfully 428 S:. 430 4.3.2 CHECK 431 This command allows a registrar to determine if a domain name or name 432 server has been registered in the System. 434 4.3.2.1 Domain Name Check 436 The request to determine if a domain name is registered MUST contain 437 the following data: 439 - The "EntityName" parameter set to value "Domain". 440 - Fully qualified second level domain name in the "DomainName" parameter. 442 The System MUST provide a positive or negative response to document 443 domain name availability at the moment the command is executed. 445 Authorized User: All registrars MAY use the CHECK command to determine 446 if a domain name has been registered or not. 448 Examples 450 A registrar checks the availability of a domain name in the System: 452 C:check 453 C:EntityName:Domain 454 C:DomainName:example.com 455 C:. 456 S:211 Domain not available 457 S:. 459 4.3.2.2 Name Server Check 461 The request to determine if a name server is registered MUST contain 462 the following data: 464 - The "EntityName" parameter set to value "NameServer". 465 - Fully qualified server name in the "NameServer" parameter. 467 The System MUST provide a positive or negative response to document 468 name server availability at the moment the command is executed. If the 469 name server has been registered, the System MUST return the IP 470 address(es) of the name server. 472 Authorized User: All registrars MAY use the CHECK command to determine 473 if a name server has been registered or not. 475 Examples 477 A registrar checks the availability of a server name in the System: 479 C:check 480 C:EntityName:Nameserver 481 C:Nameserver:ns1.example.com 482 C:. 483 S:213 Nameserver name not available 484 S:ipAddress:192.10.10.10 485 S:. 487 4.3.3 DEL 489 This command allows a registrar to delete (cancel the registration) of 490 a domain name or delete a name server. 492 4.3.3.1 Deleting a Domain Name 494 The request to cancel the registration of a domain name MUST contain 495 the following data: 497 - The "EntityName" parameter set to value "Domain". 498 - Fully qualified second level domain name in the "DomainName" parameter. 500 A request to delete a domain name SHOULD cause the deletion of all 501 name servers that are children of the domain name being deleted. The 502 name servers SHOULD be deleted if they are not actively hosting other 503 domains. A domain MUST not be deleted if it has child name servers 504 hosting other domains. 506 Authorized User: The current registrar of a domain name MAY use the 507 DEL command to delete a domain name from the System. 509 Examples 511 A registrar deletes a domain name, implicitly deleting all name servers 512 registered in the domain: 514 C:del 515 C:EntityName:Domain 516 C:DomainName:example.com 517 C:. 518 S:200 Command completed successfully 519 S:. 521 4.3.3.2 Deleting a Name Server 523 The request to delete a name server MUST contain the following data: 525 - The "EntityName" parameter set to value "NameServer". 526 - Fully qualified name of the name server in the "NameServer" parameter. 528 A name server MUST not be deleted if it is hosting domains. Deleting 529 such domains or name servers is prohibited because their deletion WILL 530 result in orphaning the hosted domains. 532 Authorized User: The current registrar of a name server MAY use the 533 DEL command to delete a name server from the System. 535 Examples 537 A registrar deletes a name server that is not hosting domains: 539 C:del 540 C:EntityName:NameServer 541 C:NameServer:ns1.registrarA.com 542 C:. 543 S:200 Command completed successfully 544 S:. 546 A registrar tries to delete a name server that is hosting domains: 548 C:del 549 C:EntityName:NameServer 550 C:NameServer:ns1.registrarA.com 551 C:. 552 S:532 Domain names linked with name server 553 S:. 555 4.3.4 DESCRIBE 557 This command allows a registrar to obtain general information about an 558 RRP implementation. The command MAY contain the following parameters: 560 - The "Target" parameter set to value "Protocol". 562 The implementation MUST return the protocol version number whether or 563 not the request contains the "Target" parameter. 565 Authorized User: All registrars MAY use the DESCRIBE command. 567 Examples 569 A registrar obtains general information about an RRP implementation: 571 C:describe 572 C:-Target:Protocol 573 C:. 574 S:200 Command completed successfully 575 S:Protocol:RRP 1.1.0 576 S:. 578 4.3.5 MOD 580 This command allows a registrar to update a registered domain name or 581 a name server. The command allows the following operations on an 582 attribute value for both single-valued and multi-valued attributes: 584 - Add an attribute value. The value to be added MUST be unique among the 585 values of the attribute. For a single-valued attribute, it replaces the 586 current value. 587 - Remove an attribute value. The value to be removed MUST exist. Further, 588 an attribute value cannot be removed if it is the only value of a required 589 attribute. 591 Attribute values to be removed are identified by tagging with an "=" 592 suffix. 594 4.3.5.1 Domain Modification 596 The request to modify a registered domain name MUST contain the 597 following data: 599 - The "EntityName" parameter set to value "Domain". 600 - Fully qualified second level domain name in the "DomainName" parameter. 602 The registrar can perform the following update operations on the 603 domain name: 605 - Update the name servers of the domain name by setting one or more instances 606 of the "NameServer" parameter. 607 - Update the status of the domain name by setting one or more instances of 608 the "Status" parameter. Valid values for the "Status" parameter are defined 609 in Section 6. 611 Authorized User: The current registrar of a domain name MAY use the 612 MOD command to modify the attributes of a domain name. 614 Examples 616 A registrar removes one name server (ns1) from a domain and adds a new name 617 server (ns3) to the same domain: 619 C:mod 620 C:EntityName:Domain 621 C:DomainName:example.com 622 C:NameServer:ns3.registrarA.com 623 C:NameServer:ns1.registrarA.com= 624 C:. 625 S:200 Command completed successfully 626 S:. 628 4.3.5.2 Name Server Modification 630 The request to update a name server MUST contain the following data: 631 - The "EntityName" parameter set to value "NameServer". 632 - Fully qualified server name of the name server in the "NameServer" 633 parameter. 635 The registrar can perform the following update operations on the name 636 server: 637 - Update the "NameServer" attribute of the name server. This allows a 638 registrar to change the name of a name server while preserving all existing 639 associations. 640 - Update the IP addresses of the name server by setting one or more instances 641 of the "IPAddress" parameter. 643 Authorized User: The current registrar of a name server MAY use the 644 MOD command to modify the attributes of a domain name. 646 Examples 648 A registrar changes the name and IP address of a name server: 650 C:mod 651 C:EntityName:NameServer 652 C:NameServer:ns1.registrarA.com 653 C:NewNameServer:ns2.registrarA.com 654 C:IPAddress:198.42.1.11 655 C:IPAddress:198.41.1.11= 656 C:. 657 S:200 Command completed successfully 658 S:. 660 4.3.6 QUIT 662 This command allows a registrar to close an RRP connection. A response 663 MUST be sent before closing the connection. 665 Authorized User: All registrars MAY use the QUIT command. 667 Examples 669 A registrar ends an RRP session and closes an existing connection: 671 C:quit 672 C:. 673 S:220 Command completed successfully. Server closing connection 674 S:. 676 4.3.7 RENEW 678 This command allows a registrar to renew a domain name in the System. 679 The request to renew a domain name MUST contain the following data: 681 - The "EntityName" parameter set to value "Domain". 682 - Fully qualified second level domain name in the "DomainName" parameter. 684 The request to renew a domain name MAY contain the renewal period in 685 years for the domain being renewed in a single instance of a "Period" 686 parameter and a single instance of a "CurrentExpirationYear" 687 parameter. These parameters MUST appear together if either is 688 specified, though the order in which the parameters appear is 689 insignificant. The "Period" parameter identifies the number of years 690 to be added to the registration. The "CurrentExpirationYear" parameter 691 identifies the current expiration year, and is required to ensure that 692 repeated attempts to retry this command do not result in multiple 693 successful renewals. The System MUST provide a default number of 694 renewal years if the "Period" and "CurrentExpirationYear" parameters 695 are not provided. Repeated use of this command without the "Period" 696 and "CurrentExpirationYear" parameters may result in repeated 697 successful renewals since idempotency is not provided when these 698 parameters are not used. The acceptable year values for the "Period" 699 parameter are implementation specific subject to syntax restrictions. 701 The System renews the domain name for a period specified by the 702 registrar. If the domain name renewal is completed successfully, the 703 System MUST return the new registration expiration date in the 704 "RegistrationExpirationDate" attribute in the response. 706 Authorized User: The current registrar of a domain name MAY use the 707 RENEW command. 709 Examples 711 A registrar renews a domain name using a specified renewal period: 713 C:renew 714 C:EntityName:Domain 715 C:DomainName:example.com 716 C:-Period:9 717 C:-CurrentExpirationYear:2001 718 C:. 719 S:200 Command completed successfully 720 S:RegistrationExpirationDate:2010-09-22 10:27:00.000 721 S:. 723 4.3.8 SESSION 725 This command allows a registrar to establish an RRP session. A 726 registrar can also use this command to change their password. The 727 request to establish an RRP connection MUST contain the following 728 command parameters: 730 - The "Id" parameter set to the registrar's System user ID. 731 - The "Password" parameter set to the registrar's current System password. 733 The request to establish an RRP session MAY contain a new password for 734 the registrar in a single instance of the "NewPassword" parameter. 736 The registrar MUST send this command to the System before any other 737 command. If the command fails due to invalid information (such as an 738 invalid registrar ID or password), the registrar can resend this 739 request with corrected information. If the command fails a second 740 time, the System SHOULD close the connection. 742 Authorized User: All registrars MAY use the SESSION command. 744 Examples 746 A registrar establishes an RRP session: 748 C:session 749 C:-Id:registrarA 750 C:-Password:i-am-registrarA 751 C:. 752 S:200 Command completed successfully 753 S:. 755 4.3.9 STATUS 757 This command allows a registrar to determine the current status of a 758 domain name or name server. 760 4.3.9.1 Domain Status 762 The request to query a domain name MUST contain the following data: 764 - The "EntityName" parameter set to value "Domain". 765 - Fully qualified second level domain name in the "DomainName" parameter. 767 The response from the System MAY contain the following data: 769 - Fully qualified second level domain name in the "DomainName" attribute. 770 - Fully qualified server names of name servers hosting the domain name in 771 multiple instances of the "NameServer" attribute. 772 - Registration expiration date in the "RegistrationExpirationDate" 773 attribute. 774 - ID of the current registrar of the domain name in the "Registrar" 775 attribute. 776 - Date the domain name was transferred by the current registrar in the 777 "RegistrarTransferDate" attribute. 778 - Current statuses of the domain name in multiple instances of the 779 "Status" attribute. 780 - Date the domain name was originally registered in the "CreatedDate" 781 attribute. 782 - ID of the registrar that originally registered the domain name in the 783 "CreatedBy" attribute. 784 - Date the domain name was last updated in the "UpdatedDate" attribute. 785 - ID of the entity (either a registrar or the registry) that last updated 786 the domain name in the "UpdatedBy" attribute. 788 Authorized User: The current registrar of a domain name MAY use the 789 STATUS command to view current domain name attributes. 791 Examples 793 The current registrar of a domain name queries the domain name: 795 C:status 796 C:EntityName:Domain 797 C:DomainName:example.com 798 C:. 799 S:200 Command completed successfully 800 S:DomainName:example.com 801 S:NameServer:ns2.registrarA.com 802 S:NameServer:ns3.registrarA.com 803 S:RegistrationExpirationDate:2010-09-22 10:27:00.000 804 S:Registrar:registrarA 805 S:RegistrarTransferDate:1998-09-22 10:27:00.000 806 S:Status:ACTIVE 807 S:CreatedDate:1998-09-22 10:27:00.000 808 S:CreatedBy:registrarA 809 S:UpdatedDate:2002-09-22 10:27:00.000 810 S:UpdatedBy:registrarA 811 S:. 813 A registrar queries a domain name currently registered by another registrar: 815 C:status 816 C:EntityName:Domain 817 C:DomainName:example.com 818 C:. 819 S:531 Authorization failed 820 S:. 822 4.3.9.2 Name Server Status 824 The request to query a name server MUST contain the following data: 826 - The "EntityName" parameter set to value "NameServer". 827 - Fully qualified name of the name server in the "NameServer" parameter. 829 The response from the System MAY contain the following data: 831 - Fully qualified name of the name server in the "NameServer" attribute. 832 - IP addresses of the name server in multiple instances of the 833 "IPAddress" attribute. 834 - ID of the current registrar of the name server in the "Registrar" 835 attribute. 836 - Date the name server was transferred by the current registrar in the 837 "RegistrarTransferDate" attribute. 838 - Date the name server was registered in the "CreatedDate" attribute. 839 - ID of the entity that registered the name server in the "CreatedBy" 840 attribute. 841 - Date the name server was last updated in the "UpdatedDate" attribute. 842 - ID of the entity that last updated the name server in the "UpdatedBy" 843 attribute. 845 Authorized User: The current registrar of a name server MAY use the 846 STATUS command to view current domain name attributes. 848 Examples 850 The current registrar of a name server queries the name server: 852 C:status 853 C:EntityName:NameServer 854 C:NameServer:ns1.registrarA.com 855 C:. 856 S:200 Command completed successfully 857 S:NameServer:ns1.registrarA.com 858 S:IPAddress:198.42.1.11 859 S:Registrar:registrarA 860 S:RegistrarTransferDate:1998-09-22 10:27:00.000 861 S:CreatedDate:1998-09-22 10:27:00.000 862 S:CreatedBy:registrarA 863 S:UpdatedDate:2002-09-22 10:27:00.000 864 S:UpdatedBy:registrarA 865 S:. 867 A registrar queries a name server that was registered by another registrar: 869 C:status 870 C:EntityName:NameServer 871 C:NameServer:ns1.registrarA.com 872 C:. 873 S:531 Authorization failed 874 S:. 876 4.3.10 TRANSFER 878 This command allows a registrar to transfer a domain name from another 879 registrar to itself and to approve or reject transfer requests 880 initiated by other registrars. The request to transfer a domain name 881 MUST contain the following data: 883 - The "EntityName" parameter set to value "Domain". 884 - Fully qualified second level domain name in the "DomainName" parameter. 886 The System must notify the potential losing registrar when a domain 887 transfer request has been received. The losing registrar SHOULD then 888 explicitly approve or reject the transfer. A request to approve or 889 reject a transfer request MUST contain a single instance of the 890 "Approve" parameter with a value of "Yes" to approve the transfer or a 891 value of "No" to reject the transfer. An implementation MAY provide a 892 default approval or rejection action to be taken if the losing 893 registrar does not explicitly approve or reject the transfer request. 894 The criteria used by registrars to approve or deny requested transfers 895 are typically based on business policies that are beyond the scope of 896 this document. 898 Name servers MUST be implicitly transferred when their parent domain 899 name is transferred. 901 Authorized User: All registrars MAY use the TRANSFER command. 903 Examples 905 A registrar requests transfer of a domain name from another registrar: 907 C:transfer 908 C:EntityName:Domain 909 C:DomainName:example.com 910 C:. 911 S:200 Command completed successfully 912 S:. 913 The original registrar approves the transfer request: 915 C:transfer 916 C:-Approve:Yes 917 C:EntityName:Domain 918 C:DomainName:example.com 919 C:. 920 S:200 Command completed successfully 921 S:. 923 5. Response Codes 925 RRP commands may return a variety of response codes to signify normal 926 completion or error conditions. This section documents all of the 927 defined RRP response codes. 929 5.1 Response Code Summary 931 200 Command completed successfully 932 This is the normal response for successful completion of most RRP 933 commands. 935 210 Domain name available 936 This is the normal response for successful completion of an RRP CHECK 937 command for a domain name that is not currently registered. 939 211 Domain name not available 940 This is the normal response for successful completion of an RRP CHECK 941 command for a domain name that is currently registered. 943 212 Nameserver name available 944 This is the normal response for successful completion of an RRP CHECK 945 command for a name server that is not currently registered. 947 213 Nameserver name not available 948 This is the normal response for successful completion of an RRP CHECK 949 command for a name server that is currently registered. 951 220 Command completed successfully. Server closing connection 952 This is the normal response for successful completion of an RRP QUIT 953 command. It may also be returned by other RRP commands if a transient 954 situation is noted that requires closing the connection after 955 successfully completing the RRP command. 957 420 Command failed due to server error. Server closing connection 958 A transient server error has caused RRP command failure and session 959 termination. A new session must be established before continued 960 processing can be attempted. 962 421 Command failed due to server error. Client should try again 963 A transient server error has caused RRP command failure. A subsequent 964 retry may produce successful results. 966 500 Invalid command name 967 A client-specified RRP command name was not recognized as a valid RRP 968 command name. 970 501 Invalid command option 971 A client-specified RRP command parameter was not recognized as a valid 972 RRP command parameter. 974 502 Invalid entity value 975 The "value" of an entity name-value pair is invalid. Command blocks 976 that require an "EntityName" parameter also require a value that 977 specifies the entity name, and the provided value is invalid. 979 503 Invalid attribute name 980 A client-specified RRP command parameter was not recognized as a valid 981 RRP command parameter. 983 504 Missing required attribute 984 A parameter required to execute the RRP command was not provided by 985 the client. The command should be retried with all required parameters 986 specified. 988 505 Invalid attribute value syntax 989 A supplied parameter value is syntactically incorrect. For example, a 990 year value digit such as "5" may be required but the client provided a 991 string of characters such as "five". 993 506 Invalid option value 994 A client-specified value for an RRP command parameter is out-of-bounds 995 or otherwise not within acceptable System limits. 997 507 Invalid command format 998 The specified command does not resemble a well-formed RRP command. The 999 command should be retried using the proper command structure and 1000 syntax. 1002 508 Missing required entity 1003 An entity required for command completion was not provided by the 1004 client. For example, the CHECK command requires specification of 1005 either a "Domain" entity or a "Nameserver" entity. 1007 509 Missing command option 1008 A command parameter that isn't really optional (such as the registrar 1009 ID in a SESSION command) was not provided by the client. The command 1010 should be retried with all needed parameters. 1012 520 Server closing connection. Client should try opening new connection; 1013 A timeout event has been detected, and the client's session is being 1014 ended. The System SHOULD define timeout periods to begin a client 1015 command, complete a client command, and for the duration of an open 1016 session. The reason for the timeout MUST be provided at the end of the 1017 response code string. 1019 521 Too many sessions open. Server closing connection 1020 A System-defined limit on the number of open connections has been 1021 exceeded, and it is impossible to establish a new session at the 1022 moment. It may be possible to establish a session by waiting for a few 1023 moments or by closing existing unused sessions. 1025 530 Authentication failed 1026 The client-supplied registrar identifier or password was not 1027 recognized by the System. A subsequent retry with valid values may 1028 produce successful results. Repeated authorization failures MAY result 1029 in termination of the TCP connection. 1031 531 Authorization failed 1032 Registrars may not view or alter data associated with either the 1033 registry or another registrar. This response code is typically 1034 returned when a registrar attempts to view or modify data belonging to 1035 either the registry or another registrar. A typical situation includes 1036 doing a STATUS command for a domain registered to another registrar. 1038 532 Domain names linked with name server 1039 The name server is hosting active domains. This error occurs when a 1040 registrar is trying to delete a server that is the name server for 1041 active domains. The registry MUST not allow the registrar to delete 1042 this server. All of the domain names using this server MUST be 1043 modified to use a different name server before the name server can be 1044 deleted. 1046 533 Domain name has active name servers 1047 The domain name has active name servers. The registrar is trying to 1048 delete a domain name that is a parent domain of an active name server, 1049 i.e., a server that is hosting active domains. All of the name servers 1050 within the domain MUST be removed from service before the domain can 1051 be deleted. 1053 534 Domain name has not been flagged for transfer 1054 The registrar is trying to approve or reject a domain name transfer 1055 for a domain name that is not pending transfer. 1057 535 Restricted IP address 1058 IANA identifies certain IP address ranges that are not valid for 1059 normal use. The registrar is trying to use an IP address that is in a 1060 restricted IP address range as identified by IANA. 1062 536 Domain already flagged for transfer 1063 The registrar tried to perform a transfer command for a domain name 1064 that is awaiting approval of an earlier transfer request. 1066 540 Attribute value is not unique 1067 A supplied attribute value is not unique. This occurs when the 1068 registrar is adding a domain name that already exists in the registry, 1069 a server that already exists in the registry, or an IP address that is 1070 already being used by another server in the registry. Another 1071 possibility occurs when performing domain modifications and the 1072 registrar is adding a server that is already in the list of servers 1073 for the domain name or setting a domain name to a status to which it 1074 is already set. The RRP STATUS command MAY be used to determine 1075 current domain name status before attempting to change the status. 1076 When modifying or adding a name server, the IP address of the name 1077 server might not be unique. The registry MUST not allow IP addresses 1078 to be used by more than one server. 1080 541 Invalid attribute value 1081 A supplied parameter value is invalid. Examples of invalid attribute 1082 values include an invalid IP address, an invalid domain name, an 1083 invalid server name, or an invalid renewal period. 1085 542 Invalid old value for an attribute 1086 A current attribute value to be modified is invalid. The registrar is 1087 trying to modify an attribute of a server or a domain name that does 1088 not exist in the registry. 1090 543 Final or implicit attribute cannot be updated 1091 The registrar is attempting to modify an attribute that is only 1092 modifiable by the registry. Registrars can not modify final or 1093 implicit attribute values. 1095 544 Entity on hold 1096 The attempted operation was rejected because the entity is on HOLD 1097 status. If the HOLD status was set by the registrar, the status can be 1098 changed using the MOD command and the requested command can be 1099 retried. If the HOLD status was set by the registry, the registrar 1100 must contact the registry to change the status before the command can 1101 be successful. 1103 545 Entity reference not found 1104 A required entity reference was not found. This occurs when the 1105 registrar tries to add a new name server and the parent domain of the 1106 name server does not exist in the registry. It also occurs when the 1107 user is trying to add a new name server to a domain name when the name 1108 server does not exist in the registry. 1110 546 Credit limit exceeded 1111 The registrar's credit limit has been exceeded. This is an 1112 implementation specific error that occurs when a potentially billable 1113 operation, such as adding a domain name, renewing a domain name, or 1114 transferring a domain name, is attempted and the registrar does not 1115 have sufficient financial standing with the registry to complete the 1116 operation. 1118 547 Invalid command sequence 1119 RRP commands are issued using a well-formed syntax that requires entry 1120 of command structures in particular sequences. This response code 1121 indicates that an ill-formed command was received and rejected. 1123 548 Domain is not up for renewal 1124 A RENEW command was attempted during a period in which the domain can 1125 not be renewed. Implementations MAY limit renewal periods to 1126 particular time frames, such as within 90 days of the domain's 1127 expiration. This response indicates that the RENEW command was 1128 received outside of the System-defined domain renewal period. 1130 549 Command failed 1131 A System error prevented successful completion of the requested RRP 1132 command. Retrying the command might produce success, but a repeated 1133 failure indicates a System error condition. 1135 550 Parent domain not registered 1136 The parent domain of a name server being registered is not registered. 1137 This occurs when the registrar tries to add a new name server and the 1138 parent domain for the server does not exist in the registry. 1140 551 Parent domain status does not allow for operation 1141 The status of the parent domain does not allow the requested 1142 operation. This occurs when a registrar tries to modify a server whose 1143 parent domain is flagged as LOCK or HOLD in the registry. 1145 552 Domain status does not allow for operation 1146 The status of the domain does not allow the requested operation. This 1147 occurs when a registrar tries to modify or delete a domain that is 1148 flagged as LOCK or HOLD in the registry. 1150 553 Operation not allowed. Domain pending transfer 1151 The status of the domain does not allow the requested operation. The 1152 registrar is attempting to delete a domain that is pending approval or 1153 denial of a transfer request. 1155 554 Domain already registered 1156 A registrar tried to register a domain name that has already been 1157 registered by the same registrar. 1159 555 Domain already renewed 1160 A registrar tried to renew a domain using the same parameters as 1161 specified for an earlier, successful renewal. This will commonly occur 1162 when executing the same RENEW command more than once. 1164 556: Maximum registration period exceeded 1165 A registrar tried to renew a domain registration without specifying a 1166 renewal period (the System default was used), and the resulting new 1167 registration period exceeds the System-defined maximum registration 1168 period. If there is renewal time available with the System-defined 1169 maximum registration period it may be possible to retry the RENEW 1170 command with specified renewal period parameters. 1172 5.2 Command-Response Correspondence 1174 The session between the client and the server is intended to be an 1175 alternating dialogue. Each command issued by a client MUST be acted 1176 upon by the server, which MUST return a response code to document the 1177 success or failure of command execution. "Success" means that the 1178 command completed normal execution without error. "Failure" means 1179 that the System did not complete the command as requested. Failure may 1180 be due to either syntax, semantic, data, or System errors. 1182 A complete list of response codes for each RRP command is listed 1183 below. 1185 Command: ADD 1186 Success: 200, 220 1187 Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 531, 535, 540, 1188 541, 545, 546, 547, 549, 550, 554 1190 Command: CHECK 1191 Success: 210, 211, 212, 213 1192 Failure: 220, 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 541, 547, 1193 549 1195 Command: DEL 1196 Success: 200, 220 1197 Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 531, 532, 533, 1198 541, 544, 545, 547, 549, 551, 552, 553 1200 Command: DESCRIBE 1201 Success: 200, 220 1202 Failure: 420, 421, 500, 501, 506, 507, 509, 520, 547, 549 1203 Command: MOD 1204 Success: 200, 220 1205 Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 531, 535, 540, 1206 541, 542, 543, 544, 545, 547, 549, 550, 551, 552, 553 1208 Command: QUIT 1209 Success: 220 1210 Failure: 420, 421, 500, 507, 520, 547, 549 1212 Command: RENEW 1213 Success: 200, 220 1214 Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 531, 541, 545, 1215 546, 547, 548, 549, 552, 553, 555, 556 1217 Command: SESSION 1218 Success: 200, 220 1219 Failure: 420, 421, 500, 501, 506, 507, 508, 509, 520, 521, 530, 531, 547, 1220 549 1222 Command: STATUS 1223 Success: 200, 220 1224 Failure: 420, 421, 500, 501, 502, 503, 504, 505, 506, 507, 508, 520, 531, 1225 541, 545, 547, 549 1227 Command: TRANSFER 1228 Success: 200, 220 1229 Failure: 420, 421, 500, 501, 502, 503, 504, 505, 506, 507, 508, 520, 531, 1230 534, 536, 541, 544, 545, 546, 547, 549, 552, 553 1232 6. Domain Status Codes 1234 The status of a domain can be viewed using the RRP STATUS command and 1235 modified using the RRP MOD command. Both the registry and the 1236 sponsoring registrar MAY view and change the status of a domain. The 1237 criteria for status changes are highly dependent on registry and 1238 registrar business models and are thus beyond the scope of this 1239 specification. 1241 The domain's status SHOULD have a direct bearing on whether or not the 1242 domain appears in the appropriate TLD zone file and whether or not the 1243 domain can be modified. A domain can have more than one assigned 1244 status, e.g., REGISTRAR-HOLD and REGISTRAR-LOCK. If a domain is in 1245 ACTIVE status, then the domain name can only be in this status. When 1246 a registrar sets a domain name to REGISTRAR-LOCK, the registry MUST 1247 automatically remove the ACTIVE status. When the registrar removes the 1248 REGISTRAR-LOCK and other domain statuses, the registry MUST 1249 automatically set the domain name status to ACTIVE. 1251 6.1 Domain Status Code Description 1253 ACTIVE: This is the default status of a domain at registration time. 1254 The registry sets the domain to this status. The domain is modifiable 1255 by the registrar. The domain can be renewed. The domain SHALL be 1256 included in the zone file when in this status if the domain has at 1257 least one associated name server. 1259 REGISTRY-LOCK: The registry sets the domain to this status. The domain 1260 cannot be modified or deleted by the registrar. The registry MUST 1261 remove the REGISTRY-LOCK status for the registrar to modify the 1262 domain. The domain can be renewed. The domain SHALL be included in the 1263 zone file when in this status if the domain has at least one 1264 associated name server. 1266 REGISTRY-HOLD: The registry sets the domain to this status. The domain 1267 cannot be modified or deleted by the registrar. The registry MUST 1268 remove the REGISTRY-HOLD status for the registrar to modify the 1269 domain. The domain can be renewed. The domain SHALL NOT be included in 1270 the zone file when in this status. 1272 REGISTRAR-HOLD: The registrar of the domain sets the domain to this 1273 status. The domain can not be modified or deleted when in this status. 1274 The registrar MUST remove REGISTRAR-HOLD status to modify the domain. 1275 The domain can be renewed. The domain SHALL NOT be included in the 1276 zone file when in this status. 1278 REGISTRAR-LOCK: The registrar of the domain sets the domain to this 1279 status. The domain cannot be modified or deleted when in this status. 1280 The registrar MUST remove REGISTRAR-LOCK status to modify the domain. 1281 The domain can be renewed. The domain SHALL be included in the zone 1282 file when in this status. 1284 REGISTRY-DELETE-NOTIFY: A domain is set on this status if it has 1285 expired and has child name servers that are hosting other domains. 1286 Only the registry may set this status. The domain SHALL be included in 1287 the zone file when in this status if the domain has at least one 1288 associated name server. 1290 7. Formal Syntax 1292 The following syntax specification uses the augmented Backus-Naur Form 1293 (BNF) as described in [ABNF]. 1295 ; ABNF specification for Registry Registrar Protocol (RRP) v1.1.0 1296 ; Note that character string literals are case insensitive. 1298 ; Lexical tokens 1299 space = %x20 ; " " 1300 dot = %x2E ; "." 1301 dash = %x2D ; "-" 1302 underscore = %x5F ; "_" 1303 colon = %x3A ; ":" 1304 cr = %x0D ; ASCII carriage return 1305 lf = %x0A ; ASCII linefeed 1306 crlf = cr lf 1307 alpha = %x41-5A / %x61-7A ; A-Z / a-z 1308 digit = %x30-39 ; 0-9 1309 dns-char = alpha / digit / dash 1310 id-char = alpha / digit / underscore / dash 1311 id-prefix = alpha / digit 1312 id-word = id-prefix *id-char 1313 printable-char = %x20-7E ; ASCII " " - "~" 1315 ; Start of basic grammar. 1316 year = 4digit 1317 month = 2digit 1318 day = 2digit 1319 ymd = year dash month dash day 1320 hour = 2digit 1321 minute = 2digit 1322 second = 2digit 1323 milli-second = 3digit 1324 hms = hour colon minute colon second dot milli-second 1325 time-stamp = ymd space hms 1326 ip-address = 1*3digit dot 1*3digit dot 1*3digit dot 1*3digit 1327 password = 4*16printable-char 1328 option-name = 1*128id-word 1329 option-tag = dash option-name 1330 option-value = 1*128id-word 1331 attribute-name = 1*128id-word 1332 attribute-value = 1*128printable-char 1333 attribute-line = attribute-name colon attribute-value crlf 1334 response = 3digit space 1*printable-char crlf 1335 version-number = "RRP" space 1*digit dot 1*digit dot 1*digit 1336 label = id-prefix *61dns-char id-prefix 1337 sldn = label dot label 1338 servername = *(label dot) sldn 1339 period = %x31-39 / (%x31-39 %x30-39) ; "1" - "9" or "10" - "99" 1340 period-option = dash "Period" colon period crlf 1341 yesno = "Yes" / "No" 1343 ; RRP commands and responses. 1344 rrp = add / check / delete / describe / mod / quit / renew / 1345 session / status / transfer 1347 add = add-request add-response 1348 check = check-request check-response 1349 delete = del-request del-response 1350 describe = describe-request describe-response 1351 mod = mod-request mod-response 1352 quit = quit-request quit-response 1353 renew = renew-request renew-response 1354 session = session-request session-response 1355 status = status-request status-response 1356 transfer = transfer-request transfer-response 1358 ; ADD command. 1359 add-request = add-domain-request / add-nameserver-request 1360 add-response = add-domain-response / add-nameserver-response 1361 add-domain-request = "add" crlf 1362 "EntityName" colon "Domain" crlf 1363 "DomainName" colon sldn crlf 1364 [period-option] 1365 0*13("NameServer" colon servername crlf) 1366 dot crlf 1367 add-nameserver-request = "add" crlf 1368 "EntityName" colon "NameServer" crlf 1369 "NameServer" colon servername crlf 1370 1*("IPAddress" colon ip-address crlf) 1371 dot crlf 1372 add-domain-response = response 1373 "RegistrationExpirationDate" colon time-stamp crlf 1374 "status" colon 1*digit crlf 1375 dot crlf 1376 add-nameserver-response = response 1377 dot crlf 1379 ; CHECK command. 1380 check-request = check-domain-request / check-nameserver-request 1381 check-response = check-domain-response / check-nameserver-response 1382 check-domain-request = "check" crlf 1383 "EntityName" colon "Domain" crlf 1384 "DomainName" colon sldn crlf 1385 dot crlf 1386 check-nameserver-request = "check" crlf 1387 "EntityName" colon "NameServer" crlf 1388 "NameServer" colon servername crlf 1389 dot crlf 1390 check-domain-response = response 1391 dot crlf 1392 check-nameserver-response = available-check-nameserver-response / 1393 notavailable-check-nameserver-response 1394 available-check-nameserver-response = response 1395 dot crlf 1396 notavailable-check-nameserver-response = response 1*("IPAddress" colon ip-address crlf) 1397 dot crlf 1399 ; DEL command. 1400 del-request = del-domain-request / del-nameserver-request 1401 del-response = response 1402 dot crlf 1403 del-domain-request = "del" crlf 1404 "EntityName" colon "Domain" crlf 1405 "DomainName" colon sldn crlf 1406 dot crlf 1407 del-nameserver-request = "del" crlf 1408 "EntityName" colon "NameServer" crlf 1409 "NameServer" colon servername crlf 1410 dot crlf 1412 ; DESCRIBE command. 1413 describe-request = "describe" crlf 1414 [target-option] 1415 *(option-tag colon option-value crlf) 1416 dot crlf 1417 describe-response = response 1418 "Protocol" colon version-number crlf 1419 *attribute-line 1420 dot crlf 1421 target-option = dash "Target" colon "Protocol" crlf 1423 ; MOD command. 1424 mod-request = mod-domain-request / mod-nameserver-request 1425 mod-response = response 1426 *attribute-line 1427 dot crlf 1428 mod-domain-request = "mod" crlf 1429 "EntityName" colon "Domain" crlf 1430 "DomainName" colon sldn crlf 1431 *(add-attribute-value-line / 1432 remove-attribute-value-line / 1433 replace-attribute-value-line) 1434 dot crlf 1435 mod-nameserver-request = "mod" crlf 1436 "EntityName" colon "NameServer" crlf 1437 "NameServer" colon servername crlf 1438 ["NewNameServer" colon attribute-value crlf] 1439 *(add-attribute-value-line / 1440 remove-attribute-value-line / 1441 replace-attribute-value-line) 1442 dot crlf 1444 add-attribute-value-line = 1445 attribute-name colon new-attribute-value 1446 remove-attribute-value-line = 1447 attribute-name colon old-attribute-value "=" 1448 replace-attribute-value-line = 1449 attribute-name colon old-attribute-value "=" 1450 new-attribute-value 1451 old-attribute-value = attribute-value 1452 new-attribute-value = attribute-value 1454 ; QUIT command. 1455 quit-request = "quit" crlf 1456 dot crlf 1457 quit-response = response 1458 dot crlf 1460 ; RENEW command. 1461 renew-request = "renew" crlf 1462 "EntityName" colon "Domain" crlf 1463 "DomainName" colon sldn crlf 1464 [renew-period-option] 1465 dot crlf 1466 expiration-year-option = dash "CurrentExpirationYear" colon year crlf 1467 renew-period-option = period-option expiration-year-option / 1468 expiration-year-option period-option 1469 renew-response = response 1470 "RegistrationExpirationDate" colon time-stamp crlf 1471 dot crlf 1473 ; SESSION command. 1474 session-request = "session" crlf 1475 registrar-id-option 1476 registrar-password-option 1477 [registrar-newpassword-option] 1478 dot crlf 1479 session-response = response 1480 dot crlf 1481 registrar-id-option = dash "Id" colon option-value crlf 1482 registrar-password-option = 1483 dash "Password" colon password crlf 1484 registrar-newpassword-option = 1485 dash "NewPassword" colon password crlf 1487 ; STATUS command. 1488 status-request = status-domain-request / 1489 status-nameserver-request 1490 status-response = response 1491 *attribute-line 1492 dot crlf 1493 status-domain-request = "status" crlf 1494 "EntityName" colon "Domain" crlf 1495 "DomainName" colon sldn crlf 1496 dot crlf 1497 status-nameserver-request = "status" crlf 1498 "EntityName" colon "NameServer" crlf 1499 "NameServer" colon servername crlf 1500 dot crlf 1502 ; TRANSFER command. 1503 transfer-request = "transfer" crlf 1504 [approve-option] 1505 "EntityName" colon "Domain" crlf 1506 "DomainName" colon sldn crlf 1507 dot crlf 1508 transfer-response = response 1509 "RegistrationExpirationDate" colon time-stamp crlf 1510 dot crlf 1511 approve-option = dash "Approve" colon yesno crlf 1513 ; End of grammar. 1515 8. Internationalization 1517 RRP is defined using 7-bit US-ASCII characters. Other character sets 1518 and character codes are not currently supported. 1520 9. Known Issues 1522 RRP was not designed to provide bulk data query features. The primary 1523 goal of the original protocol designers was to provide a fast, light 1524 weight transactional protocol that could be implemented with minimal 1525 need for database queries that would take a "long" time to complete or 1526 that would return a "large" amount of data. Implementers SHOULD 1527 consider developing offline reporting features to provide bulk data 1528 for registrar reporting in a fashion suitable for the given registry- 1529 registrar operating environment. 1531 This version of RRP does contain a few limitations noted over the 1532 course of several months of operational experience with live domain 1533 name registrars. Later versions of this protocol or its successors 1534 should strive to resolve or address each of the following issues: 1536 The DESCRIBE command should return information describing System- 1537 defined default implementation values. 1539 Use of the RENEW command without the "CurrentExpirationYear" and 1540 "Period" parameters does not provide idempotency. Repeated execution 1541 of a RENEW command without these parameters can result in multiple 1542 successful RENEW commands, which may not be the desired action if a 1543 registrar is retrying a RENEW command due to network connectivity 1544 problems. 1546 Time stamps returned by RRP do not include time zone identifiers and 1547 SHOULD be interpreted as local registry time. 1549 The protocol does not provide features for a registrar to become aware 1550 of domain transfer requests and responses. Systems must rely on means 1551 outside of the protocol, such as electronic mail, to inform registrars 1552 of transfer requests and responses. 1554 The protocol does not provide features for a registrar to determine 1555 all of the domains served by a name server. Systems must provide this 1556 information using a method outside of the protocol, such as through 1557 periodic extracts from a System database. 1559 The protocol does not provide features to manage lame delegation of 1560 name servers. Any registrar may "use" name servers registered by 1561 another registrar. When a registrar tries to delete a domain or name 1562 server it is quite possible that name servers in the domain to be 1563 deleted or the name server to be deleted will be associated with other 1564 live domains, precluding immediate deletion. Systems must rely on 1565 means outside of the protocol to manage lame delegation of name 1566 servers. 1568 The use of "=" within the MOD command to indicate a value to be 1569 removed is somewhat confusing. A more explicit means of identifying 1570 old and new attribute values within the protocol syntax could make 1571 this feature more obvious. 1573 The CHECK command also returns name server IP addresses when returning 1574 positive confirmation of the registration of a name server. This 1575 extra information may be useful, but it is inconsistent with the 1576 limited function of the command. The command should return a positive 1577 or negative response and nothing more. 1579 The formal protocol syntax described in this document requires a 1580 specific order for the elements of a command entity block and command 1581 options. The NSI Registry's server-side implementation of the protocol 1582 provides the additional flexibility of allowing order independent 1583 specification of options and entity block elements. Client-side 1584 implementers are strongly urged to observe the order of command 1585 elements as specified here to ensure compliance if the more restricted 1586 form is enforced in the future. 1588 10. Security Considerations 1590 Misuse of the Registry Registrar Protocol can have catastrophic 1591 operational consequences for registrants, registrars, and registries. 1592 As such, all registrars must be authenticated prior to all 1593 interactions with the registry. In addition, all data exchanged 1594 between the registrar and the registry must be protected to avoid 1595 unintended disclosure of information. 1597 11. IANA Considerations 1599 IANA assigned TCP port 648 for RRP use in November 1998. No other 1600 action is required of IANA to support operation of this protocol. 1602 IANA has reserved certain IPv4 address ranges as described in 1603 [ALLOCATION]. Implementers MUST ensure that name server IP addresses 1604 do not fall into one of the reserved address ranges to avoid 1605 operational DNS errors. 1607 12. References 1609 [ABNF] D. Crocker (Editor) and P. Overell: "Augmented BNF for Syntax 1610 Specifications: ABNF", RFC 2234, November 1997. 1612 [ALLOCATION] K. Hubbard, M. Kosters, D. Conrad, D. Karrenberg, and J. 1613 Postel: "Internet Registry IP Allocation Guidelines", BCP 12, RFC 1614 2050, November 1996. 1616 [MUSTSHOULD] S. Bradner: "Key Words for Use in RFCs to Indicate 1617 Requirement Levels", BCP 14, RFC 2119, March 1997. 1619 [SSL] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol", 1620 Netscape Communications Corp., November 18, 1996. 1622 [TLS] T. Dierks and C. Allen, "The TLS Protocol Version 1.0", RFC 1623 2246, January 1999. 1625 13. Acknowledgments 1627 Many people have contributed significantly to this document and the 1628 protocol it describes. Brad McMillen and Neeran Saraf deserve special 1629 mention as co-authors of an earlier internal protocol specification. 1630 Other content contributors to the earlier internal specification 1631 include Aristotle Balogh, Chris Bason, Mark Kosters, Jasdip Singh, and 1632 Yibing Wu. Finally, significant contributors to the review of this 1633 document include Steve Mahlstedt and Chris Smith. 1635 14. Authors' Address 1636 Scott Hollenbeck Manoj Srivastava 1637 Network Solutions, Inc. Registry Network Solutions, Inc. Registry 1638 505 Huntmar Park Dr. 505 Huntmar Park Dr. 1639 Herndon, VA 20170 Herndon, VA 20170 1640 USA USA 1641 shollenb@netsol.com manojs@netsol.com 1643 15. Full Copyright Statement 1645 Copyright (C) The Internet Society 1999. All Rights Reserved. 1647 This document and translations of it may be copied and furnished to 1648 others, and derivative works that comment on or otherwise explain it 1649 or assist in its implementation may be prepared, copied, published and 1650 distributed, in whole or in part, without restriction of any kind, 1651 provided that the above copyright notice and this paragraph are 1652 included on all such copies and derivative works. However, this 1653 document itself may not be modified in any way, such as by removing 1654 the copyright notice or references to the Internet Society or other 1655 Internet organizations, except as needed for the purpose of developing 1656 Internet standards in which case the procedures for copyrights defined 1657 in the Internet Standards process must be followed, or as required to 1658 translate it into languages other than English. 1660 The limited permissions granted above are perpetual and will not be 1661 revoked by the Internet Society or its successors or assigns. 1663 This document and the information contained herein is provided on an 1664 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1665 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 1666 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 1667 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1668 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.