Back

26 Whois

gTLDFull Legal NameE-mail suffixDetail
.saxoSaxo Bank A⁄Ssaxobank.comView
We have engaged ARI Registry Services (ARI) to deliver services for this TLD. ARI provide registry services for a number of TLDs including the .au ccTLD. For more background information on ARI please see the attachment ‘Q26 – ARI Background & Roles.pdf’. This response describes the WhoIs interface as implemented by ARI.

1 INTRODUCTION

ARI’s WhoIs service is for all domain names, contacts, nameservers and Registrars provisioned in the registry database. This response describes the port 43 and web interfaces of WhoIs, security controls to mitigate abuse, compliance with bulk access requirements for registration data, and the architecture delivering the service.

2 PORT 43 WHOIS SERVICE

WhoIs is on TCP port 43 in accordance with RFC3912. Requests are made in semi-free text format and ended by CR & LF. The server responds with a semi-free text format, terminating the response by connection close.
To support IDNs and Localised data we assume the query is encoded in UTF-8 and sends responses encoded in UTF-8. UTF-8 is backwards compatible with the ASCII charset and its use is consistent with the IETF policy on charsets as defined in BCP 18 [http:⁄⁄tools.ietf.org⁄html⁄bcp18].

2.1 Query Format
By default WhoIs searches domains. To facilitate the queries of other objects keywords must be used. Supported keywords are:
– Domain
– Host⁄Nameserver
– Contact
– Registrar
Keywords are case-insensitive. The rest of the input is the search string. Wildcard chars may be used in search strings to match zero or more chars (%), or match exactly one char(_). Wildcard chars must not be in the first 5 chars.

2.2 Response Format
The response follows a semi-structured format of object-specific data, followed by query-related meta-information, then a disclaimer.
The object-specific data is represented by key⁄value pairs, beginning with the key, followed by a colon and a space then the value terminated by an ASCII CR & LF. Where no object is found ‘No Data Found’ is returned.
The meta-information is used to identify data freshness and indicate when limits have been exceeded. It appears on one line within ‘〉〉〉’ and ‘〈〈〈’ chars.
The legal disclaimer is presented without leading comment marks wrapped at 72 chars. This format is consistent with that in the registry agreement.

2.3 Domain Data
Domain data is returned in response to a query with the keyword omitted, or with the ‘domain’ keyword. Domain queries return information on domains that are provisioned in the registry database.
The IDN domains may be specified in either the ASCII-compatible encoded form or the Unicode form. Clients are expected to perform any mappings, in conformance with relevant guidelines such as those specified in RFC5894 and UTS46.
Variant domains may be specified in the search string and WhoIs will match (using case-insensitive comparison) and return information for the primary registered domain.
For queries containing wildcard chars, if only one domain name is matched its details are returned, if more than one domain name is matched then the first 50 matched domain names are listed.

2.3.1 Internationalised Domain Names
The WhoIs response format, prescribed in Specification 4, does not provide a mechanism to identify active variant domain names. ARI will include active variant domain names in WhoIs responses until a common approach for handling and display of variant names is determined.

2.3.2 Reserved Domain Names
Domain names reserved from allocation will have a specific response that indicates the domain is not registered but also not available.

2.4 Nameserver Data
Nameserver data is returned in response to a query where the ‘nameserver’ or ‘host’ keywords have been used. Nameserver queries return information on hosts that are provisioned in the registry.
The search string for a nameserver query can be either a hostname or IP. Queries using the hostname produce one result unless wildcards are used. Queries using the IP produce one or more results depending on the number of hostnames that match that address. Queries for the hostname are matched case-insensitively.
The quad-dotted notation is expected for IPv4 and the RFC3513 – IPv6 Addressing Architecture format for IPv6. Wildcards cannot be used for IP queries.

2.5 Contact Data
Contact data is returned in response to a query where the ‘contact’ keyword was used. Contact queries return information on contacts that are provisioned in the registry.
The search string for a contact query is the contact identifier. Contact identifiers are matched using a case-insensitive comparison. Wildcards cannot be used.

