Exhibit G
To
iDomains Registry
Operator’s Proposal
CORE Shared Registry System Protocol (SRSP)
Version 1.1
Klaus Malorny,
Knipp Medien und Kommunikation
September 13th, 2000
1. History......... 6
2. Protocol Structure............ 6
2.1. Transmission
Layer.............. 6
2.1.1. Digital
Signatures... 7
2.1.2. Transmission by
E-Mail.. 7
2.1.3. Transmission by
TCP...... 7
2.1.4. Payload
Encoding.... 8
2.2. Payload.. 8
2.2.1. Registry Data
Model........ 8
2.2.1.1. The Domain Object.... 9
2.2.1.2. The Contact
Object.. 10
2.2.1.3. The Host
Object.. 10
2.2.1.4. The Registrar
Object.. 10
2.2.2. Syntax................. 11
2.2.3. Transaction
Mechanism 12
2.2.4. Common Request
Keys................. 12
2.2.5. Common Response
Keys........ 12
2.2.6. Acknowledge
Responses 13
2.2.7. Replies................. 13
2.2.8. Requests and
their Replies................. 13
2.2.8.1. Complete
Transfer Request 14
2.2.8.2. Create
Contact Request 15
2.2.8.3. Create Domain
Request 16
2.2.8.4. Create Host
Request 16
2.2.8.5. Delete
Contact Request 17
2.2.8.6. Delete Domain
Request 17
2.2.8.7. Delete Host
Request 18
2.2.8.8. Inquire
Contact Request 18
2.2.8.9. Inquire
Domain Request 20
2.2.8.10. Inquire Host
Request 21
2.2.8.11. Inquire
Registrar Request 22
2.2.8.12. Modify
Contact Request 24
2.2.8.13. Modify
Domain Request 24
2.2.8.14. Modify Host
Request 25
2.2.8.15. Modify
Registrar Request 25
2.2.8.16. Query
Request 26
2.2.8.17. Renew Domain
Request 27
2.2.8.18. Status
Request 27
2.2.8.19. Transfer
Domain Request 28
2.2.9. Notifications................. 29
2.2.9.1. Init-Transfer
Notification............. 29
2.2.9.2.
Transfer-Acknowledge Notification............. 29
2.2.9.3.
Transfer-Finish Notification............. 29
2.2.10. Common Data
Types...... 30
2.2.10.1. Handles 30
2.2.10.2. Domain Names.. 30
2.2.10.3. IP Addresses............. 30
2.2.10.4. Dates/Times........... 30
2.2.10.5. Phone and
Fax Numbers 30
2.2.10.6. E-Mail
Addresses............. 30
2.2.10.7. Billing
Units.... 30
2.2.11. Description of
the Keys.. 30
2.2.11.1. Action Key............. 30
2.2.11.2. Address Keys.... 31
2.2.11.3. Admin-Contact
Key...... 31
2.2.11.4.
Approved-Owner-Change Key............. 31
2.2.11.5. City Key 31
2.2.11.6.
Completed-Before Key............. 31
2.2.11.7.
Completed-Since Key............. 32
2.2.11.8. Contact Key...... 32
2.2.11.9. Costs Key............. 32
2.2.11.10. Count Key............. 32
2.2.11.11. Country Key...... 32
2.2.11.12. Created Key...... 33
2.2.11.13. Created-By
Key...... 33
2.2.11.14. Domain-Name
Key............. 33
2.2.11.15.
Domain-State Key 33
2.2.11.16. EMail Key............. 33
2.2.11.17. Error-Code
Key...... 33
2.2.11.18. Error-Text
Key...... 34
2.2.11.19.
Expiration-Date Key 34
2.2.11.20. Fax Key 34
2.2.11.21. FName Key............. 34
2.2.11.22.
Gaining-Registrar Key...... 34
2.2.11.23. Handle Key............. 35
2.2.11.24. Individual
Key...... 35
2.2.11.25. IP-Address
Key...... 35
2.2.11.26.
Last-Modified Key...... 35
2.2.11.27.
Last-Modified-By Key 35
2.2.11.28. List Key 35
2.2.11.29. LName Key............. 36
2.2.11.30.
Managing-Registrar-ID Key...... 36
2.2.11.31.
Notification-Type Key............. 36
2.2.11.32. NS-Host
Keys.... 36
2.2.11.33. Organization
Key... 36
2.2.11.34.
Owner-Contact Key...... 37
2.2.11.35.
Owner-Contact-Origin Key............. 37
2.2.11.36.
Payload-Version Key...... 37
2.2.11.37. Period Key............. 37
2.2.11.38. Phone Key............. 37
2.2.11.39. Postal-Code
Key...... 37
2.2.11.40.
Reg-Admin-Auth-Key Key...... 38
2.2.11.41.
Reg-Admin-Auth-Key-Info Key 38
2.2.11.42.
Reg-Admin-Auth-Type Key...... 38
2.2.11.43.
Reg-Admin-Contact Key...... 38
2.2.11.44.
Reg-Admin-Permissions Key...... 38
2.2.11.45.
Reg-Agent-Auth-Key Keys.... 39
2.2.11.46.
Reg-Agent-Auth-Key-Info Key 39
2.2.11.47.
Reg-Agent-Auth-Type Keys.... 39
2.2.11.48.
Reg-Agent-Contact Keys.... 39
2.2.11.49.
Reg-Agent-Permissions Key...... 40
2.2.11.50. Reg-State
Key...... 40
2.2.11.51.
Reg-Super-Auth-Key Key...... 40
2.2.11.52.
Reg-Super-Auth-Key-Info Key 40
2.2.11.53.
Reg-Super-Auth-Type Key...... 40
2.2.11.54.
Reg-Super-Contact Key...... 40
2.2.11.55.
Reg-Super-Permissions Key...... 41
2.2.11.56. Registrar-ID Key...... 41
2.2.11.57.
Request-Transaction-ID Key 41
2.2.11.58.
Request-Type Key............. 41
2.2.11.59.
Request-State Key 41
2.2.11.60.
Response-Type Key............. 42
2.2.11.61. State Key 42
2.2.11.62.
Submitted-Before Key............. 42
2.2.11.63.
Submitted-Since Key............. 42
2.2.11.64. Success Key...... 42
2.2.11.65.
Tech-Contact Key...... 43
2.2.11.66.
Time-Out-Date Key 43
2.2.11.67. Title Key 43
2.2.11.68.
Transaction-Credit Key............. 43
2.2.11.69.
Transaction-ID Key 43
2.2.11.70.
Transfer-Approved Key...... 44
2.2.11.71.
Transfer-Performed Key...... 44
2.2.11.72. Zone-Contact
Key...... 44
2.2.12. Error Codes....... 44
2.3. Domain Transfer
Process..................... 45
A. References... 48
B. Glossary...... 48
The original Shared Registry System Protocol (version 0.9) was developed by CORE together with Emergent, Inc. in the context of the creation of a registry system suitable for the registration of the anticipated seven new top level domains. Due to the political change, CORE was unable to start the registration of those domains. Instead, CORE got the opportunity to register COM, NET and ORG (CNO) domains via the registry spin-off of Network Solution Inc. As the infrastructure had already been set up and was working, CORE decided to extend the registry system instead of the development of a new system specific to CNO domains. The server system was extended to synchronize its database with NSIRegistry’s via the Registry Registrar Protocol (RRP). The payload of the SRSP was modified to conform to the new needs. The development was performed by Computer Service Langenbach GmbH, and the SRSP got the version number 1.0.
This document describes the version 1.1 of the protocol, which is mostly a cosmetic update of the payload and does not introduce much new functionality.
The protocol defines the communication between a client (operated by the registrar) and the server (operated by the registry). It is message-based, i.e. one side (either the server or the client), compiles a packet with its data (called payload) and sends it to the opposite side. The receive and transmit channels are not synchronized: The client does not need to wait for the server’s answer to send additional requests; the server does not need to send the responses immediately or in the order in which the client sent the requests. But it is guaranteed that the server does not send responses not related to the particular client, i.e. the client does not receive unexpected responses. Due to the transaction management, situations where the communication fails can be handled (see below for details).
The protocol consists of two layers. The transport layer defines the communication between the client and the server. It is also responsible for the client/server authentication and for the secure transmission of the payload data.
The payload represents the application layer. It defines the requests from the clients and the responses from the server. A built-in transaction management allows the processing of asynchronous, interleaved requests.
For the purpose of domain transfers, it is required that the registry can notify the registrar about certain events. This does not fit in mentioned request-reply schema. Therefore, the notification is handled separately, but by using the same technologies: The server uses the e-mail transmission variant for the notification. The destination e-mail address is a fixed address specified by the registrar. The format of the payload is the same, although different keys are used.
The transmission layer is responsible for the transfer of the payload to the server and back to the client. The SRSP defines two different variants for this transfer: by e-mail and by a TCP connection. In both cases, the authentication and the secure transmission is done by digital signatures[1]. The format of the signatures conforms to the standard defined by [PGP5].
For the attachment of the signature to the payload, the PGP specific variant of the S/MIME standards is used, as described in [RFC1847] and [RFC2015]. The following content-type specific attributes must be used in the context of this protocol:
micalg pgp-sha1
protocol application/pgp-signature
The keys must use the DSS/Diffie-Hellman algorithms. Keys of other types are not accepted. Depending on whether the message is sent to the server or to the client, it is signed by different keys.
On the server side, a registry specific key is used to sign the messages to the clients. On the client side, multiple keys can be used. There is a super contact with a corresponding key, which is maintained by the registry. An administrative contact and additional agents with their keys can be added by registrar at will (see modify registrar below).
The PGP-signed payload is sent to a specific address at the registry. The registry uses the contents of the reply-to field or, if it does not exist, the contents of the from field specifies the e-mail address, to which the server’s response is sent back. The e-mail address is not used to authenticate the user — the registrar-id field together with the key used for the signature identifies and authenticates the user.
Due to the mechanisms behind the e-mail transport, there is a risk of wrongly delivered e-mails and eavesdropping. Although protocol does not transport very sensitive data, it is recommended not to use this transmission method.
In this variant, the messages are transported between client and server via a TCP connection. Port number 362/service name srssend has been assigned for that service [IANA-PORTS].
For transmission, the payload is signed according to the rules above. A message is constructed according to the syntactic rules specified in [RFC822] and [RFC1521], with the difference that the header consists only of MIME related fields, i.e., in relation to this application, exactly of the content-type field.
The message is sent through the TCP connection without additional information (length or termination mark). Since the outermost content-type is always a multipart type (multipart/signed), the body of the message always contains MIME boundaries. The reader can easily detect the end of the message by watching the input stream for the closing boundary (it differs from intermediate boundaries by two additional hyphens).
A typical message looks like this:
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
PGPFormat="PGPMIME-signed";
boundary="12027960_39A4DF56751968_1"
--12027960_39A4DF56751968_1
Content-Type: text/x-srs-data
payload-version: 1.1
transaction-id: 4084.968850757
registrar-id: CORE-326
request-type: inquire registrar
handle: CORE-326
--12027960_39A4DF56751968_1
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: PGP 5.0i
MessageID: gA7PE4txVcbglLFpY14pt9BreT3zhESX
iQA/AwUBOaTfVibmObpCSbN4EQIN5wCg7cU9iCZyeGaXBqRkjFJyD550PpoAn3Mx
X/ur+CMmG+WfaeYQNOL73KgN
=sPqi
-----END PGP SIGNATURE-----
--12027960_39A4DF56751968_1--
The payload has the content-type text/x-srs-data. No MIME content transfer encoding or compression may be applied to the payload.
Before describing the requests of the client and the responses of the server, it is important to understand the model on which the registry operates.
The registry stores objects. An object is, in this context, a collection of related data. Four different object types exist: domains, contacts, hosts and registrars (explained later). Each object has a unique identifier. This identifier is either a certain part of the data (in case of the domain object, it is the domain name), or it is a unrelated text label, usually called handle.
|
object type |
unique identifier |
|
domain |
the domain name, case insensitive |
|
contact |
text label COCO-N (where N is a positive number) |
|
Host |
text label COHO-N (where N is a positive number) |
|
registrar |
text label CORE-N (where N is a positive number) |
Objects can reference each other, e.g. domains reference hosts for the purpose of specifying the name servers which manage the corresponding zones. Referenced objects cannot be deleted, as the referencing objects would become invalid. A change to a referenced object indirectly modifies all referencing objects[2], e.g., changing a host’s IP address results in a change of all domains referencing it: The next build of the registry’s master zone file would contain the new IP address for those domains.
The objects are shared among the registrars, i.e., any registrar can view or use any object. Domain, contact and host objects have a property of the managing registrar. Each of those objects is managed by the registrar who created it. The property restricts the right to modify a certain object: only the managing registrar may change it. The managing registrar of domains is changed during the transfer domain process. The managing registrar of contacts and hosts cannot be changed. Even in the case of a domain transfer between registrars, the contacts and hosts referenced in the domain stay at the loosing registrar. The gaining registrar can continue to use these contacts and hosts or it can create new ones and update the domain accordingly.
The domain object stores the domain related data, which is
- the domain name itself, fully qualified
- the owner of the domain
- the administrative, technical and zone contact of the domain (the tasks of these contacts is out of the scope of this document)
- up to twelve hosts
- the registration period in years
- the state of the domain
The contacts (excluding the owner) and hosts are stored as references to the corresponding objects. The owner is directly stored in the domain object. It contains the data of a given contact object at the point of time of the creation or modification of the domain object. Later changes to the contact object do not modify the contents of the domain object. Although the domain object stores a reference to the owner contact object, the reference has only informational character: It just informs the registrar about the origin of the owner data.
The registration period determines how long the domain will operate without further interaction and how much is deducted from the registrar’s account.
The state has one of the four possible values:
|
reserved |
the domain is registered but no entry is generated in the registry’s master zone file. |
|
production |
the domain is registered and fully functional |
|
expired |
the registration period has expired (the exact consequences are out of the scope of this document, limited modification rights may apply) |
|
hold |
the domain is currently matter of a dispute (the exact consequences are out of the scope of this document, limited modification rights may apply) |
The contact object stores the identity and various types of addresses of an individual or of an organization. It contains the following data:
- a flag which identifies whether the contact is an individual or an organization
- the first name, the last name and the title of the individual
- the name of the organization
- The "real world" address: two free form address lines (typically used for specification of the street, but may contain a more specific or different inner-city address), the city (including the postal code), the state and the country.
- the phone number (with international area code)
- the fax number (with international area code)
- the e-mail address
Although it should be avoided by the registrar, it is possible to create multiple contact objects for exactly the same person or organization.
The host object describes a name server, which is able to respond to DNS requests ([RFC1035]) for those domains which reference this object. The following data is stored in the object:
- the domain name of the name server
- the IP address of the name server (optional)
- a reference to a contact object (identifying a person or organization, who/which is responsible for the name server; optional)
Although it should be avoided by the registrar, it is possible to create multiple host objects with the same domain name or IP address. Please note that the host object does not contain a reference to a domain object, so a domain object may be deleted even if a host exists that is located inside (in the sense of the domain name system) that domain.
The registrar object is maintained by the registry. Some parts of the data are exposed to the registrars, and a registrar is able to modify some aspects of his own data. The data which is exposed is:
- the name and the handle of the registrar
- the status (active, suspended or defunct)
- the account balance
- the super, administrative and agent contacts, along with PGP related information and permissions.
The payload consists of readable text, encoded by the 7-Bit ASCII encoding. It represents a set of key-value pairs. A single key may appear multiple times. In this case, each appearance of the key represents an independent record and is not the continuation of a previous key-value pair. The order of differing keys is irrelevant. In the case of multiple identical keys, the order is important.
Two representations exist for a key-value pair. They differ only syntactically: the first variant is more suitable for single line entries. If it starts with a quote, that quote must be doubled to make the entry different to the second variant. The value may continue on the next line, but the newline must be prefixed by a backslash (the backslash/newline combination does not become part of the value). Whitespace that appears at the start or at the end of the value is ignored.
The second form is a multi-line form which is used for lengthy data, e.g. an ASCII encoded PGP public key. It starts and ends with a double quote. Any non double-quote character between them is allowed, even a newline. The quotes are not part of the value.
The key is case-insensitive.
The formal grammer of the payload is:
payload
::= kv-pair*
kv-pair
::= key whitespace* : value
newline | newline
value
::= value1 | value2 | whitespace*
value1
::= value1start value1other*
value1start
::= value-char
| "" | \ newline
value1other
::= value-char
| " | \ newline
value2
::= " value2char+ "
value2char
::= value-char
| newline | \
value-char[3]
::= whitespace
| ! | [0x23 .. 0x5B] | [0x5D .. 0x7E]
key
::= key-char+
key-char[4]
::= [0x21 .. 0x39] | [0x3B .. 0x7E]
newline
::= 0x0D | 0x0D 0x0A | 0x0A
whitespace
::= 0x20 | 0x09
(name denotes a non-terminal symbol, | separates alternatives, x denotes a literal character or character sequence, 0xNN the hexadecimal code of a character, [ from .. to ] a sub-range of the ASCII character set, ? zero or one occurrences, + one or more occurrences, * zero or more occurrences)
The protocol uses transaction identifiers to enable the tracking of requests. The transaction identifier is specified by the client via the transaction-id key. The server uses that identifier in every response, so the client can associate these responses to the corresponding requests.
The server reacts to a normal request by sending two responses. The first is an acknowledge (response-type: ack) and is sent immediately after the reception at the server. After the processing of the request, the server sends the results back to the client (response-type: reply).
In both transmission variants (e-mail and TCP), it may happen that the communication fails — either the e-mail is lost or the TCP connection is interrupted, maybe just in the moment of sending a request or receiving a response. In the case of requests which do not modify the state of the registry, the client has to repeat the request, since the server does not back up the results of such requests.
For requests that modify the state of the registry, the server saves the results of processed requests for a certain time, at least for a day. Two special request exist to help the client on its recovery: With the status request, the client is able to retrieve the status of a specific request. The server responses either with the result of the request, with the current processing state or with the information that no request with the given transaction identifier exist (either the request has not yet been received or it is lost).
The other special request is the query request. By this request, the client can ask the server to send back a list of transaction identifiers of requests, whose submission or completion time falls in a specified period and that have the specified processing state.
Each registrar has its own name space for the transaction identifiers. Therefore it is not possible to request information about transactions of different registrars.
All requests sent to the server must contain at least the following four key: registrar-id, payload-version, transaction-id and request-type.
The registrar-id key identifies the registrar. It is also used for authentication in combination with the signature of the transmission layer.
the payload-version key enables the server to identify the version of the payload and to react differently to different client software versions.
The transaction-id key represents the transaction identifier of the request, as discussed above.
The request-type key describes the action the server should perform on behalf of the client.
All responses sent from the server contain at least the following three keys: registrar-id, transaction-id and response-type.
The registrar-id identifies the registrar, whose request is replied.
The transaction-id identifies the request the response corresponds to.
The response-type tells whether the response is an intermediate (acknowledge) or the final response (reply).
The acknowledge response is immediately sent by the server to notify that the request has been received, that it is syntactically correct, that the client authentication was successful, that it conforms so far to the protocol and that it can be queued for processing. It does, however, not give any clues whether the processing of the request will succeed or fail. If one of the conditions above is not satisfied, a reply is sent back instead, indicating the corresponding error.
The client does not need to take this response into account, but it can use this message for the internal management of the requests eventually.
The acknowledge response has the value ack for the response-type key. No additional keys appear in this message.
Any reply contains the request-state key, indicating whether the request was successfully (value succeeded) processed or whether the processing failed for any reason (value failed).
If the processing is successful, the reply contains the success key, which contains an informational message.
If the processing fails, the reply contains a list of errors which were detected. This list is not necessarily complete, i.e., if these errors are corrected, it is not guaranteed that the new request will succeed.
The errors are reported by the error-code and error-text keys. The n-th error-code key corresponds to the n-th error-text key.
The protocol defines the following requests:
|
domain related |
create
domain |
R |
creates a new domain object |
|
|
modify
domain |
R |
modifies a domain, including owner changes |
|
|
delete
domain |
R |
deletes an existing domain |
|
|
renew domain |
R |
extends the registration period of a domain |
|
|
transfer
domain |
R |
either initiates an incoming domain transfer or confirms (positively or negatively) an outgoing domain transfer |
|
|
complete
transfer |
R |
completes an incoming domain transfer |
|
|
inquire
domain |
|
requests the data of a domain object |
|
contact related |
create
contact |
R |
creates a new contact object |
|
|
modify
contact |
R |
modifies an existing contact |
|
|
delete
contact |
R |
deletes an existing contact |
|
|
inquire
contact |
|
requests the data of a contact object |
|
host related |
create host |
R |
creates a new host object |
|
|
modify host |
R |
modifies an existing host |
|
|
delete host |
R |
deletes an existing host |
|
|
inquire host |
|
requests the data of a host object |
|
registrar related |
modify
registrar |
R |
modifies the exposed parts of a registrar object |
|
|
inquire
registrar |
|
requests the exposed data of a registrar object |
|
transaction management |
status |
|
requests the status of a specified request |
|
|
query |
|
requests all the transaction identifiers of the requests of a specified period |
The replies of the requests marked with R are recorded and can be queried by the status and query requests.
General information:
|
request type: |
complete transfer |
|
recorded: |
yes |
The complete transfer request is the final step in the process for an incoming domain transfer. The request and reply keys are identical to the create domain request.
Special request keys:
|
domain-name |
M |
the domain name |
|
owner-contact |
M |
the new owner (approved-owner-change must be Y to come into effect) |
|
admin-contact |
M |
the new administrative contact |
|
tech-contact |
M |
the new technical contact |
|
zone-contact |
M |
the new zone contact |
|
approved-owner-change |
M |
flag, whether an owner change should be performed (see also the modify domain request) |
|
ns1-host |
O |
either none or at least two name servers must be specified. If no name server is specified, the domain state must be set to reserved. |
|
domain-state |
M |
either production or reserved. Other states may not be assigned by a registrar. |
(M mandatory key, O optional key, D disallowed)
Special reply keys:
|
expiration-date |
the point of time when the domain expires |
|
costs |
the costs of the transfer |
General information:
|
request type: |
create contact |
|
recorded: |
yes |
The create contact request creates a new contact object in the registry’s database.
Special request keys:
|
individual |
M |
determines whether this contact describes an individual (Y) or an organization (N) |
|
fname |
M/D |
the first name of the individual |
|
lname |
M/D |
the last name of the individual |
|
title |
O/D |
the title of the individual |
|
organization |
O/M |
the organization (may be specified for an individual also) |
|
address-1 |
M |
the city-local address |
|
address-2 |
O |
additional address |
|
city |
M |
the city where the individual/organization is located in |
|
postal-code |
M |
the postal code of the city |
|
state |
O |
the state where the city is located in |
|
country |
M |
the country the city is located in |
|
phone |
M |
the phone number |
|
fax |
O |
the fax number |
|
email |
M |
the e-mail address |
(M mandatory key, O optional key, D disallowed)
Special reply keys:
|
handle |
the handle for the contact, assigned by the server |
General information:
|
request type: |
create domain |
|
recorded: |
yes |
The create domain request creates a new domain. The name may not exist when the request is processed.
Special request keys:
|
domain-name |
M |
the domain name |
|
owner-contact |
M |
the owner |
|
admin-contact |
M |
the administrative contact |
|
tech-contact |
M |
the technical contact |
|
zone-contact |
M |
the zone
contact |
|
ns1-host |
O |
either none or at least two name servers must be specified. If no name server is specified, the domain state must be set to reserved. |
|
domain-state |
M |
either production or reserved. Other states may not be assigned by a registrar. |
|
period |
O |
the registration period. If omitted, a registry specific default period is used. |
(M mandatory key, O optional key, D disallowed)
Special reply keys:
|
expiration-date |
the point of time when the domain expires |
|
costs |
the costs of the creation |
General information:
|
request type: |
create host |
|
recorded: |
yes |
The create host request creates a new host object in the registry’s database.
Special request keys:
|
contact |
O |
a contact that is responsible for the host |
|
domain-name |
M |
the domain name of the host |
|
ip-address |
O |
the IP address of the host |
(M mandatory key, O optional key, D disallowed)
Special reply keys:
|
handle |
the handle for the host, assigned by the server |
General information:
|
request type: |
delete contact |
|
recorded: |
yes |
The delete contact request deletes an existing contact object in the registry’s database. The object may not be referenced by other objects, i.e., may not appear in a host contact or domain contact (as the owner or the admin, technical or zone contact). The object must be managed by the registrar.
Special request keys:
|
handle |
M |
the contact handle of the object |
(M mandatory key, O optional key, D disallowed)
General information:
|
request type: |
delete domain |
|
recorded: |
yes |
The delete domain request deletes an existing domain object in the registry’s database. The object must be managed by the registrar. Depending on the registry’s policy, costs are refunded if a domain is deleted a short time after the creation.
Special request keys:
|
domain-name |
M |
the name of the domain to be deleted |
(M mandatory key, O optional key, D disallowed)
Special reply keys:
|
costs |
the costs (refunds) of the deletion |
General information:
|
request type: |
delete host |
|
recorded: |
yes |
The delete host request deletes an existing host object in the registry’s database. The object may not be referenced by other objects, i.e., may not appear in a domain as a name server. The object must be managed by the registrar.
Special request keys:
|
handle |
M |
the host handle of the object |
(M mandatory key, O optional key, D disallowed)
General information:
|
request type: |
inquire contact |
|
recorded: |
no |
The inquire contact request returns information about an existing contact object. Depending on the existence and the value of the list key, either the contact details or its usage in domains and hosts is returned.
Special request keys:
|
handle |
M |
the contact handle of the object |
|
list |
O |
what kind of information should be returned. If key does not exist or is empty, then details about the contact are returned (case 1). If the value is equal to domains, a list of domains, which use this contact as the owner, the administrative, technical or zone contact, is returned (case 2). If the value is equal to hosts, a list of hosts using the object as a contact is returned (case 3). |
(M mandatory key, O optional key, D disallowed)
Special reply keys (case 1):
|
handle |
the handle of the object |
|
individual |
determines whether this contact describes an individual (Y) or an organization (N) |
|
fname |
the first name of the individual |
|
lname |
the last name of the individual |
|
title |
the title of the individual |
|
organization |
the organization |
|
address-1 |
the city-local address |
|
address-2 |
additional address |
|
city |
the city where the individual/organization is located in |
|
postal-code |
the postal code of the city |
|
state |
the state where the city is located in |
|
country |
the country the city is located in |
|
phone |
the phone number |
|
fax |
the fax number |
|
email |
the e-mail address |
|
managing-registrar-id |
the managing registrar |
|
created |
the point of time when the object was created |
|
created-by |
the registrar who created the object (typically identical to managing-registrar-id) |
|
last-modified |
the point of time when the object was modified at last. It appears only after the first modification. |
|
last-modified-by |
the registrar who modified the object at last (typically identical to managing-registrar-id). It appears only after the first modification. |
Special reply keys (case 2):
|
domain-name |
a domain name. This key is repeated for each domain. |
|
count |
the number of domains that use the contact |
Special reply keys (case 3):
|
handle |
a host handle. This key is repeated for each host. |
|
count |
the number of hosts that use the contact |
General information:
|
request type: |
inquire domain |
|
recorded: |
no |
The inquire domain request returns information about an existing domain object.
Special request keys:
|
domain-name |
M |
the name of the domain |
(M mandatory key, O optional key, D disallowed)
Special reply keys:
|
domain-name |
the domain name |
|
individual |
owner: determines whether this contact describes an individual (Y) or an organization (N) |
|
fname |
owner: the first name of the individual |
|
lname |
owner: the last name of the individual |
|
title |
owner: the title of the individual |
|
organization |
owner: the organization |
|
address-1 |
owner: the city-local address |
|
address-2 |
owner: additional address |
|
city |
owner: the city where the individual/organization is located |
|
postal-code |
owner: the postal code of the city |
|
state |
owner: the state where the city is located in |
|
country |
owner: the country the city is located in |
|
phone |
owner: the phone number |
|
fax |
owner: the fax number |
|
email |
owner: the e-mail address |
|
owner-contact-origin |
the handle of the contact which was used as the source of the owner data |
|
admin-contact |
the handle of the administrative contact |
|
tech-contact |
the handle of the technical contact |
|
zone-contact |
the handle of the zone contact |
|
managing-registrar-id |
the managing registrar |
|
ns1-host |
the handles of the name servers |
|
domain-state |
the current domain state |
|
created |
the point of time when the object was created |
|
created-by |
the registrar who created the object (typically identical to managing-registrar-id) |
|
last-modified |
the point of time when the object was modified at last. It appears only after the first modification. |
|
last-modified-by |
the registrar who modified the object at last (typically identical to managing-registrar-id). It appears only after the first modification. |
General information:
|
request type: |
inquire host |
|
recorded: |
no |
The inquire host request returns information about an existing host object. Depending on the existence and the value of the list key, either the host details or its usage in domains is returned.
Special request keys:
|
handle |
M |
the host handle of the object |
|
list |
O |
what kind of information should be returned. If key does not exist or is empty, then details about the host are returned (case 1). If the value is equal to domains, a list of domains, which use this host as a name server, is returned (case 2). |
(M mandatory key, O optional key, D disallowed)
Special reply keys (case 1):
|
handle |
the handle of the object |
|
contact |
a contact that is responsible for the host |
|
domain-name |
the domain name of the host |
|
ip-address |
the IP address of the host |
|
created |
the point of time when the object was created |
|
created-by |
the registrar who created the object (typically identical to managing-registrar-id) |
|
last-modified |
the point of time when the object was modified at last. It appears only after the first modification. |
|
last-modified-by |
the registrar who modified the object at last (typically identical to managing-registrar-id). It appears only after the first modification. |
Special reply keys (case 2):
|
domain-name |
a domain name. This key is repeated for each domain. |
|
count |
the number of domains that use the host |
General information:
|
request type: |
inquire registrar |
|
recorded: |
no |
The inquire registrar request returns some information about a registrar. If the list key is not present or has an empty value, information about the users and their public keys is returned (case 1). If the value of the list key is domains, the domains managed by the registrar are listed (case 2). If the value is hosts, the hosts managed by the registrar are listed (case 3). If the value is contacts, the contacts managed by the registrar are listed (case 4).
Special request keys:
|
handle |
M |
the handle of the registrar |
|
list |
O |
whether the contacts, hosts or domains of the registrar should be listed |
(M mandatory key, O optional key, D disallowed)
Special reply keys (case 1):
|
handle |
the handle of the registrar |
|
organization |
the name of the registrar |
|
reg-admin-permissions |
the allowed request types |
|
reg-admin-contact |
the contact handle |
|
reg-admin-auth-type |
the type of the public key |
|
reg-admin-auth-key-info |
information about the public key |
|
reg-agent-permissions |
the allowed request types |
|
reg-agent1-contact |
the contact handles |
|
reg-agent1-auth-type |
the types of the public keys |
|
reg-agent1-auth-key-info |
information about the public keys |
|
reg-super-permissions |
the allowed request types |
|
reg-super-contact |
the contact handle |
|
reg-super-auth-type |
the type of the public key |
|
reg-super-auth-key-info |
information about the public key |
|
reg-state |
the state of the registrar |
|
transaction-credit |
the current balance of the account |
|
created |
the point of time when the object was created |
|
created-by |
the registrar who created the object (typically identical to managing-registrar-id) |
|
last-modified |
the point of time when the object was modified at last. It appears only after the first modification. |
|
last-modified-by |
the registrar who modified the object at last (typically identical to managing-registrar-id). It appears only after the first modification. |
Special reply keys (case 2):
|
domain-name |
a domain name. This key is repeated for each domain. |
|
count |
the number of domains |
Special reply keys (case 3):
|
handle |
a host handle. This key is repeated for each host. |
|
count |
the number of hosts |
Special reply keys (case 4):
|
handle |
a contact handle. This key is repeated for each host. |
|
count |
the number of contacts |
General information:
|
request type: |
modify contact |
|
recorded: |
yes |
The create contact request modifies an existing contact object. The object must be managed by the registrar.
Special request keys:
|
handle |
M |
the handle of the contact |
|
individual |
M |
determines whether this contact describes an individual (Y) or an organization (N) |
|
fname |
M/D |
the first name of the individual |
|
lname |
M/D |
the last name of the individual |
|
title |
O/D |
the title of the individual |
|
organization |
O/M |
the organization (may be specified for an individual also) |
|
address-1 |
M |
the city-local address |
|
address-2 |
O |
additional address |
|
city |
M |
the city where the individual/organization is located in |
|
postal-code |
M |
the postal code of the city |
|
state |
O |
the state where the city is located in |
|
country |
M |
the country the city is located in |
|
phone |
M |
the phone number |
|
fax |
O |
the fax number |
|
email |
M |
the e-mail address |
(M mandatory key, O optional key, D disallowed)
General information:
|
request type: |
modify domain |
|
recorded: |
yes |
The modify domain request changes contacts and name servers of the given domain. Data from the given owner contact is either copied partially or fully into the domain object, depending on the value of the approved-owner-change key. If the value is Y, all fields are copied. If the value is N, the following fields are copied: title, email, phone and fax.
Special request keys:
|
domain-name |
M |
the domain name |
|
owner-contact |
O |
the new owner (effect depends on the approved-owner-change key; see above) |
|
admin-contact |
O* |
the new administrative contact |
|
tech-contact |
O* |
the new technical contact |
|
zone-contact |
O* |
the new zone contact |
|
approved-owner-change |
O* |
flag, whether an owner change should be performed |
|
ns1-host |
O |
either none or at least two name servers must be specified. If no name server is specified, the domain state must be set to reserved. |
|
domain-state |
O* |
either production or reserved. Other states may not be assigned by a registrar. |
(M mandatory key, O optional key, D disallowed)
* not changed if key is omitted
General information:
|
request type: |
modify host |
|
recorded: |
yes |
The modify host request modifies an existing host object. The object must be managed by the registrar.
Special request keys:
|
Contact |
O |
a contact that is responsible for the host |
|
domain-name |
M |
the domain name of the host |
|
ip-address |
O |
the IP address of the host |
(M mandatory key, O optional key, D disallowed)
General information:
|
request type: |
modify host |
|
recorded: |
yes |
The modify registrar request enables the registrar to modify some aspects of his data stored in the registry system, mainly the keys and the identities of the staff working with the SRS.
Special request keys:
|
Handle |
M |
the handle of the registrar |
|
Organization |
O* |
the name of the registrar |
|
reg-admin-contact |
O* |
the contact describing the administrator |
|
reg-admin-auth-type |
O* |
the type of the authorization the administrator uses |
|
reg-admin-auth-key |
O* |
the public key of the administrator |
|
reg-agent1-contact |
O* |
the contacts describing the agents |
|
reg-agent1-auth-type |
O* |
the types of the authorizations of the agents |
|
reg-agent1-auth-key |
O* |
the public keys of the agents |
|
reg-super-contact |
O* |
the contact describing the super administrator |
|
reg-super-auth-type |
O* |
the type of the authorization the super administrator uses |
|
reg-super-auth-key |
O* |
the public key of the super administrator |
(M mandatory key, O optional key, D disallowed)
* if omitted, the corresponding entry is not modified
General information:
|
request type: |
query |
|
recorded: |
no |
The query request returns information about requests submitted/completed in a given period of time. Only those requests are returned, whose results were recorded previously. See the general information/recorded entries in the description of the requests whether the results are recorded or not. The requests are returned in chronological order regarding to the submission date.
Special request keys:
|
completed-before |
O |
if present, it restricts the output to those requests which were completed before the given date (including) |
|
completed-after |
O |
if present, it restricts the output to those requests which were completed after the given date (including) |
|
submitted-before |
O |
if present, it restricts the output to those requests which were submitted before the given date (including) |
|
submitted-after |
O |
if present, it restricts the output to those requests which were submitted after the given date (including) |
|
request-state |
O |
if present, it restricts the output to those requests which are in the given state. |
(M mandatory key, O optional key, D disallowed)
Special reply keys:
|
request-transaction-id |
a transaction identifier that matches the condition(s). This key is repeated for each request |
|
count |
the number of requests matching the condition(s) |
General information:
|
request type: |
renew domain |
|
recorded: |
yes |
The renew domain request extends the registration period of a domain.
Special request keys:
|
domain-name |
M |
the domain name |
|
period |
M |
the extension of registration period. |
(M mandatory key, O optional key, D disallowed)
Special reply keys:
|
expiration-date |
the point of time when the domain expires |
|
costs |
the costs of the renewal |
General information:
|
request type: |
status |
|
recorded: |
no |
The status request enables the client to retrieve information about requests sent to the server earlier. If the request has been finished, the result of it is returned. If the specified transaction identifier is unknown to the server, the server returns a failed request state with the error-code key indicating the problem.
Special request keys:
|
transaction-id |
M |
In contrast to other requests, not a new transaction identifier should be specified here, but the transaction identifier of the request to be inspected instead. |
(M mandatory key, O optional key, D disallowed)
Special reply keys:
|
request-state |
If the request related to the given transaction identifier does not exist, failed is returned and error code -270 is returned. If the request has been received, but not yet been processed, either pending or in-process is returned. If the request has been processed, the key contains the corresponding value of the request’s reply. |
|
(other) |
see the description of the specific request |
General information:
|
request type: |
transfer domain |
|
recorded: |
yes |
The transfer domain request is used in the process of the transfer of a domain from one registrar to another registrar. The request is both used for incoming and outgoing transfers. See below for the exact process.
Special request keys:
|
domain-name |
M |
the domain name |
|
action |
M |
the action to be performed. |
(M mandatory key, O optional key, D disallowed)
During the domain transfer process, the server sends notifications to the registrar. The notifications use the e-mail transmission variant and the payload layer. The registrar may react upon the notifications by sending normal requests to the server via one of its clients. The notification contains at least two keys:
|
payload-version |
identifies the version of the payload used for the notification |
|
notification-type |
the type of notification |
General information:
|
notification type: |
init-transfer |
The init-transfer notification is sent to the loosing registrar to inform that a domain transfer process has been started for the given domain.
Additional keys:
|
domain-name |
the name of the domain to be transferred |
|
gaining-registrar |
the registrar who initiated the transfer |
|
time-out-date |
point of time until the loosing registrar can react |
General information:
|
notification type: |
transfer-acknowledge |
The transfer-acknowledge notification is sent to the gaining registrar to inform about the decision of the loosing registrar (or the registry in case of a timeout).
Additional keys:
|
domain-name |
the name of the domain to be transferred |
|
transfer-approved |
tells whether the loosing registrar has acknowledged the transfer positively or negatively. |
|
time-out-date |
point of time until the gaining registrar can react |
General information:
|
notification type: |
transfer-finish |
The transfer-finished notification is sent to the loosing registrar (and to the gaining registrar in case of a time-out) to inform about the final result of the domain transfer process.
Additional keys:
|
domain-name |
the name of the domain |
|
transfer-performed |
tells whether the transfer has been performed or not |
SRSP specific handles share a common format: a prefix followed by a number. The prefix is CORE-, COCO- and COHO- for registrar, contact and host handles, respectively. The case of the prefixes does not matter. Handles are always assigned by the server (or, for the registrar handle, by the registry staff).
Domain names are always fully qualified domain names (see [RFC1035]) without a trailing dot.
The IP Addresses are IPv4 addresses in the form A.B.C.D, where A, B, C, D are numbers between 0 and 255.
A date and time always appear in combination. The time zone is Greenwich Mean Time (GMT). The exact format is
YYYYMMDD hh:mm:ss
where YYYY is four-digit year, MM is the two-digit month, DD is the two digit day, hh is the two digit hour, mm is the two digit minute and ss is the two digit second. Date and time are separated by exactly one space character (0x20).
It is strongly recommended (although not required) that telephone and Fax numbers are specified in the international format, i.e., starting with a plus sign, followed by the international area code, by the area code used in the specific country and by the local subscriber number.
E-mail addresses should conform to the format specified in [RFC822], without any comments.
CORE uses a fictional currency for the registrars’ accounts. It is called RCU (registry currency unit). It is a number with two fractional digits.
|
name: |
action |
|
used by: |
client |
|
format/values: |
either init-transfer, abort-transfer, positive-transfer-ack or negative-transfer-ack (case insensitive) |
|
description: |
The action to be performed in a domain transfer process. |
|
name: |
address-1 |
|
used by: |
client, server |
|
format/values: |
text string, no more than 50 characters |
|
description: |
Specifies a contact’s address. |
|
name: |
admin-contact |
|
used by: |
client, server |
|
format/values: |
contact handle |
|
description: |
Administrative contact (of a domain). |
|
name: |
approved-owner-change |
|
used by: |
client |
|
format/values: |
Y or N (case insensitive) |
|
description: |
If Y (yes), it signals that the requirements for an owner change have been fulfilled by the registrar and that the owner data of the domain should be updated by the given owner contact handle. If N (no), most of the previous owner data is retained. See the modify domain request for details. |
|
name: |
city |
|
used by: |
client, server |
|
format/values: |
text string, no more than 50 characters |
|
description: |
Specifies the city where the contact is located in. |
|
name: |
completed-before |
|
used by: |
client |
|
format/values: |
date |
|
description: |
Specifies the upper bound for the completion date of a request to be found by the query request. |
|
name: |
completed-since |
|
used by: |
client |
|
format/values: |
date |
|
description: |
Specifies the lower bound for the completion date of a request to be found by the query request. |
|
name: |
contact |
|
used by: |
client, server |
|
format/values: |
contact handle |
|
description: |
(Administrative, technical) contact of the host. |
|
name: |
costs |
|
used by: |
server |
|
format/values: |
RCU value |
|
description: |
Specifies the amount of RCUs which were deducted from the registrar’s account. A positive value is a debit, a negative value a credit. |
|
name: |
count |
|
used by: |
server |
|
format/values: |
positive number |
|
description: |
The number of objects that meet the criteria (inquire requests in combination with the list key, or the query request). The value is not necessarily identical with the number of object handles/domain names returned: the actual number of objects listed may be reduced due to the registry policy. |
|
name: |
country |
|
used by: |
client, server |
|
format/values: |
text string, no more than 50 characters; although not required, it is strongly recommended to use the ISO two letter code [ISO3166] |
|
description: |
Specifies the country where the contact is located in. |
|
name: |
created |
|
used by: |
server |
|
format/values: |
date |
|
description: |
Specifies the date when the object was created. |
|
name: |
created-by |
|
used by: |
server |
|
format/values: |
registrar handle |
|
description: |
Specifies the handle of the registrar who created the object. |
|
name: |
domain-name |
|
used by: |
client, server, notification |
|
format/values: |
domain name |
|
description: |
For domain objects the name of the domain, for host objects the DNS name of the host. |
|
name: |
domain-state |
|
used by: |
client, server |
|
format/values: |
either reserved, production, expired or hold (case insensitive) |
|
description: |
The state of the domain. See the description of the domain object for details. |
|
name: |
|
|
used by: |
client, server |
|
format/values: |
text string, containing a single valid e-mail address |
|
description: |
Specifies an e-mail address. |
|
name: |
error-code |
|
used by: |
server |
|
format/values: |
integer number (positive or negative) |
|
description: |
Indicates a specific error. See below for the error codes. |
|
name: |
error-text |
|
used by: |
server |
|
format/values: |
text string |
|
description: |
Contains a human readable explanation of the error. The string is meant for debugging purposes. The client should not attempt to parse the contents of this string. Therefore, no description of the various texts are given in this document. |
|
name: |
expiration-date |
|
used by: |
server |
|
format/values: |
date |
|
description: |
Specifies the date when the domain expires. |
|
name: |
fax |
|
used by: |
client, server |
|
format/values: |
text string, containing a phone number of a fax machine |
|
description: |
Specifies a fax number. |
|
name: |
fname |
|
used by: |
client, server |
|
format/values: |
text string, no more than 50 characters |
|
description: |
Specifies the first name of an individual. |
|
name: |
gaining-registrar |
|
used by: |
notification |
|
format/values: |
registrar handle |
|
description: |
Specifies the registrar who wants to gain a domain in a domain transfer process. |
|
name: |
handle |
|
used by: |
client, server |
|
format/values: |
handle |
|
description: |
Specifies the handle of the target object to be modified, deleted or inquired (client) or the handle that has been assigned by the server |
|
name: |
individual |
|
used by: |
client, server |
|
format/values: |
either Y or N (case insensitive) |
|
description: |
Specifies whether a contact describes an individual (Y) or an organization (N). |
|
name: |
ip-address |
|
used by: |
client, server |
|
format/values: |
An IP address |
|
description: |
Specifies the IP address of a host. |
|
name: |
last-modified |
|
used by: |
server |
|
format/values: |
date |
|
description: |
Specifies the date when the object was modified at last. |
|
name: |
last-modified-by |
|
used by: |
server |
|
format/values: |
registrar handle |
|
description: |
Specifies the handle of the registrar who modified the object at last. |
|
name: |
list |
|
used by: |
client |
|
format/values: |
text string, containing either domains, contacts or hosts (case insensitive) |
|
description: |
Specifies on inquiries which referencing objects should be listed. |
|
name: |
lname |
|
used by: |
client, server |
|
format/values: |
text string, no more than 50 characters |
|
description: |
Specifies the last name of an individual. |
|
name: |
managing-registrar-id |
|
used by: |
server |
|
format/values: |
registrar handle |
|
description: |
Identifies the managing registrar of a domain, contact or host object |
|
name: |
notification-type |
|
used by: |
notification |
|
format/values: |
text string, containing either init-transfer, transfer—acknowledge or transfer-finish (case insensitive) |
|
description: |
Specifies the type of notification. |
|
name: |
ns1-host |
|
used by: |
client, server |
|
format/values: |
host handle |
|
description: |
Specifies the name servers of a domain. |
|
name: |
organization |
|
used by: |
client, server |
|
format/values: |
text string, no more than 50 characters |
|
description: |
Specifies the name of the organization. |
|
name: |
owner-contact |
|
used by: |
client |
|
format/values: |
contact handle |
|
description: |
Owner (of the domain). |
|
name: |
owner-contact-origin |
|
used by: |
server |
|
format/values: |
contact handle |
|
description: |
Identifies the origin of the owner data stored in the domain object. |
|
name: |
payload-version |
|
used by: |
client (the server does not use this key, since it always uses the same payload version as the client used in its request), notification |
|
format/values: |
N.M where N and M are positive numbers |
|
description: |
Specifies the version number of the payload. The payload specified in this document has the version number 1.1. |
|
name: |
period |
|
used by: |
client |
|
format/values: |
positive number indicating the number of years |
|
description: |
Specifies the registration period of a domain (or its extension). |
|
name: |
phone |
|
used by: |
client, server |
|
format/values: |
text string, containing a phone number |
|
description: |
Specifies a phone number |
|
name: |
postal-code |
|
used by: |
client, server |
|
format/values: |
text string, containing the postal code |
|
description: |
Specifies the postal code of the related city key. |
|
name: |
reg-admin-auth-key |
|
used by: |
client |
|
format/values: |
PGP key |
|
description: |
The public PGP key which the registrar uses for administration purposes. |
|
name: |
reg-admin-auth-key-info |
|
used by: |
server |
|
format/values: |
key related information in the form <param> = <value>
[ , <param>
= <value> ...] |
|
description: |
Additional information about the key |
|
name: |
reg-admin-auth-type |
|
used by: |
client |
|
format/values: |
must be pgp5 (case insensitive) |
|
description: |
The type of the cryptographic key specified with the corresponding reg-admin-auth-key. |
|
name: |
reg-admin-contact |
|
used by: |
client, server |
|
format/values: |
contact handle |
|
description: |
Contact handle of the registrar administration. |
|
name: |
reg-admin-permissions |
|
used by: |
server |
|
format/values: |
a comma-separated list of request types |
|
description: |
Specifies the allowed request types for the corresponding entity. |
|
name: |
reg-agent1-auth-key |
|
used by: |
client |
|
format/values: |
PGP key |
|
description: |
The public PGP key which the registrar’s staff uses for the daily work. |
|
name: |
reg-agent-auth-key-info |
|
used by: |
server |
|
format/values: |
key related information in the form <param> = <value>
[ , <param>
= <value> ...] |
|
description: |
Additional information about the key |
|
name: |
reg-agent1-auth-type |
|
used by: |
client |
|
format/values: |
must be pgp5 (case insensitive) |
|
description: |
The type of the cryptographic key specified with the corresponding reg-agentN-auth-key. |
|
name: |
reg-agent1-contact |
|
used by: |
client, server |
|
format/values: |
contact handle |
|
description: |
Contact handle of the registrar staff. |
|
name: |
reg-agent-permissions |
|
used by: |
server |
|
format/values: |
a comma-separated list of request types |
|
description: |
Specifies the allowed request types for the corresponding entity. |
|
name: |
reg-state |
|
used by: |
client, server |
|
format/values: |
one of active, suspended or defunct (case insensitive) |
|
description: |
The registrar’s state |
|
name: |
reg-super-auth-key |
|
used by: |
client |
|
format/values: |
PGP key |
|
description: |
The public PGP key of the registrar’s super contact. |
|
name: |
reg-super-auth-key-info |
|
used by: |
server |
|
format/values: |
key related information in the form <param> = <value>
[ , <param>
= <value> ...] |
|
description: |
Additional information about the key |
|
name: |
reg-super-auth-type |
|
used by: |
client |
|
format/values: |
must be pgp5 (case insensitive) |
|
description: |
The type of the cryptographic key specified with the corresponding reg-super-auth-key. |
|
name: |
reg-super-contact |
|
used by: |
client, server |
|
format/values: |
contact handle |
|
description: |
Contact handle of the registrar’s super contact. |
|
name: |
reg-super-permissions |
|
used by: |
server |
|
format/values: |
a comma-separated list of request types |
|
description: |
Specifies the allowed request types for the corresponding entity. |
|
name: |
registrar-id |
|
used by: |
client, server |
|
format/values: |
registrar handle |
|
description: |
This key identifies the registrar. The handle is assigned by the registry staff. |
|
name: |
request-transaction-id |
|
used by: |
server |
|
format/values: |
transaction identifier (see transaction-id key) |
|
description: |
The transaction identifier of a previously received request. This key is used in the reply of a query request. |
|
name: |
request-type |
|
used by: |
client |
|
format/values: |
The value consists of a sequence of words, separated by whitespace. A word is a sequence of the letters A to Z. The case of the words is irrelevant |
|
description: |
The request type specifies the action the server should perform on behalf of the client. |
|
name: |
request-state |
|
used by: |
server |
|
format/values: |
one of the following terms: pending, in-process, succeeded, failed |
|
description: |
Returns the processing state of a request. The meanings of the values are: pending the request has been received and is currently waiting to be processed in-process the request is being processed succeeded the request has been processed successfully. Changes were made according to the request failed the processing of the request failed. No changes, even not partially, were made |
|
name: |
response-type |
|
used by: |
server |
|
format/values: |
either ack or reply |
|
description: |
This key tells the client whether the response contains an intermediate confirmation of the reception of the request (acknowledge, ack) or the final result of the request (reply) |
|
name: |
state |
|
used by: |
client, server |
|
format/values: |
text string |
|
description: |
The state or territory where the contact is located in. |
|
name: |
submitted-before |
|
used by: |
client |
|
format/values: |
date |
|
description: |
Specifies the upper bound for the submission date of a request to be found by the query request. |
|
name: |
submitted-since |
|
used by: |
client |
|
format/values: |
date |
|
description: |
Specifies the lower bound for the submission date of a request to be found by the query request. |
|
name: |
success |
|
used by: |
server |
|
format/values: |
text string |
|
description: |
A human readable comment to the successful processing of a request. The string is meant for debugging purposes. The client should not attempt to parse the contents of this string. Therefore, no description of the various texts are given in this document. |
|
name: |
tech-contact |
|
used by: |
client, server |
|
format/values: |
contact handle |
|
description: |
Technical contact (of a domain). |
|
name: |
time-out-date |
|
used by: |
notification |
|
format/values: |
date |
|
description: |
The deadline until the server expects a reaction from the registrar. |
|
name: |
title |
|
used by: |
client, server |
|
format/values: |
text string, no more than 50 characters |
|
description: |
The title of the contact. |
|
name: |
title |
|
used by: |
server |
|
format/values: |
RCU value |
|
description: |
The balance of the registrar’s account. |
|
name: |
transaction-id |
|
used by: |
client, server |
|
format/values: |
may consist of a sequence of printable, non-whitespace characters, no less than one character and no more than forty characters |
|
description: |
The transaction identifier is generated by the client. It is not required, but strongly recommended that the identifier is registrar-unique, since the status request cannot return any information for multiply used transaction identifiers. |
|
name: |
transfer-approved |
|
used by: |
notification |
|
format/values: |
either Y or N (case insensitive) |
|
description: |
Specifies whether the loosing registrar approves (Y) or declines (N) the domain transfer. |
|
name: |
transaction-performed |
|
used by: |
notification |
|
format/values: |
either Y or N (case insensitive) |
|
description: |
Specifies whether the transfer has finally been performed (Y) or not (N). |
|
name: |
zone-contact |
|
used by: |
client, server |
|
format/values: |
contact handle |
|
description: |
Contact who is responsible for the maintenance of the DNS zone. |
|
-100 |
empty request |
|
-101 |
transaction-id not found |
|
-102 |
registrar-id not found or invalid |
|
-103 |
request-type not found or invalid |
|
-104 |
no permission to execute this request |
|
-105 |
field payload version not found or invalid |
|
-106 |
not enough credits for this request |
|
-107 |
duplicate key in request |
|
-108 |
no registrar-contact record found for registrar-id and PGP keyid |
|
-109 |
no registrar-handle record found or registrar-handle is invalid |
|
-110 |
value not found or invalid |
|
-111 |
mandatory key not found |
|
-112 |
value exceeds maximum field length |
|
-113 |
mandatory key can not be empty in modification request. |
|
-114 |
invalid top level domain name |
|
-117 |
value is not a valid date |
|
-118 |
host-handles must be unique for each domain |
|
-130 |
host cannot be deleted because of references to existing domains. |
|
-131 |
contact cannot be deleted because of references to existing objects. |
|
-150 |
not manager of this contact |
|
-151 |
illegal flag |
|
-160 |
domain name is already registered. |
|
-180 |
not manager of this domain |
|
-200 |
PGP key could not be added, maybe wrong format or invalid |
|
-201 |
PGP keyid is already in use for that registrar |
|
-251 |
reg-admin, reg-agent or reg-super key sets incomplete |
|
-270 |
no request with the given transaction-id exists |
|
-310 |
host-handle not found or invalid |
|
-311 |
not manager of this host |
|
-350 |
domain does not exist |
|
-351 |
domain is not scheduled for transfer |
|
-352 |
not owner of this transfer, permission denied |
|
-354 |
transfer for that domain is already in progress |
The domain transfer process involves three parties — the gaining registrar, the registry and the loosing registrar. Both registrars negotiate about the transfer, the registry only being the mediator in this process.
Steps in a domain transfer where the loosing registrar agrees to a transfer:
|
gaining registrar |
|
registry |
|
loosing registrar |
|
|
¾request® |
|
|
|
|
|
¬reply¾ |
registry checks whether domain exists and can be transferred |
¾notification® |
|
|
|
|
|
¬request¾ |
registrar determines whether customer wants to change registrar, agrees |
|
|
¬notification¾ |
registry checks whether process is still in progress |
|
|
|
registrar finishes process |
¾request® |
|
|
|
|
|
¬reply¾ |
registry performs changes and notifies loosing registrar |
¾notification® |
|
Steps in a domain transfer where the loosing registrar declines a transfer:
|
gaining registrar |
|
registry |
|
loosing registrar |
|
|
¾request® |
|
|
|
|
|
¬reply¾ |
registry checks whether domain exists and can be transferred |
¾notification® |
|
|
|
|
|
¬request¾ |
registrar determines whether customer wants to change registrar, declines |
|
|
¬notification¾ |
registry checks whether process is still in progress |
¾notification® |
|
Steps in a domain transfer where the gaining registrar aborts a transfer before the loosing registrar makes its decision:
|
gaining registrar |
|
registry |
|
loosing registrar |
|
|
¾request® |
|
|
|
|
|
¬reply¾ |
registry checks whether domain exists and can be transferred |
¾notification® |
|
|
registrar aborts process |
|
|
|
|
|
|
¾request® |
|
|
|
|
|
¬reply¾ |
registry aborts the process |
¾notification® |
|
Steps in a domain transfer where the gaining registrar aborts a transfer despite of an agreement of the loosing registrar:
|
gaining registrar |
|
registry |
|
loosing registrar |
|
|
¾request® |
|
|
|
|
|
¬reply¾ |
registry checks whether domain exists and can be transferred |
¾notification® |
|
|
|
|
|
¬request¾ |
registrar determines whether customer wants to change registrar, agrees |
|
|
¬notification¾ |
registry checks whether process is still in progress |
|
|
|
registrar aborts process |
¾request® |
|
|
|
|
|
¬reply¾ |
registry aborts the process |
¾notification® |
|
If the loosing registrar fails to respond upon the init-transfer notification before reaching the time-out date, the registry decides on behalf of the registrar, depending on the registry’s policy. The registry behaves as if it received a transfer domain request with either positive or negative transfer acknowledge.
If the gaining registrar fails to respond upon the transfer-acknowledge notification before reaching the time-out date, the registry behaves as if it received a transfer domain request with the abort-transfer action. Additionally, it sends a transfer-finish notification to the gaining registrar.
|
gaining registrar |
|
registry |
|
loosing registrar |
|
¾ ¾ same as above ¾ ¾ |
||||
|
|
¬notification¾ |
registry checks whether process is still in progress |
|
|
|
|
¬notification¾ |
registry aborts the process due to time-out |
¾notification® |
|
|
[PGP5] |
http://www.pgp.com |
|
[RFC822] |
RFC 822, Standard for the format of ARPA Internet text messages |
|
[RFC1035] |
RFC 1035, Domain names - implementation and specification |
|
[RFC1847] |
RFC 1847, Security Multiparts for MIME: Multipart/Signed andMultipart/Encrypted |
|
[RFC2015] |
RFC 2015, MIME Security with Pretty Good Privacy (PGP) |
|
[IANA-PORTS] |
http://www.isi.edu/in-notes/iana/assignments/port-numbers |
|
[ISO3166] |
http://userpage.chemie.fu-berlin.de/diverse/doc/ISO_3166.html |
|
CORE |
Council of Registrars |
|
CNO |
COM, NET and ORG (domains) |
|
registry |
the entity which operates the central database of registered domains (and additional data, eventually) |
|
registrar |
the entity which registers domains on behalf of customers and resellers |
|
request |
a message the client sends to the server |
|
response |
a message the server sends to the client |
|
reply |
the result of a request |
|
notification |
a message sent by the server to inform the registrar about an event or change of state; not directly related to a request |
|
message |
a data packet containing the payload and the digital signature |
[1] encryption was considered, but some countries (e.g. France) had a very restrictive policy on cryptography at that time
[2] there is one exception: the owner of a domain is stored in a copy, although he is also referenced by a handle. See the description of the domain object for details.
[3] this is any printable character except double quote " and backslash \
[4] this is any printable character except the colon :