549 Command failed
A System error prevented successful completion of the requested RRP
command. Retrying the command might produce success, but a repeated
failure indicates a System error condition.
550 Parent domain not registered
The parent domain of a name server being registered is not
registered. This occurs when the registrar tries to add a new name
server and the parent domain for the server does not exist in the
registry.
551 Parent domain status does not allow for operation
The status of the parent domain does not allow the requested
operation. This occurs when a registrar tries to modify a server
whose parent domain is flagged as LOCK or HOLD in the registry.
552 Domain status does not allow for operation
The status of the domain does not allow the requested operation. This
occurs when a registrar tries to modify or delete a domain that is
flagged as LOCK or HOLD in the registry.
553 Operation not allowed. Domain pending transfer
The status of the domain does not allow the requested operation. The
registrar is attempting to delete a domain that is pending approval
or denial of a transfer request.
554 Domain already registered
A registrar tried to register a domain name that has already been
registered by the same registrar.
555 Domain already renewed
A registrar tried to renew a domain using the same parameters as
specified for an earlier, successful renewal. This will commonly
occur when executing the same RENEW command more than once.
556 Maximum registration period exceeded
A registrar tried to renew a domain registration, and the resulting
new registration period exceeds the System-defined maximum
registration period. If there is renewal time available with the
System-defined maximum registration period it may be possible to
retry the RENEW command with specified renewal period parameters.
5.2 Command-Response Correspondence
The session between the client and the server is intended to be an
alternating dialogue. Each command issued by a client MUST be acted
upon by the server, which MUST return a response code to document the
success or failure of command execution. "Success" means that the
command completed normal execution without error. "Failure" means
that the System did not complete the command as requested. Failure
may be due to either syntax, semantic, data, or System errors.
A complete list of response codes for each RRP command is listed
below.
Command: ADD
Success: 200, 220
Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 531, 535,
540, 541, 545, 546, 547, 549, 550, 554
Command: CHECK
Success: 210, 211, 212, 213
Failure: 220, 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 541,
547, 549
Command: DEL
Success: 200, 220
Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 531, 532,
533, 541, 544, 545, 547, 549, 551, 552, 553
Command: DESCRIBE
Success: 200, 220
Failure: 420, 421, 500, 501, 506, 507, 509, 520, 547, 549
Command: MOD
Success: 200, 220
Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 531, 535,
540, 541, 542, 543, 544, 545, 547, 549, 550, 551, 552, 553
Command: QUIT
Success: 220
Failure: 420, 421, 500, 507, 520, 547, 549
Command: RENEW
Success: 200, 220
Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 531, 541,
545, 546, 547, 548, 549, 552, 553, 555, 556
Command: SESSION
Success: 200, 220
Failure: 420, 421, 500, 501, 506, 507, 508, 509, 520, 521, 530, 531,
547, 549
Command: STATUS
Success: 200, 220
Failure: 420, 421, 500, 501, 502, 503, 504, 505, 506, 507, 508, 520,
531, 541, 545, 547, 549
Command: TRANSFER
Success: 200, 220
Failure: 420, 421, 500, 501, 502, 503, 504, 505, 506, 507, 508, 520,
531, 534, 536, 541, 544, 545, 546, 547, 549, 552, 553
6. Domain Status Codes
The status of a domain can be viewed using the RRP STATUS command and
modified using the RRP MOD command. Both the registry and the
sponsoring registrar MAY view and change the status of a domain. The
criteria for status changes are highly dependent on registry and
registrar business models and are thus beyond the scope of this
specification.
The domain's status SHOULD have a direct bearing on whether or not
the domain appears in the appropriate TLD zone file and whether or
not the domain can be modified. A domain can have more than one
assigned status, e.g., REGISTRAR-HOLD and REGISTRAR-LOCK. If a domain
is in ACTIVE status, then the domain name can only be in this status.
When a registrar sets a domain name to REGISTRAR-LOCK, the registry
MUST automatically remove the ACTIVE status. When the registrar
removes the REGISTRAR-LOCK and other domain statuses, the registry
MUST automatically set the domain name status to ACTIVE.
6.1 Domain Status Code Description
ACTIVE: This is the default status of a domain at registration time.
The registry sets the domain to this status. The domain is modifiable
by the registrar. The domain can be renewed. The domain SHALL be
included in the zone file when in this status if the domain has at
least one associated name server.
REGISTRY-LOCK: The registry sets the domain to this status. The
domain cannot be modified or deleted by the registrar. The registry
MUST remove the REGISTRY-LOCK status for the registrar to modify the
domain. The domain can be renewed. The domain SHALL be included in
the zone file when in this status if the domain has at least one
associated name server.
REGISTRY-HOLD: The registry sets the domain to this status. The
domain cannot be modified or deleted by the registrar. The registry
MUST remove the REGISTRY-HOLD status for the registrar to modify the
domain. The domain can be renewed. The domain SHALL NOT be included
in the zone file when in this status.
REGISTRAR-HOLD: The registrar of the domain sets the domain to this
status. The domain can not be modified or deleted when in this
status. The registrar MUST remove REGISTRAR-HOLD status to modify the
domain. The domain can be renewed. The domain SHALL NOT be included
in the zone file when in this status.
REGISTRAR-LOCK: The registrar of the domain sets the domain to this
status. The domain cannot be modified or deleted when in this status.
The registrar MUST remove REGISTRAR-LOCK status to modify the domain.
The domain can be renewed. The domain SHALL be included in the zone
file when in this status.
REGISTRY-DELETE-NOTIFY: A domain is set on this status if it has
expired and has child name servers that are hosting other domains.
Only the registry may set this status. The domain SHALL be included
in the zone file when in this status if the domain has at least one
associated name server.
7. Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in [ABNF].
; ABNF specification for Registry Registrar Protocol (RRP) v1.1.0
; Note that character string literals are case insensitive.
; Lexical tokens
space = %x20 ; " "
dot = %x2E ; "."
dash = %x2D ; "-"
underscore = %x5F ; "_"
colon = %x3A ; ":"
cr = %x0D ; ASCII carriage return
lf = %x0A ; ASCII linefeed
crlf = cr lf
alpha = %x41-5A / %x61-7A ; A-Z / a-z
digit = %x30-39 ; 0-9
dns-char = alpha / digit / dash
id-char = alpha / digit / underscore / dash
id-prefix = alpha / digit
id-word = id-prefix *id-char
printable-char = %x20-7E ; ASCII " " - "~"
; Start of basic grammar.
year = 4digit
month = 2digit
day = 2digit
ymd = year dash month dash day
hour = 2digit
minute = 2digit
second = 2digit
split-second = 1digit
hms = hour colon minute colon second dot split-second
time-stamp = ymd space hms
ip-address = 1*3digit dot 1*3digit dot 1*3digit dot 1*3digit
password = 4*16printable-char
option-name = 1*128id-word
option-tag = dash option-name
option-value = 1*128id-word
attribute-name = 1*128id-word
attribute-value = 1*128printable-char
attribute-line = attribute-name colon attribute-value crlf
response = 3digit space 1*printable-char crlf
version-number = "RRP" space 1*digit dot 1*digit dot 1*digit
label = id-prefix [*61dns-char id-prefix]
sldn = label dot label
servername = *(label dot) sldn
period = %x31-39 / (%x31-39 %x30-39) ; "1" - "9" or "10" - "99"
period-option = dash "Period" colon period crlf
yesno = "Yes" / "No"
domainstatus = "Active" / "Registry-Lock" / "Registry-Hold" /
"Registrar-Lock" / "Registrar-Hold" /
"Registry-Delete-Notify"
; RRP commands and responses.
rrp = add / check / delete / describe / mod / quit / renew /
session / status / transfer
add = add-request add-response
check = check-request check-response
delete = del-request del-response
describe = describe-request describe-response
mod = mod-request mod-response
quit = quit-request quit-response
renew = renew-request renew-response
session = session-request session-response
status = status-request status-response
transfer = transfer-request transfer-response
; ADD command.
add-request = add-domain-request / add-nameserver-request
add-response = add-domain-response / add-nameserver-response
add-domain-request = "add" crlf
"EntityName" colon "Domain" crlf
"DomainName" colon sldn crlf
[period-option]
0*13("NameServer" colon servername crlf)
dot crlf
add-nameserver-request = "add" crlf
"EntityName" colon "NameServer" crlf
"NameServer" colon servername crlf
1*("IPAddress" colon ip-address crlf)
dot crlf
add-domain-response = response
"RegistrationExpirationDate" colon time-stamp crlf
"status" colon domainstatus crlf
dot crlf
add-nameserver-response = response
dot crlf
; CHECK command.
check-request = check-domain-request / check-nameserver-request
check-response = check-domain-response / check-nameserver-response
check-domain-request = "check" crlf
"EntityName" colon "Domain" crlf
"DomainName" colon sldn crlf
dot crlf
check-nameserver-request = "check" crlf
"EntityName" colon "NameServer" crlf
"NameServer" colon servername crlf
dot crlf
check-domain-response = response
dot crlf
check-nameserver-response = available-check-nameserver-response /
notavailable-check-nameserver-response
available-check-nameserver-response = response
dot crlf
notavailable-check-nameserver-response = response
1*("IPAddress" colon ip-address crlf)
dot crlf
; DEL command.
del-request = del-domain-request / del-nameserver-request
del-response = response
dot crlf
del-domain-request = "del" crlf
"EntityName" colon "Domain" crlf
"DomainName" colon sldn crlf
dot crlf
del-nameserver-request = "del" crlf
"EntityName" colon "NameServer" crlf
"NameServer" colon servername crlf
dot crlf
; DESCRIBE command.
describe-request = "describe" crlf
[target-option]
*(option-tag colon option-value crlf)
dot crlf
describe-response = response
"Protocol" colon version-number crlf
*attribute-line
dot crlf
target-option = dash "Target" colon "Protocol" crlf
; MOD command.
mod-request = mod-domain-request / mod-nameserver-request
mod-response = response
*attribute-line
dot crlf
mod-domain-request = "mod" crlf
"EntityName" colon "Domain" crlf
"DomainName" colon sldn crlf
*(add-attribute-value-line /
remove-attribute-value-line /
replace-attribute-value-line)
dot crlf
mod-nameserver-request = "mod" crlf
"EntityName" colon "NameServer" crlf
"NameServer" colon servername crlf
["NewNameServer" colon attribute-value crlf]
*(add-attribute-value-line /
remove-attribute-value-line /
replace-attribute-value-line)
dot crlf
add-attribute-value-line =
attribute-name colon new-attribute-value
remove-attribute-value-line =
attribute-name colon old-attribute-value "="
replace-attribute-value-line =
attribute-name colon old-attribute-value "="
new-attribute-value
old-attribute-value = attribute-value
new-attribute-value = attribute-value
; QUIT command.
quit-request = "quit" crlf
dot crlf
quit-response = response
dot crlf
; RENEW command.
renew-request = "renew" crlf
"EntityName" colon "Domain" crlf
"DomainName" colon sldn crlf
[renew-period-option]
dot crlf
expiration-year-option = dash "CurrentExpirationYear" colon year crlf
renew-period-option = period-option expiration-year-option /
expiration-year-option period-option
renew-response = response
"RegistrationExpirationDate" colon time-stamp crlf
dot crlf
; SESSION command.
session-request = "session" crlf
registrar-id-option
registrar-password-option
[registrar-newpassword-option]
dot crlf
session-response = response
dot crlf
registrar-id-option = dash "Id" colon option-value crlf
registrar-password-option =
dash "Password" colon password crlf
registrar-newpassword-option =
dash "NewPassword" colon password crlf
; STATUS command.
status-request = status-domain-request /
status-nameserver-request
status-response = response
*attribute-line
dot crlf
status-domain-request = "status" crlf
"EntityName" colon "Domain" crlf
"DomainName" colon sldn crlf
dot crlf
status-nameserver-request = "status" crlf
"EntityName" colon "NameServer" crlf
"NameServer" colon servername crlf
dot crlf
; TRANSFER command.
transfer-request = "transfer" crlf
[approve-option]
"EntityName" colon "Domain" crlf
"DomainName" colon sldn crlf
dot crlf
transfer-response = response
"RegistrationExpirationDate" colon time-stamp crlf
dot crlf
approve-option = dash "Approve" colon yesno crlf
; End of grammar.
8. Internationalization
RRP is defined using 7-bit US-ASCII characters. Other character sets
and character codes are not currently supported.
9. Known Issues
RRP was not designed to provide bulk data query features. The primary
goal of the original protocol designers was to provide a fast, light
weight transactional protocol that could be implemented with minimal
need for database queries that would take a "long" time to complete
or that would return a "large" amount of data. Implementers SHOULD
consider developing offline reporting features to provide bulk data
for registrar reporting in a fashion suitable for the given
registry-registrar operating environment.
This version of RRP does contain a few limitations noted over the
course of several months of operational experience with live domain
name registrars. Later versions of this protocol or its successors
should strive to resolve or address each of the following issues:
The DESCRIBE command should return information describing System-
defined default implementation values.
Use of the RENEW command without the "CurrentExpirationYear" and
"Period" parameters does not provide idempotency. Repeated execution
of a RENEW command without these parameters can result in multiple
successful RENEW commands, which may not be the desired action if a
registrar is retrying a RENEW command due to network connectivity
problems.
Time stamps returned by RRP do not include time zone identifiers and
SHOULD be interpreted as local registry time.
The protocol does not provide features for a registrar to become
aware of domain transfer requests and responses. Systems must rely on
means outside of the protocol, such as electronic mail and/or
registry-provided reports, to inform registrars of transfer requests
and responses.
The protocol does not provide features for a registrar to determine
all of the domains served by a name server. Systems must provide this
information using a method outside of the protocol, such as through
periodic extracts from a System database.
The protocol does not provide features to manage lame delegation of
name servers. Any registrar may "use" name servers registered by
another registrar. When a registrar tries to delete a domain or name
server it is quite possible that name servers in the domain to be
deleted or the name server to be deleted will be associated with
other live domains, precluding immediate deletion. Systems must rely
on means outside of the protocol to manage lame delegation of name
servers.
The use of "=" within the MOD command to indicate a value to be
removed is somewhat confusing. A more explicit means of identifying
old and new attribute values within the protocol syntax could make
this feature more obvious.
The CHECK command also returns name server IP addresses when
returning positive confirmation of the registration of a name server.
This extra information may be useful, but it is inconsistent with the
limited function of the command. The command should return a
positive or negative response and nothing more.
The formal protocol syntax described in this document requires a
specific order for the elements of a command entity block and command
options. The NSI Registry's server-side implementation of the
protocol provides the additional flexibility of allowing order
independent specification of options and entity block elements.
Client-side implementers are strongly urged to observe the order of
command elements as specified here to ensure compliance if the more
restricted form is enforced in the future.
RRP does not return time stamps or transaction identifiers to track
transactions. The NSI Registry provides registrars with daily and
weekly reports that include time stamps in local registry time to
document and synchronize data on a per-registrar basis.
10. Security Considerations
Misuse of the Registry Registrar Protocol can have catastrophic
operational consequences for registrants, registrars, and registries.
As such, all registrars must be authenticated prior to all
interactions with the registry. In addition, all data exchanged
between the registrar and the registry must be protected to avoid
unintended disclosure of information.
11. IANA Considerations
IANA assigned TCP port 648 for RRP use in November 1998. No other
action is required of IANA to support operation of this protocol.
IANA has reserved certain IPv4 address ranges as described in
[ALLOCATION]. Implementers MUST ensure that name server IP addresses
do not fall into one of the reserved address ranges to avoid
operational DNS errors.
12. References
[ABNF] Crocker, D. (Editor) and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", RFC2234, November 1997.
[ALLOCATION] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D. and
J. Postel, "Internet Registry IP Allocation Guidelines",
BCP 12, RFC2050, November 1996.
[MUSTSHOULD] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
[SSL] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0
Protocol", Netscape Communications Corp., November 18,
1996.
[TLS] Dierks T. and C. Allen, "The TLS Protocol Version 1.0",
RFC2246, January 1999.
13. Acknowledgments
Many people have contributed significantly to this document and the
protocol it describes. Brad McMillen and Neeran Saraf deserve special
mention as co-authors of an earlier internal protocol specification.
Other content contributors to the earlier internal specification
include Aristotle Balogh, Chris Bason, Mark Kosters, Jasdip Singh,
and Yibing Wu. Finally, significant contributors to the review of
this document include Steve Mahlstedt and Chris Smith.
14. Authors' Addresses
Scott Hollenbeck
Network Solutions, Inc. Registry
505 Huntmar Park Dr.
Herndon, VA 20170
USA
EMail: shollenb@netsol.com
Manoj Srivastava
Network Solutions, Inc. Registry
505 Huntmar Park Dr.
Herndon, VA 20170
USA
EMail: manojs@netsol.com
15. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.