2.6 Registrar Data
Registrar data is returned in response to a query where the ‘Registrar’ keyword was used. Registrar queries return information on Registrar objects that are provisioned in the registry.
The search string for a Registrar query can be name or IANA ID. Queries using the name or the IANA ID produce only one result. Queries for the name are matched using a case-insensitive comparison. Wildcards cannot be used.

2.7 Non-standard Data
The SRS supports domain-related data beyond that above. It may include information used to claim eligibility to participate in the sunrise process, or other arbitrary data collected using the Key-Value Mapping to the EPP. This information will be included in the WhoIs response after the last object-specific data field and before the meta-information.

3 WEB-BASED WHOIS SERVICE

WhoIs is also available via port 80 using HTTP, known as Web-based WhoIs. This interface provides identical query capabilities to the port 43 interface via an HTML form.

4 SECURITY CONTROLS

WhoIs has an in-built mechanism to blacklist malicious users for a specified duration. Blacklisted users are blocked by source IP address and receive a specific blacklisted notification instead of the normal WhoIs response.
Users may be blacklisted if ARI’s monitoring system determines excessive use. A whitelist is used to facilitate legitimate use by law enforcement agencies and other reputable entities.

5 BULK ACCESS

The registry system complies with the requirements for the Periodic Access to Thin Registration Data and Exceptional Access to Thick Registration Data as described in Specification 4.

5.1 Periodic Access to Thin Registration Data
ARI shall provide ICANN with Periodic Access to Thin Registration Data. The data will contain the following elements as specified by ICANN. The format of the data will be consistent with the format specified for Data Escrow. The Escrow Format prescribes an XML document encoded in UTF-8. The generated data will be verified to ensure that it is well formed and valid.
The data will be generated every Monday for transactions committed up to and on Sunday unless otherwise directed by ICANN. The generated file will be made available to ICANN using SFTP. Credentials, encryption material, and other parameters will be negotiated between ARI and ICANN using an out-of-band mechanism.

5.2 Exceptional Access to Thick Registration Data
If requested by ICANN, ARI shall provide exceptional access to thick registration data for a specified Registrar. The date will contain full information for the following objects:
– Domain names sponsored by the Registrar
– Hosts sponsored by the Registrar
– Contacts sponsored by the Registrar
– Contacts linked from domain names sponsored by the Registrar
As above the format of the data will be consistent with the format specified for Data Escrow. And will be made available to ICANN using SFTP.

6 CAPACITY

ARI’s WhoIs infrastructure is built to sustain 20M domain names. Based on ARI’s experience running a high volume ccTLD registry (.au) and industry analysis, ARI were able to calculate the conservative characteristics of a registry of this size.
Through conservative statistical analysis of the .au registry and data presented in the May 2011 ICANN reports for the .com & .net, .org, .mobi, .info, .biz and .asia [http:⁄⁄www.icann.org⁄en⁄resources⁄registries⁄reports] we know there is:
– An average of 30 SRS txs per domain, per month.
Which indicates an expected monthly transaction volume of 600M txs?
Through statistical analysis of the .au registry and backed up by the data published in the .net RFP responses [http:⁄⁄archive.icann.org⁄en⁄tlds⁄net-rfp⁄net-rfp-public-comments.htm] we also know:
– The peak daily transactions is 6% of the monthly total
– The peak 5 min is 5% of the peak day
Thus we expect a peak WhoIs tx rate of WhoIs 6,000 TPS.
For perspective on the conservativeness of this, the following numbers were taken from data in the May 2011 ICANN reports referenced above:
– .info ~7.8M domain names, peaks at ~1,300 TPS (projected peak TPS of ~3,400 with 20M names).
– .mobi ~1M domain names, peaks at ~150 TPS (projected peak TPS of ~3,000 TPS with 20M names).
– .org ~9.3M domain names, peaks at ~1,300 TPS (projected peak TPS of ~2,800 with 20M names).
ARI understand the limitations of these calculations but they serve as a best estimate of probable transaction load. ARI has built overcapacity of resources to account for limitations of this method, however as conservative numbers were used and these are greater than real world observations, we are confident these capacity numbers are sufficient.
ARI benchmarked their WhoIs infrastructure and used the results to calculate the required computing resources for each of the tiers within the WhoIs architecture – allowing ARI to accurately estimate the required CPU, IOPS, storage and memory requirements for each server within the architecture, as well as the network bandwidth and packet throughput requirements for the anticipated WhoIs traffic. These capacity numbers were then doubled to account for unanticipated traffic spikes, errors in predictions and head room for growth. The technical resource allocations are explored in question 32.
This TLD is projected to reach 6000 domains at its peak volume and will generate 1,8 WhoIs transactions per second. This will consume 0,03 % of the resources of the WhoIs infrastructure. As is evident ARI’s WhoIs can easily accommodate this TLD’s growth plans. See attachment ‘Q26 – Registry Scale Estimates & Resource Allocation.xlsx’ for more information.
ARI expects to provide Registry services to 100 TLDs and a total of 12M domains by end of 2014. With all the TLDs and domains combined, ARI’s WhoIs infrastructure will be only 60% utilized. The WhoIs infrastructure capacity can also be easily scaled as described in question 32

