The SRS protocol can be used by registrars for interacting with the SRS. Individual parts of the protocol are covered in depth below.
The specification of SRS and a description of the communication protocol used by the system is available in IETF I-D format but has not been accepted as an RFC:
System for Managing a Shared Domain Registry (Plain text) - draft-nzrs-srs-03
System for Managing a Shared Domain Registry (PDF) - draft-nzrs-srs-03
The protocol schema is available here:
- SRS Transactions
- Element and Attribute definitions
- SRS Registrar Information Kit (RIK)
The SRS protocol works in a connection-oriented fashion with no session state. The registrar sends a SRS XML request document to the SRS containing commands to be executed by the SRS and the result of processing these commands is returned as the response. Each registrar request document receives a response document containing the result of processing all of the requests in a single request document.
All communication with the SRS is performed using XML documents encoded in UTF−8 and sent using HTTP or HTTPS. The request body can contain multiple independent requests to be performed on the SRS. The response will include a response to each request in the XML document, or a single error response. The SRS will process the requests in the order that they are received in the request body.
All SRS XML transactions attempting to modify the data in the SRS or to retrieve data that is not deemed public, needs to be transmitted via HTTPS. If these transactions are sent via HTTP they will get rejected.
Registrars should ensure that:
- Requests in an XML document are ordered logically to prevent errors due to sequencing (for example, attempting to update a domain record before creating it)
- The number of requests per XML document is limited to ensure acceptable processing time and response size
Both request and response messages must be accompanied by a digital signature of the complete XML request body (See SRS Security for further details on signing requests).
The VerMajor and VerMinor attributes are required in the first element of each request and response to allow clients and servers to modify their behaviour dependent on the version of the protocol that they support.
The SRS server will reject any request made with a major version number that is greater than the SRS server’s own supported version.
HTTP Request Format¶
Requests must include three parameters in the HTTP POST request:
|n||The registry-assigned registrar identifier.|
|r||The XML request, encoded in UTF-8.|
|s||An OpenPGP-compatible signature of the XML request document, signed with the registrar’s private key. Presented in ASCII armoured format and encoded in UTF-8.|
Example request prior to encoding:
n=945&r= <NZSRSRequest VerMajor="6" VerMinor="7" RegistrarId="945"> <Whois DomainName="example.org" /> </NZSRSRequest>&s=-----BEGIN PGP SIGNATURE-----...
Responses include two parameters:
|r||The XML response, encoded in UTF-8.|
|s||An OpenPGP-compatible signature of the XML response document, signed with the registry’s private key. Presented in ASCII armoured format and encoded in UTF-8.|
Example response prior to encoding:
r=<?xml version="1.0" encoding="utf-8"?> <NZSRSResponse VerMajor="6" VerMinor="7" RegistrarId="50041"> <Response Action="Whois" FeId="4" FeSeq="137" OrigRegistrarId="50041" RecipientRegistrarId="50041" Rows="1"> <FeTimeStamp Year="2007" Month="10" Day="19" Hour="14" Minute="7" Second="51" TimeZoneOffset="+13:00" /> <Domain DomainName="example.org">...</Domain> </Response> </NZSRSResponse>&s=-----BEGIN PGP SIGNATURE-----...
For more information please see:
System for Managing a Shared Domain Registry (Plain text) - draft-nzrs-srs-03
The request and response signature mechanism provides a means of ensuring that messages have not been tampered with in transit. In addition to this, all requests for private data (data that cannot be retrieved using the public WHOIS system) must use an encrypted HTTP connection (HTTPS) for data security. If a request for private data is received via an unencrypted HTTP connection, the SRS server will return an error response.
Only the Whois request may be issued over an unencrypted HTTP connection.
The SRS API currently supports connections via:
SRS uses SSL certificates signed by the NZRS Certificate Authority chain. To validate connections to SRS you will need to install these in your root CA store.
Both request and response messages MUST be accompanied by a digital signature of the complete XML request body. The digital signature authentication method follows the specification in section 2.2 of OpenPGP Message Format [RFC4880] and MUST be encoded in ASCII Armour (see section 6.2 of [RFC4880]) for inclusion in the HTTP request. The SRS protocol is a signature−only application of OpenPGP.
You can find a wide range of PGP compatible software at the following sites:
Please note that it is your responsibility to licence the version you acquire.
More information is available in the following FAQ item: How do I generate a PGP key for use with SRS?.
The SRS protocol uses messages in an XML format for system requests and responses. All data values must be entity-escaped, and the file itself must be UTF-8 encoded.
The protocol is available in DTD, Relax NG and XSD. All three version are available in three RIK download packages.
The SRS XML request document must:
- Begin with an opening <NZSRSRequest> tag and end with a closing </NZSRSRequest> tag.
- Include a VerMajor attribute.
- Include a VerMinor attribute.
- Include a RegistrarId attribute.
- Include one or more request elements (transactions).
Transactions within a request are processed in the same order as they are received. Each transaction will be applied to the database separately and the failure of the one transaction will not directly affect the processing of any of the other transactions.
All transactions will be checked to ensure that:
- All data is supplied in a valid format.
- All update transactions contain a unique Action ID.
- All mandatory fields are supplied.
XML Request Definition¶
|<NZSRSRequest>||Yes||Encapsulates the file and references the current protocol standard.|
|VerMajor||Yes||Major version number of the protocol. This number only changes when major changes are made to the system that are not backward compatible with previous versions; for example, client/ server interface changes (changes to the protocol schema).|
|VerMinor||Yes||Minor version number of the protocol. This number changes for minor updates to the protocol that are backward compatible with previous versions with the same major version number.|
|RegistrarId||Yes||Registrar’s unique identifier provided by InternetNZ|
|<requestElements>||Yes||One or more request elements where <requestElements> can be <DomainCreate> <DomainUpdate> <HandleCreate> <HandleUpdate> <HandleDetailsQry> <Whois> <DomainDetailsQry> <ActionDetailsQry> <UDAIValidQry> <RegistrarUpdate> <RegistrarDetailsQry> <RegistrarAccountQry> <GetMessages> <AckMessage>|
Example XML Request:
<NZSRSRequest RegistrarId="999" VerMajor="5" VerMinor="10"> <Whois DomainName="internetnz.net.nz" FullResult="1" SourceIP="18.104.22.168"/> </NZSRSRequest>
Your SRS file must be UTF-8 encoded. Any data values must use entity escape codes for the characters listed below:
The SRS XML response document contains the same attributes as listed for the SRS XML Request above and contains either a transaction response for each transaction in the original request or a single error element if the request as a whole has failed.
The transaction response includes the following:
|VerMajor||The major version number of the SRS system|
|VerMinor||The minor version number of the SRS system|
|Action||name of the transaction that caused the response. Either actual transaction name, Domain Transfer (to notify ‘loosing’ registrar about transfer), Unknown Transaction (for various Error responses|
|ActionId||The identifier of the transaction that caused the response|
|MoreRowsAvailable||Only returned if ‘triggered’|
|RecipientRegistrarId||The registrar ID to which the response is posted|
|FeId||Identifier of the front end server that services the request|
|FeSeq||Identifier of the request instance on the front end server that serviced it|
|FeTimestamp||Time/date that the request instance was received on the front end server that serviced it|
|OrigRegistrarId||Identifier of the registrar that submitted the request|
|TransId||Identifier for the transaction if and as submitted by the initiator, either an ActionId or QryId|
<NZSRSResponse RegistrarId="90" VerMajor="5" VerMinor="7"> <Response Action="DomainCreate" FeId="8" FeSeq="20888439" OrigRegistrarId="90" RecipientRegistrarId="90" TransId="Unique Value 1234"> <FeTimeStamp Day="11" Hour="10" Minute="43" Month="3" Second="40" TimeZoneOffset="+13:00" Year="2011"/> <Domain Delegate="1" DomainName="internetnztest.co.nz" RegistrarId="90" Status="Active" Term="1" UDAI="SvmTxPXw"> <NameServers> <Server FQDN="ns1.internetnztest.co.nz" IP4Addr="22.214.171.124"/> <Server FQDN="ns2.internetnztest.co.nz" IP4Addr="126.96.36.199"/> </NameServers> <RegistrantContact Email="firstname.lastname@example.org" Name="John Smith"> <PostalAddress Address1="Level 9 Grand Arcade" Address2="Willis Street" City="Wellington" CountryCode="NZ" PostalCode="6001"/> <Phone AreaCode="4" CountryCode="64" LocalNumber="1234567"/> <Fax AreaCode="4" CountryCode="64" LocalNumber="1234567"/> </RegistrantContact> <AdminContact Email="email@example.com" Name="Admin Manager, InternetNZ Inc"> <PostalAddress Address1="Level 9 Grand Arcade" Address2="Willis Street" City="Wellington" CountryCode="NZ" PostalCode="6001"/> <Phone AreaCode="4" CountryCode="64" LocalNumber="1234567"/> <Fax AreaCode="4" CountryCode="64" LocalNumber="1234567"/> </AdminContact> <TechnicalContact Email="firstname.lastname@example.org" Name="Technical Manager, InternetNZ Inc"> <PostalAddress Address1="Level 9 Grand Arcade" Address2="Willis Street" City="Wellington" CountryCode="NZ" PostalCode="6001"/> <Phone AreaCode="4" CountryCode="64" LocalNumber="1234567"/> <Fax AreaCode="4" CountryCode="64" LocalNumber="1234567"/> </TechnicalContact> <BilledUntil Day="11" Hour="10" Minute="43" Month="3" Second="40" TimeZoneOffset="+13:00" Year="2012"/> <RegisteredDate Day="11" Hour="10" Minute="43" Month="3" Second="40" TimeZoneOffset="+13:00" Year="2011"/> <AuditDetails ActionId="Unique Value 1234" RegistrarId="1"> <AuditTime> <From Day="11" Hour="10" Minute="43" Month="3" Second="40" TimeZoneOffset="+13:00" Year="2011"/> </AuditTime> <AuditText><![CDATA[create new domain]]></AuditText> </AuditDetails> </Domain> </Response> </NZSRSResponse>
SRS Resource Manager¶
The Resource Manager component of the SRS is used to protect the SRS and to share the SRS resources equally between registrars. The Resource Manager monitors registrar transactions and if a registrar crosses certain thresholds (in terms of the number of requests they send each second, for example) then the SRS will begin to reject their requests until such time as they reduce the workload they are sending to the SRS.
A simple rate-limit has been imposed on each registrar that they may not send more than 15 requests per second. When the SRS detects that a registrar is sending more than 15 requests per second (as a “rolling average”) it will begin to reject their requests. It will then continue to reject all of their requests until the rolling average drops below the threshold.
SRS Resource Manager Headers¶
To assist registrars with managing their transaction request rates the SRS provides an additional HTTP response header as part of SRS communications. There is no requirement for registrars to use this header, however it does provide information to assist them in tuning their applications to get the best possible throughput from SRS.
The following is an example of the HTTP response header:
HTTP/1.1 200 OK Date: Mon, 12 Feb 2007 22:50:31 GMT Server: Apache X-resource-consent: RegistrarRequestLimit,2,15 Connection: close Content-Type: application/x-www-form-urlencoded
In this example you can see the RegistrarRequestLimit returned and has two values. The first value is the number of requests per second received at the front end and the second value is the current limit. So in this example we have a rate of 2 requests per second for this registrar and the limit is 15 requests per second.
An example of the XML error response returned if the rate is exceeded:
<NZSRSResponse VerMajor="1" VerMinor="38"> <Error ErrorId="CONSENT_ERROR" Hint="INVALID_REQUEST_ERROR" Severity="err"> <Description><![CDATA[Request denied due to resource limits being exceeded]]></Description> <ErrorDetails><![CDATA[RegistrarRequestLimit,17,15]]></ErrorDetails> </Error> </NZSRSResponse>
In this example you can see the RegistrarRequestLimit returned has a rate of 17 requests per second for this registrar and the limit is 15 requests per second.
The rate limit value is rounded down to the nearest whole number.