OT & E instructions and documentation are available in Become a Registrar.
- How do I begin the certification process?
- What do I do after I receive the OT&E welcome package?
- How do I test my client application?
- How do I arrange a time for OT&E certification?
- What will be tested during OT&E certification?
- What happens after OT&E certification?
- What is the name and port of the OT&E test server?
- What key or cert sizes are accepted ?
The OT&E certification process begins when the registry accepts a registrar's application. Tech Support will send you a welcome package. It will contain the following:
- OT&E server information and username/password for two accounts to access the OT&E environment for registrar client testing.
- Instructions on where to download the Registrar Toolkit.
- Instructions on where to download the RRP specifications.
- Instructions on how to proceed with the T&E certification process.
- Instructions on how to obtain an SSL certificate from an approved certificate authority.
- Instructions on how to provide Tech Support with the list of subnets that will be used to access the live Shared Registry System.
- Documentation that will explain the tests to be performed during OT&E verification.
Some of the above information is also available on this Web site.
The registrar is responsible for developing the client application that will interface with the registry using the EPP protocol. The Registrar Toolkit is available to any interested party that would like to develop Registrar client applications. A registrar may opt to develop their application to conform to the EPP specification without the use of the Registrar Toolkit. This is acceptable as long as the client is able to pass the OT&E certification process. In our version of the RTK we will be supplying open SSL support for our open SSL requirements.
The registry-registrar communication channel will be encrypted. A SSL certificate from an approved certificate authority is required to establish this encrypted channel. The registrar is responsible for acquiring the SSL
certificate and developing support for SSL in their client application. Please see the Security FAQ for details.
During client development, the registrar will have access to the OT&E environment. In the OT&E environment, the registrar may test the operation of their software to verify the correct handling of EPP commands and their responses. Operations performed in the OT&E environment will not be charged and will not have any impacts on the live Shared Registry System. Registrars will
continue to have access to the OT&E environment after certification, so that they may continue to test their software systems
When a registrar has completed the testing of their client systems and would like to proceed with OT&E certification, they should contact Technical Support to schedule a time slot. It is important to schedule your test quickly, as time
slots will be scheduled on a first-come, first-served basis.
At the scheduled time, the registrar should contact the Tech Support OT&E Team to initiate the certification.
During OT&E certification, a registrar's client application will be required to demonstrate the proper execution ofa variety of operations. Please see the OT&E Registrar Acceptance Criteria document for full details.
NOTE: Afilias and the Registry reserve the right to change the OT&E certification requirements as necessary.
To pass, the registrar must complete all aspects of the OT&E certification test without errors. Tech Support will provide the certification results in a timely manner and provide feedback for those registrars that failed to successfully complete the tests. Registrars may correct their systems and re-schedule for certification. Registrars will not be limited in the number of attempts at OT&E certification.
Upon successful OT&E certification, a new username/password is assigned and Tech Support will configure the live system to recognize the SSL certificate, username, and subnet blocks for the registrar. The registrar may start operation
when it has satisfied the financial requirements for going live.
The OT&E test server name and port will be provided to each registrars along with its OT&E account information.
The .IN registry currently supports private keys that are up to 2048 bits in length. We do not currently support 4096-bit keys.
- How does the Registry control access to the Shared Registry System?
- How do I specify the IP addresses that can access the SRS?
- What is a SSL Certificate?
- Where do I get a SSL Certificate?
- Which SSL toolkit should I use?
- Which cipher suites are accepted?
- When do I get the username/password for the production SRS?
Access to the Shared Registry System is restricted by three mechanisms:
- Access control to the production SRS is restricted by IP address filters.
- SSL encryption is required for the communication channels between the Registrar's client system and the OT&E and production systems.
- Authentication by means of a username and password is required for session establishment.
The SRS requires the correct combination of the three mechanisms for each registrar before access is granted.
The Registrar Data Form has a section where registrars may specify the IP subnets that will be accessing the production SRS. The specified subnets must conform to the following rules:
- A maximum of 3 IP subnets
- A maximum of 96 hosts between the three IP subnets
- The .IN Registry supports connections to the registry both by IPv6 or IPv4.
- Ranges for IPv4 must be written in CIDR format (e.g. 192.168.1.0/27 where the "/27" represents the length of the subnet). We cannot accept any ranges below a /26 range (i.e. /25, /24, etc). CIDR format dictates the number of hosts within each range. The ranges are as follows:
- /26 = 64 hosts
- /27 = 32 hosts
- /28 = 16 hosts
- /29 = 8 hosts
- /30 = 4 hosts
- /31 = 2 hosts
- /32 = 1 host
- Examples of valid IPv4 subnets include:
- One subnet of 64 hosts(e.g. 192.168.1.0/26)
- One subnet of 64 hosts and one subnet of 32 hosts or less (e.g. subnet #1 as 192.168.2.0/26, which represents 64 addresses 192.168.2.0 to 192.168.2.63; and subnet #2 as 192.168.3.0/27, which represents 32 addresses 192.168.3.0 to 192.168.3.31.
- Three subnets of 32 hosts or less (e.g. subnet #1 as 192.168.2.0/27, which represents 32 addresses 192.168.2.0 to 192.168.2.31; subnet #2 as 192.168.3.0/27, which represents 32 addresses 192.168.3.0 to 192.168.3.31; and subnet #3 as 192.168.4.0/27, which represents 32 addresses 192.168.4.0 to 192.168.4.31)
- Accepted ranges for IPv6 subnets include:
- /48 = 1,208,925,819,614,629,174,706,176 hosts
- /64 = 18,446,744,073,709,551,616 hosts
- /128 = 1 hosts
- Registrars may submit IPv6 subnets as they see wish, as long as the total number of both IPv4 and IPv6 subnets stay within the limit of 3. IPv6 subnets will count towards the registrars' connection limits in the registry system along with the IPv4 addresses.
- The specified subnets must fall on valid bit boundaries. For example, a subnet specified as 192.168.2.1/27 is not acceptable because ".1" is not a valid boundary for a /27 subnet. The following table defines the valid boundaries for each subnet length.
Length of Subnet Number of Hosts Boundaries /26 64 0,64,128,192 /27 32 0,32,64,96,128,160,192,224 /28 16 0,16,32,48,64,80,96,112,128, 144,160,176,192,208,224,240 /29 8 0,8,16,24,32,40,...,248 (in increments of 8) /30 4 0,4,8,12,16,20,...,252 (in increments of 4) /31 2 0,2,4,6,8,12,...,254 (in increments of 2) /32 1 0 through 255 (in increments of 1)
- As a cautionary note, Registrars who currently have dual stack hosts may be affected (i.e if their network interface is configured with a global unicast IPv6 address, along with an IPv4 address). When dual stack registrars try to connect to the .IN registry, the IPv6 address will usually be selected over the IPv4 address for the connection. If you have not submitted your IPv6 address to Technical Support for inclusion in the list of allowed IPs for your registrar, the registry will refuse a connection and your client will be unable to establish a connection with the registry. You may implement RFC 6555 in your client to address this issue. This mechanism is currently included in the Mac operating system after the Mac OS X Lion Release and may be included at the Operating System level in Linux and Windows in the future.
A digital certificate is simply a statement digitally signed by an independent and trusted third party (the Certificate Authority). That statement usually follows a very specific format laid down in a standard called X.509, hence they are sometimes referred to as X.509 certificates.
A certificate is required to establish an authenticated and encrypted communications channel between the Registrar's server and the Registry's SRS.
Where do I get a SSL Certificate?
X.509 server certificates can be obtained from one of the accepted Certificate Authorities. Please make sure you obtain an SSL server certificate and NOT an individual/personal certificate. The accepted Certificate Authorities currently include Verisign, Thawte and Starfield; qualified Indian government entities may use certificates issued by NIC. We are happy to consider use of certificates from an offical Indian Certifying Authority. If you would like to use a certificate from an authority that is not on this list, please contact us so that we can evaluate and test the certificate.
Registrars are responsible for obtaining an SSL toolkit that is compatible with the development language and platform of their client system. The minimum requirement is that it must support SSL version 3.
For C, C++ or Perl, OpenSSL is an
open-source SSL solution.
- Sun's Java Secure Socket Extension
- SSLava from Phaos Technology (Oracle). SSLava is also the toolkit used in the development of the SRS.
To establish a SSL connection to the SRS, the Registrar's client system must choose a cipher suite supported by the SRS. The SRS supports the following ciphers:
- SSL_DHE_RSA_WITH_DES _CBC_SHA
The username and password for the production SRS is issued after you have successfully completed OT&E certification and have completed funding.
Details about the software development kit is currently available in Become a Registrar.
- What is the Registrar Tool Kit?
- What is included in the Tool Kit?
- When will the Tool Kit be available and what are the licensing terms?
The Registrar Tool Kit is a software development kit that will support the development of a registrar software system for registering Internet domain names in the registry using the EPP registry-registrar protocol.
The Registrar Tool Kit consists of software and documentation as described below.
The software will consist of a working Java API and Java and Perl samples that can be used to implement the EPP protocol used to communicate between the registry and the registrar. The samples will illustrate how XML requests (registration events) can be assembled and forwarded to the registry for processing. The software will provide the registrar with the basis for a reference implementation that conforms to the Registry-Registrar Protocol. The software component of the Tool Kit will be based on static XML requests.
The documentation will explain to the registrar the details of the protocol specification. It will describe the commands that need to be sent to the registry in order to support domain registration events, as well as the possible responses that may be returned by the registry. The precise nature of the sequencing of commands, as well as the payload that must be assembled and transmitted to the registry, will be defined for each possible registration event.
The documentation will also describe the sample software that implements the EPP registry-registrar protocol. This will consist of a description of the software package hierarchy, and an explanation of the defined objects and methods (including calling parameter lists, and expected response behavior).
The toolkit is available now. Terms are included in the development kit available in Step 3.