7 ARCHITECTURE

WhoIs uses a database separate from the SRS database as it operates from the secondary site such that network and database resources are decoupled from the operation of the SRS. Oracle Data Guard ensures the two databases are synchronised in real-time. The WhoIs service is operated live from the SRS ‘failover’ site, with the SRS ‘primary’ site serving as the ‘failover’ site for the WhoIs service. Both sites have enough capacity to run both services simultaneously, however by separating them, in normal operating modes headroom above the already over provisioned capacity is available. The architecture and data flow diagrams are described below and shown in the attachment ‘Q26 – WhoIs.pdf’.
Traffic enters the network from the Internet through border routers and then firewalls. All traffic destined for this service except for TCP ports 43, 80 & 443 is blocked. Load balancers forward the request to one of the application servers running ARI built WhoIs software. Each server is connected to the database cluster through another firewall further restricting access to the. Each server uses a restricted Oracle user that has read only access to the registry data and can only access the data that is relevant to the WhoIs queries. This ensures that in the unlikely event of an application server compromise the effects are limited.
All components are configured and provisioned to provide N+1 redundancy. Multiple Internet providers with separate upstream bandwidth suppliers are used. At least one additional component of all hardware exists, enabling maintenance without downtime. This configuration provides a service exceeding the availability requirements in Specification 10.
The use of load balancing allows addition of application servers with no downtime. From a database perspective, the ability to scale is enabled by utilising Oracle RAC database clustering. The entire service, including routers, firewalls and application is IPv6 compatible and WhoIs is offered on both IPv4 and IPv6. Detail about this architecture is available in our response to Question 32.

7.1 Synchronisation
The WhoIs database is synchronised with the SRS database using Oracle Data Guard. Committed transactions in the SRS database are reflected in the WhoIs database in real-time. Should synchronisation break, WhoIs continues to operate with the latest available data until the issue is reconciled. The channel between the two sites consists of two independent dedicated point to point links as well as the Internet. Replication traffic flows via the dedicated links or if both links fail replication traffic flows over Internet tunnels.

7.2. Interconnectivity with Other Services
The WhoIs service is not directly interconnected with other registry services or systems. The software has been developed to provide the WhoIs service exclusively and retrieve response information from a database physically separate to the SRS transactional database. This database is updated as described in ‘Synchronisation’ above. Although for smaller system the WhoIs and SRS can be configured to use the same data store. The WhoIs servers log every request to a central repository that is logically separate from the WhoIs database. This repository is used for query counts, detection of data mining and statistical analysis on query trends.

7.3 IT and Infrastructure Resources
The WhoIs service is provided utilizing Cisco networking equipment, IBM servers & SAN. They are described in the attachment ‘Q26 – WhoIs.pdf’. For more information on the architecture including server specifications and database capabilities please see Questions 32 & 33.

8 COMPLIANCE

Compliance with WhoIs RFCs is achieved through design and QA. The WhoIs interface was designed to conform to the RFCs as documented and independent test cases have been developed.
QA processes provide confidence that any changes to the service don’t result in regression of the WhoIs. Automated build processes execute test suites that ensure every facet of the WhoIs service (including malformed input, commands sequencing and synchronisation, and boundary values) is covered and compliant with RFCs. These tests are executed prior to the committing of code and nightly. The final deliverable is packaged and tested again to ensure no defects were introduced in the packaging of the software.
New versions of the WhoIs follow a deployment schedule. The new version is deployed into an OT&E environment for Registrar integration testing. Registrars who rely on WhoIs functionality are encouraged during this stage to test their systems operate without change. After a fixed time in OT&E without issue, new versions are scheduled for production deployment. This ensures incompatibilities with RFCs that made it through QA processes are detected in test environments prior to reaching production.
ARI is committed to providing a WhoIs service that integrates with third party tools and as such tests are conducted using these tools such as jWhoIs, a popular UNIX command line WhoIs client. Any issues identified during integration fall into 1 of the following categories:
– Third-party tool not compliant with the WhoIs specification
– WhoIs service not compliant
– Both third-party tool and WhoIs service are compliant, however another operational issue causes a problem
Defects are raised and follow the change management. Change requests may also be raised to promote integration of third-party tools and to meet common practice.

9 RESOURCES

This function will be performed by ARI. The WhoIs system is supported by a number of ARI departments:
– Products and Consulting Team (7 staff)
– Production Support Group (27 staff)
– Development Team (11 staff)
– Legal, Abuse and Compliance Team (6 staff)
A detailed list of the departments, roles and responsibilities in ARI is provided as attachment ‘Q26 – ARI Background & Roles.pdf’. This attachment describes the functions of the above teams and the exact number and nature of staff within.
The number of resources required to design, build, operate and support the SRS does not vary significantly with, and is not linearly proportional to, the number or size of TLDs that ARI provides registry services to.
ARI provides registry backend services to 5 TLDs and has a wealth of experience in estimating the number of resources required to support a registry system.
Based on past experience ARI estimates that the existing staff is adequate to support a registry system that supports in excess of 50M domains. Since this TLD projects 6000 domains, 0,01% of these resources are allocated to this TLD. See attachment ‘Q26 – Registry Scale Estimates & Resource Allocation.xlsx’ for more information.
ARI protects against loss of critical staff by employing multiple people in each role. Staff members have a primary role plus a secondary role for protection against personnel absence. Additionally ARI can scale resources as required. Additional trained resources can be added to any of the above teams with a 2 month lead time.
The products and consulting team is responsible for product management of the WhoIs solution including working with clients and the industry to identify new features or changes required to the system. The team consists of:
– 1 Products and Consulting Manager
– 1 Product Manager
– 1 Technical Product Manager
– 4 Domain Name Industry Consultants
ARI employ a development team responsible for the maintenance and continual improvement of the WhoIs software. The team consists of:
– 1 Development Manager
– 2 Business Analysts
– 6 Developers
– 2 Quality Analysts
ARI’s Production Support Team ensures the successful operation of the WhoIs system. The team comprises Database Administrators, Systems Administrators and Network Administrators. This team routinely checks and monitors bandwidth, disk and CPU usages to plan and respond to expected increases in the volume of queries, and perform maintenance of the system including security patches and failover and recovery testing. The team consists of:
– Production Support Manager
– Service Desk:
– 1 Level 1 Support Team Lead
– 8 Customer Support Representatives (Level 1 support)
– 1 Level 2 Support Team Lead
– 4 Registry Specialists (Level 2 support)
– Operations (Level 3 support)
– 1 Operations Team Lead
– 2 Systems Administrators
– 2 Database Administrators
– 2 Network Engineers
– Implementation
– 1 Project Manager
– 2 Systems Administrators
– 1 Database Administrators
– 1 Network Engineers
ARI’s registry provides abuse monitoring detection mechanisms to block data mining. ARI support staff may be contacted to remove blacklisted users during which they may be referred to the Legal, Abuse and Compliance Team for evaluation of their activities. Additionally the support team in conjunction with the Legal, Abuse and Compliance team administer requests for listing on the whitelist. The team consists of:
– 1 Legal Manager
– 1 Legal Counsel
– 4 Policy Compliance Officers
These resources sufficiently accommodate the needs of this TLD, and are included in ARI’s fees as described in our Financial responses.

gTLDFull Legal NameE-mail suffixDetail
.appTRI Ventures, Inc.litl.comView
We have engaged ARI Registry Services (ARI) to deliver services for this TLD. ARI provide registry services for a number of TLDs including the .au ccTLD. For more background information on ARI please see the attachment ‘Q26 – ARI Background & Roles.pdf’. This response describes the WhoIs interface as implemented by ARI.


1 INTRODUCTION

ARI’s WhoIs service is for all domain names, contacts, nameservers and Registrars provisioned in the registry database. This response describes the port 43 and web interfaces of WhoIs, security controls to mitigate abuse, compliance with bulk access requirements for registration data, and the architecture delivering the service.


2 PORT 43 WHOIS SERVICE

WhoIs is on TCP port 43 in accordance with RFC3912. Requests are made in semi-free text format and ended by CR & LF. The server responds with a semi-free text format, terminating the response by connection close.

To support IDNs and Localised data we assume the query is encoded in UTF-8 and sends responses encoded in UTF-8. UTF-8 is backwards compatible with the ASCII charset and its use is consistent with the IETF policy on charsets as defined in BCP 18 [http:⁄⁄tools.ietf.org⁄html⁄bcp18].


2.1 QUERY FORMAT

By default WhoIs searches domains. To facilitate the queries of other objects keywords must be used. Supported keywords are:
– Domain
– Host⁄Nameserver
– Contact
– Registrar

Keywords are case-insensitive. The rest of the input is the search string. Wildcard chars may be used in search strings to match zero or more chars (%), or match exactly one char(_). Wildcard chars must not be in the first 5 chars.


2.2 RESPONSE FORMAT

The response follows a semi-structured format of object-specific data, followed by query-related meta-information, then a disclaimer.

The object-specific data is represented by key⁄value pairs, beginning with the key, followed by a colon and a space then the value terminated by an ASCII CR & LF. Where no object is found ‘No Data Found’ is returned.

The meta-information is used to identify data freshness and indicate when limits have been exceeded. It appears on one line within ‘〉〉〉’ and ‘〈〈〈’ chars.
The legal disclaimer is presented without leading comment marks wrapped at 72 chars. This format is consistent with that in the registry agreement.


2.3 DOMAIN DATA

Domain data is returned in response to a query with the keyword omitted, or with the ‘domain’ keyword. Domain queries return information on domains that are provisioned in the registry database.
The IDN domains may be specified in either the ASCII-compatible encoded form or the Unicode form. Clients are expected to perform any mappings, in conformance with relevant guidelines such as those specified in RFC5894 and UTS46.

Variant domains may be specified in the search string and WhoIs will match (using case-insensitive comparison) and return information for the primary registered domain.
For queries containing wildcard chars, if only one domain name is matched its details are returned, if more than one domain name is matched then the first 50 matched domain names are listed.


2.3.1 INTERNATIONALISED DOMAIN NAMES

The WhoIs response format, prescribed in Specification 4, does not provide a mechanism to identify active variant domain names. ARI will include active variant domain names in WhoIs responses until a common approach for handling and display of variant names is determined.


2.3.2 RESERVED DOMAIN NAMES

Domain names reserved from allocation will have a specific response that indicates the domain is not registered but also not available.


2.4 NAMESERVER DATA

Nameserver data is returned in response to a query where the ‘nameserver’ or ‘host’ keywords have been used. Nameserver queries return information on hosts that are provisioned in the registry.
The search string for a nameserver query can be either a hostname or IP. Queries using the hostname produce one result unless wildcards are used. Queries using the IP produce one or more results depending on the number of hostnames that match that address. Queries for the hostname are matched case-insensitively.
The quad-dotted notation is expected for IPv4 and the RFC3513 – IPv6 Addressing Architecture format for IPv6. Wildcards cannot be used for IP queries.


2.5 CONTACT DATA

Contact data is returned in response to a query where the ‘contact’ keyword was used. Contact queries return information on contacts that are provisioned in the registry.
The search string for a contact query is the contact identifier. Contact identifiers are matched using a case-insensitive comparison. Wildcards cannot be used.


2.6 REGISTRAR DATA

Registrar data is returned in response to a query where the ‘Registrar’ keyword was used. Registrar queries return information on Registrar objects that are provisioned in the registry.
The search string for a Registrar query can be name or IANA ID. Queries using the name or the IANA ID produce only one result. Queries for the name are matched using a case-insensitive comparison. Wildcards cannot be used.


2.7 NON-STANDARD DATA

The SRS supports domain-related data beyond that above. It may include information used to claim eligibility to participate in the sunrise process, or other arbitrary data collected using the Key-Value Mapping to the EPP. This information will be included in the WhoIs response after the last object-specific data field and before the meta-information.



3 WEB-BASED WHOIS SERVICE

WhoIs is also available via port 80 using HTTP, known as Web-based WhoIs. This interface provides identical query capabilities to the port 43 interface via an HTML form.



4 SECURITY CONTROLS

WhoIs has an in-built mechanism to blacklist malicious users for a specified duration. Blacklisted users are blocked by source IP address and receive a specific blacklisted notification instead of the normal WhoIs response.

Users may be blacklisted if ARI’s monitoring system determines excessive use. A whitelist is used to facilitate legitimate use by law enforcement agencies and other reputable entities.



5 BULK ACCESS

The registry system complies with the requirements for the Periodic Access to Thin Registration Data and Exceptional Access to Thick Registration Data as described in Specification 4.


5.1 PERIODIC ACCESS TO THIN REGISTRATION DATA

ARI shall provide ICANN with Periodic Access to Thin Registration Data. The data will contain the following elements as specified by ICANN. The format of the data will be consistent with the format specified for Data Escrow. The Escrow Format prescribes an XML document encoded in UTF-8. The generated data will be verified to ensure that it is well formed and valid.

The data will be generated every Monday for transactions committed up to and on Sunday unless otherwise directed by ICANN. The generated file will be made available to ICANN using SFTP. Credentials, encryption material, and other parameters will be negotiated between ARI and ICANN using an out-of-band mechanism.


5.2 EXCEPTIONAL ACCESS TO THICK REGISTRATION DATA

If requested by ICANN, ARI shall provide exceptional access to thick registration data for a specified Registrar. The date will contain full information for the following objects:
– Domain names sponsored by the Registrar
– Hosts sponsored by the Registrar
– Contacts sponsored by the Registrar
– Contacts linked from domain names sponsored by the Registrar

As above the format of the data will be consistent with the format specified for Data Escrow. And will be made available to ICANN using SFTP.



6 CAPACITY

ARI’s WhoIs infrastructure is built to sustain 20M domain names. Based on ARI’s experience running a high volume ccTLD registry (.au) and industry analysis, ARI were able to calculate the conservative characteristics of a registry of this size.

Through conservative statistical analysis of the .au registry and data presented in the May 2011 ICANN reports for the .com & .net, .org, .mobi, .info, .biz and .asia [http:⁄⁄www.icann.org⁄en⁄resources⁄registries⁄reports] we know there is:
– An average of 30 SRS txs per domain, per month.
Which indicates an expected monthly transaction volume of 600M txs.
Through statistical analysis of the .au registry and backed up by the data published in the .net RFP responses [http:⁄⁄archive.icann.org⁄en⁄tlds⁄net-rfp⁄net-rfp-public-comments.htm] we also know:
– The peak daily transactions is 6% of the monthly total
– The peak 5 min is 5% of the peak day
Thus we expect a peak WhoIs tx rate of WhoIs 6,000 TPS.
For perspective on the conservativeness of this, the following numbers were taken from data in the May 2011 ICANN reports referenced above:
– .info ~7.8M domain names, peaks at ~1,300 TPS (projected peak TPS of ~3,400 with 20M names).
– .mobi ~1M domain names, peaks at ~150 TPS (projected peak TPS of ~3,000 TPS with 20M names).
– .org ~9.3M domain names, peaks at ~1,300 TPS (projected peak TPS of ~2,800 with 20M names).

ARI understand the limitations of these calculations but they serve as a best estimate of probable transaction load. ARI has built overcapacity of resources to account for limitations of this method, however as conservative numbers were used and these are greater than real world observations, we are confident these capacity numbers are sufficient.

ARI benchmarked their WhoIs infrastructure and used the results to calculate the required computing resources for each of the tiers within the WhoIs architecture – allowing ARI to accurately estimate the required CPU, IOPS, storage and memory requirements for each server within the architecture, as well as the network bandwidth and packet throughput requirements for the anticipated WhoIs traffic. These capacity numbers were then doubled to account for unanticipated traffic spikes, errors in predictions and head room for growth. The technical resource allocations are explored in question 32.

This TLD is projected to reach 3,664 domains at its peak volume and will generate 1.09 WhoIs transactions per second. This will consume 0.02% of the resources of the WhoIs infrastructure. As is evident ARI’s WhoIs can easily accommodate this TLD’s growth plans. See attachment ‘Q26 – Registry Scale Estimates & Resource Allocation.xlsx’ for more information.

ARI expects to provide Registry services to 100 TLDs and a total of 12M domains by end of 2014. With all the TLDs and domains combined, ARI’s WhoIs infrastructure will be only 60% utilized. The WhoIs infrastructure capacity can also be easily scaled as described in question 32



7 ARCHITECTURE

WhoIs uses a database separate from the SRS database as it operates from the secondary site such that network and database resources are decoupled from the operation of the SRS. Oracle Data Guard ensures the two databases are synchronised in real-time. The WhoIs service is operated live from the SRS ‘failover’ site, with the SRS ‘primary’ site serving as the ‘failover’ site for the WhoIs service. Both sites have enough capacity to run both services simultaneously, however by separating them, in normal operating modes headroom above the already over provisioned capacity is available. The architecture and data flow diagrams are described below and shown in the attachment ‘Q26 – WhoIs.pdf’.

Traffic enters the network from the Internet through border routers and then firewalls. All traffic destined for this service except for TCP ports 43, 80 & 443 is blocked. Load balancers forward the request to one of the application servers running ARI built WhoIs software. Each server is connected to the database cluster through another firewall. Each server uses a restricted Oracle user that has read only access to the registry data and can only access the data that is relevant to the WhoIs queries. This ensures that in the unlikely event of an application server compromise the effects are limited.

All components are configured and provisioned to provide N+1 redundancy. Multiple Internet providers with separate upstream bandwidth suppliers are used. At least one additional component of all hardware exists, enabling maintenance without downtime. This configuration provides a service exceeding the availability requirements in Specification 10.

The use of load balancing allows addition of application servers with no downtime. From a database perspective, the ability to scale is enabled by utilising Oracle RAC database clustering. The entire service, including routers, firewalls and application is IPv6 compatible and WhoIs is offered on both IPv4 and IPv6. Detail about this architecture is available in our response to Question 32.


7.1 SYNCHRONISATION

The WhoIs database is synchronised with the SRS database using Oracle Data Guard. Committed transactions in the SRS database are reflected in the WhoIs database in real-time. Should synchronisation break, WhoIs continues to operate with the latest available data until the issue is reconciled. The channel between the two sites consists of two independent dedicated point to point links as well as the Internet. Replication traffic flows via the dedicated links or if both links fail replication traffic flows over Internet tunnels.


7.2. INTERCONNECTIVITY WITH OTHER SERVICES

The WhoIs service is not directly interconnected with other registry services or systems. The software has been developed to provide the WhoIs service exclusively and retrieve response information from a database physically separate to the SRS transactional database. This database is updated as described in ‘Synchronisation’ above. Although for smaller system the WhoIs and SRS can be configured to use the same data store. The WhoIs servers log every request to a central repository that is logically separate from the WhoIs database. This repository is used for query counts, detection of data mining and statistical analysis on query trends.


7.3 IT AND INFRASTRUCTURE RESOURCES

The WhoIs service is provided utilizing Cisco networking equipment, IBM servers & SAN. They are described in the attachment ‘Q26 – WhoIs.pdf’. For more information on the architecture including server specifications and database capabilities please see Questions 32 & 33.



8 COMPLIANCE

Compliance with WhoIs RFCs is achieved through design and QA. The WhoIs interface was designed to conform to the RFCs as documented and independent test cases have been developed.

QA processes provide confidence that any changes to the service don’t result in regression of the WhoIs. Automated build processes execute test suites that ensure every facet of the WhoIs service (including malformed input, commands sequencing and synchronisation, and boundary values) is covered and compliant with RFCs. These tests are executed prior to the committing of code and nightly. The final deliverable is packaged and tested again to ensure no defects were introduced in the packaging of the software.

New versions of the WhoIs follow a deployment schedule. The new version is deployed into an OT&E environment for Registrar integration testing. Registrars who rely on WhoIs functionality are encouraged during this stage to test their systems operate without change. After a fixed time in OT&E without issue, new versions are scheduled for production deployment. This ensures incompatibilities with RFCs that made it through QA processes are detected in test environments prior to reaching production.

ARI is committed to providing a WhoIs service that integrates with third party tools and as such tests are conducted using these tools such as jWhoIs, a popular UNIX command line WhoIs client. Any issues identified during integration fall into 1 of the following categories:
– Third-party tool not compliant with the WhoIs specification
– WhoIs service not compliant
– Both third-party tool and WhoIs service are compliant, however another operational issue causes a problem

Defects are raised and follow the change management. Change requests may also be raised to promote integration of third-party tools and to meet common practice.



9 RESOURCES

This function will be performed by ARI. The WhoIs system is supported by a number of ARI departments:
– Products and Consulting Team (7 staff)
– Production Support Group (27 staff)
– Development Team (11 staff)
– Legal, Abuse and Compliance Team (6 staff)

A detailed list of the departments, roles and responsibilities in ARI is provided as attachment ‘Q26 – ARI Background & Roles.pdf’. This attachment describes the functions of the above teams and the exact number and nature of staff within.

The number of resources required to design, build, operate and support the SRS does not vary significantly with, and is not linearly proportional to, the number or size of TLDs that ARI provides registry services to.

ARI provides registry backend services to 5 TLDs and has a wealth of experience in estimating the number of resources required to support a registry system.

Based on past experience ARI estimates that the existing staff is adequate to support a registry system that supports in excess of 50M domains. Since this TLD projects 3,664 domains, 0.01% of these resources are allocated to this TLD. See attachment ‘Q26 – Registry Scale Estimates & Resource Allocation.xlsx’ for more information.

ARI protects against loss of critical staff by employing multiple people in each role. Staff members have a primary role plus a secondary role for protection against personnel absence. Additionally ARI can scale resources as required. Additional trained resources can be added to any of the above teams with a 2 month lead time.

The products and consulting team is responsible for product management of the WhoIs solution including working with clients and the industry to identify new features or changes required to the system. The team consists of:
– 1 Products and Consulting Manager
– 1 Product Manager
– 1 Technical Product Manager
– 4 Domain Name Industry Consultants

ARI employ a development team responsible for the maintenance and continual improvement of the WhoIs software. The team consists of:
– 1 Development Manager
– 2 Business Analysts
– 6 Developers
– 2 Quality Analysts

ARI’s Production Support Team ensures the successful operation of the WhoIs system. The team comprises Database Administrators, Systems Administrators and Network Administrators. This team routinely checks and monitors bandwidth, disk and CPU usages to plan and respond to expected increases in the volume of queries, and perform maintenance of the system including security patches and failover and recovery testing. The team consists of:
– Production Support Manager
– Service Desk:
– 1 Level 1 Support Team Lead
– 8 Customer Support Representatives (Level 1 support)
– 1 Level 2 Support Team Lead
– 4 Registry Specialists (Level 2 support)
– Operations (Level 3 support)
– 1 Operations Team Lead
– 2 Systems Administrators
– 2 Database Administrators
– 2 Network Engineers
– Implementation
– 1 Project Manager
– 2 Systems Administrators
– 1 Database Administrators
– 1 Network Engineers

ARI’s registry provides abuse monitoring detection mechanisms to block data mining. ARI support staff may be contacted to remove blacklisted users during which they may be referred to the Legal, Abuse and Compliance Team for evaluation of their activities. Additionally the support team in conjunction with the Legal, Abuse and Compliance team administer requests for listing on the whitelist. The team consists of:
– 1 Legal Manager
– 1 Legal Counsel
– 4 Policy Compliance Officers

These resources sufficiently accommodate the needs of this TLD, and are included in ARI’s fees as described in our Financial responses.