| gTLD | Full Legal Name | E-mail suffix | Detail | | .auto | Uniregistry, Corp. | internet.pro | View |
TABLE OF CONTENTS
26.1 WHOIS SERVICE
26.1.1 Architecture
26.1.2 Port 43 Whois
26.1.3 Tiered Access Web⁄RESTful Interface
26.1.4 Privacy and Transparency
26.1.5 Abuse Mitigation
26.2 RESOURCING PLANS
26.2.1 Human Resources
26.2.2 Technical Platform
26.3 SYSTEM PERFORMANCE
26.3.1 Procedure
26.3.2 Results
26.3.3 Queries per Second
26.3.4 Round Trip Times
26.3.5 Server Load
26.4 ABOUT THIS RESPONSE
〈〉 - - - - - 〈〉
26.1. WHOIS SERVICE
26.1.1. Architecture
Our whois service is highly robust, geographically scalable, flexible, allows resources to be added or replaced without service disruption, and executes seamless failover. As shown in EXHIBIT ʺ26-Figure-Whois-Architecture.pngʺ it is located in three data centers. The location of the third data center will be determined by a security assessment to be performed in mid 2012. Each data center is internally redundant with local Load Balancers (LB) and firewalls, and each provides backup for the other. Global LB apportions the query traffic among the two centers. Each facility can handle the entire anticipated whois traffic load.
The LB servers provide two distinct forms of access: Port 43 Whois (RFC 3912), providing classic Whois service; and Tiered Whois Access using a RESTful web interface supporting various search facilities, and returns answers in XML.
When a user contacts the whois service, the LBs will route the user to the most appropriate data center and server. Should a server or a data center be unavailable, the LBs will spread the work among the rest of the servers to improve reliability. EXHIBIT ʺ26-Figure-Whois-Overview.jpgʺ further shows the front-end to back-end communication path.
26.1.1.1. Scalability
Every element of the whois service platform can be expanded without disrupting operations, and each single server can provide all necessary components of the system. Hence, a server can be placed in any location as chosen by the Registry Operations Center (ROC). In case of a large demand spike, such as DoS attacks or unpredicted traffic bursts, additional servers can be quickly deployed to distribute the load on a temporary basis.
26.1.1.2. Frequency of Updates
Whois servers query a database cluster that is part of our live database replication system.
This means that servers are up to date quickly after the submission of the operation. The servers are designed to be able to handle user queries even when isolated from the main database cluster replication mechanism. When replication is not possible, the system falls back to periodic (1 hour) updates.
26.1.2. Port 43 Whois
Our standard Whois service implementation consists of a high capacity Internet server that answers RFC 3912 requests on TCP port 43, waits for a query string and returning a text response. The system supports various anti-abuse mechanisms to protect the service.
26.1.2.1. Software
The whois server is a custom designed solution that uses our front-end architecture to interact with high performance back-end components.
Servers can be provisioned individually to increment the service capacity transparently. Systems architecture allows servers either to have their own read-only replica database, or to share a cluster among them for increased-demand scenarios.
26.1.2.1.1. Development Process
The Agile software development process used for this service is the same that is explained in our answer to Question 24.
26.1.2.1.2. Features
Our Whois system implements the following features:
* Input timeouts to limit resource usage (default 4 seconds).
* Input length verification to prevent resource exhaustion attacks (default 1024 bytes).
* Response Caching
* Statistics collection
26.1.2.2. Query Format
RFC 3912 specifies the format in which a Whois query is to be sent to the server. After the client has initiated the TCP connection to port 43 of a Whois server, the server expects to receive a valid query within the input timeout interval.
Any mixture of upper- or lower-case letters may be used in a query; the protocol is not case sensitive.
Queries are encoded using either US-ASCII or UTF-8; this allows for extended character sets while keeping backwards compatibility with older implementations.
To maintain compatibility with whois clients that use keywords before the query (usually to restrict the search to a specific type of object) the whois server is also capable of understanding queries with the CONTACT, HOST, DOMAIN or REGISTRAR prefixes: DOMAIN example.tld[CR][LF]
To permit querying of an IDN domain name, either the IDNʹs A-Label or the U-Label is allowed in the query string.
26.1.2.3. Query Response
The whois response consists of US-ASCII encoded text with a set of key⁄value pairs and informative notes describing the object queried and legal disclaimers.
Data objects are represented in key⁄value pairs. Lines start with a key followed by a colon ʹ:ʹ and a space as delimiters, followed by the value.
Fields that contain multiple values for the same key repeat the key at the beginning of the line.
This format conforms to Specification 4 of the Registry Agreement.
The EXHIBIT: ʺ26-Table-WHOIS-Responses.pdfʺ contains examples of the response for a WHOIS query for a domain, registrar and name server.
All of the fields specified in the response will conform with the mappings specified in the RFCs related to EPP: RFC 5730, RFC 5731, RFC 5732, RFC 5733, RFC 5734 and RFC 5910.
26.1.3. Tiered Access Web⁄RESTful Interface
26.1.3.1. Summary
To overcome the limitations of the Whois protocol as specified in RFC 3912 we have developed a tiered system that supports varying levels of access to Whois information.
The Tiered Access system uses a web-based RESTful (Representational State Transfer) interface to query the registry.
Tiered Access to Whois data is subject to strict security and access controls to ensure that access is limited to identifiable qualified users.
All transfers are encrypted using the HTTPS protocol.
Tiered Access queries can either be general exact-match queries similar to the port-43 service, or wildcard search strings that can yield more than one result. The particular information that is made available to the service user is configurable according to registry policy.
The registry operator can grant bulk data access to qualified organizations. Such use will be governed by a contract that sets forth the conditions and limitations of such access. Bulk data access is performed using a specialized RESTful interface based on HTTPS.
Currently the RESTful interface lacks any IETF standardization. ISC participates in this effort within the IETF and will adjust its operational implementation to be RFC compliant once such an RFC exists.
26.1.3.2. Searchability
The Tiered Access RESTful⁄Web-whois service is not bound to the same protocol technology restrictions as the port 43 (RFC 3912). Consequently there is room for innovation in the way clients interact with the service.
The system allows the user to query the whois database using keywords. These keywords will be partially matched against the following database fields:
* Domain name;
* contact names (including registrant), and:
** Postal Addresses;
** City;
** State;
** Country; and
** Any other subfields as needed
In addition to the partially matched queries, the system will also support exact match on the following fields:
* Registrar ID;
* Name server (using a Fully Qualified Domain Name);
* IP addresses (IPv4 and IPv6)
Multiple keywords may be combined using the following boolean operations: AND, OR and NOT.
Search results will consist of lists of objects that match the userʹs search criteria.
This search capability meets or exceeds the requirements of Specification 4 of the Registry Agreement.
26.1.3.3. Architecture
The Tiered Access interface to the whois system uses the same underlying architecture as described previously in this answer. The only difference is the way the system is queried and the format of the responses.
The architecture uses a RESTful interface, as described in http:⁄⁄en.wikipedia.org⁄wiki⁄Representational_state_transfer.
When issuing a Tiered Access query the following HTTP methods are supported:
* GET - This is used to obtain information about an object.
* HEAD - This is used to check object existence without obtaining the actual data.
26.1.3.4. Query Format
All the queries to the system are performed through HTTPS (HTTP Secure) using URLs crafted to contain the query information. These are described below.
26.1.3.4.1. Exact Matches
For exact match searches the user will issue an HTTP query of the following form: https:⁄⁄whois.nic.AUTO⁄rest⁄OBJECT⁄NAME where OBJECT corresponds to any of the following keywords:
* domain - for domain objects;
* host - for name servers;
* contact - for contact objects; and
* registrar - for registrar information
NAME corresponds to the object ID that the client wishes to retrieve.
26.1.3.4.2. Searchable Keywords
Searchable Whois accommodates those cases where customers such as law enforcement require additional capabilities not available via traditional Port 43 whois. To access the searchable part of the Tiered Access service, customers must have obtained authorization credentials by registering into the Web whois system, and providing at least:
* Email Address
* Desired Password
* First Name
* Last Name
* Affiliation or Capacity
Once the requester has submitted the registration form, an email address will be sent to verify the email address. This allow us to certify that the email is valid, and that it is in use by the current requester.
For a searchable Tiered Access Whois query the user will issue an HTTPS query of the following form:
https:⁄⁄USER:PASSWORD@whois.nic.AUTO⁄search⁄OBJECT⁄KEYWORDS?key=value
USER:PASSWORD provides the authentication credentials to use the RESTful interface.
OBJECT corresponds to any of the following keywords:
* domain - for domain objects;
* host - for name servers;
* contact - for contact objects; and
* registrar - for registrar information
KEYWORDS correspond to partially matched string corresponding to the identifier of the object, for example, the query:
https:⁄⁄foo:bar@whois.nic.AUTO⁄search⁄domain⁄exam?country=US&state=CA
Will result in the list of domain names that start with exam* and that have a registrant in the United States. By default the system uses the AND boolean operator to perform the search. However a + and ! character can be prepended to the value string to indicate OR or NOTʹ operations.
For example, a query similar to the one described above but for domain names where the registrant is NOT in the US would be:
https:⁄⁄foo:bar@whois.nic.AUTO⁄search⁄domain⁄exam?country=!US
Note that this interface is still under development. We are tracking the efforts of the IETF WIERDS working group in this area. Our interface will evolve in response to the IETFʹs work.
26.1.3.5. Query Response
The Tiered Access interface allows the output to be in XML format. XML tools such as XSLT and stylesheets make it possible to convert or re-format the data as desired.
26.1.3.5.1. XML Format
The current proposed format for the XML response, will use namespaces as similar as possible to those provided in RFC 5731, RFC 5732, RFC 5733 and RFC 5734.
The following exhibit shows an example of a whois response for example.AUTO.:
https:⁄⁄whois.nic.AUTO⁄rest⁄domain⁄example.tld.
See EXHIBIT: ʺ26-Exhibit-Restful-Whois.pdfʺ.
The format consist of a ʺresponseʺ tag that contains exactly one object, in this example, the domain object example.tld.
Any objects mentioned within the response object will be returned in the ʺadditionalʺ section using the same object-notation format.
This format is subject to change when the IETF working group standardizes the interface.
26.1.4. Privacy and Transparency
ISC SRS implements the ability to specify the fields that can be publicly displayed as described in RFC 5733. Fields marked to prohibit disclosure are not shown to public or unauthorized users. Registrars can set the level of privacy based on the relevant jurisdiction and will be required to comply with applicable privacy protection laws. Uniregistry will provide registrars with a set of default privacy level protections based on the country of the registrant, to the extent that such privacy protections are known. As the party collecting data, registrars are best positioned to provide the required notifications, warnings or terms of service to their customers as dictated by jurisdictional requirements. The RFC 5733 mechanism is combined with appropriate language in the registrar agreement to facilitate compliance with jurisdictional requirements on the information that is presented to third parties and under what circumstances.
ISC SRS also implements the ability to remove Contact objects when those are not required for other active registrations, allowing inactive registrants to remove their personal information from the registry database, allowing compliance with all current privacy requirements at the required jurisdictions.
To promote transparency, Uniregistry will implement a service in which registrants can opt-in through their registrar, allowing a registrant to receive notice whenever domain name contact information is accessed via one of the whois querying mechanisms.
Certain jurisdictions, notably the European Union, have implemented data protection regulations and principles that may conflict with one another and with which there has been tension and ongoing discussion in relation to ICANN policies and requirements. While Uniregistry cannot track and implement multiple conflicting data protection requirements on a global basis, the primary commercial relationship is between the registrar and the registrant.
Uniregistry will continue to monitor policy developments in this area, which principally occur in venues such as the Internet Governance Forum and the ICANN Government Advisory Committee, to remain abreast of best practices in this area. Uniregistry will require its accredited registrars to maintain compliance with relevant regulations in their respective jurisdictions, and receive input from impacted registrars to detemine how Uniregistryʹs Whois practices can best accomodate the continued expansion of domain name availability into jurisdictions under-served by local registrars and which may present conflicts that may need to be addressed with the appropriate authority in such jurisdictions.
26.1.5. Abuse Mitigation
Whois services are subject to multiple forms of attack, some of them well known in the industry. The first and most common line of defense is to rate-limit the number of queries one client can perform according to various criteria.
Since it is not possible to envision every type of attack against a whois server, the registry will collect queries in real time and stream them into an analysis system to detect unusual patterns and behaviors, feeding the ROC with the information it needs for defense.
The provision of Whois services will be subject to terms prohibiting the use of Whois data for mass marketing and other inappropriate uses. Uniregistry will actively seek to detect these activities, investigate third party reports of misuse of Whois data, and de-accredit registrars if they or their resellers are found to be facilitating or engaging in such activies. Uniregistry will also seek judicially-available sanctions against non-registrar abusers of Whois data in violation of the terms of service.
26.2. RESOURCING PLANS
Costs and procurement of the resources described here are detailed in our response to Question 47.
26.2.1. Human Resources
See EXHIBIT: 26-Chart-Resourcing.png
The resourcing plan specific to this response follows the principles, guidelines and information set forth in our response to Question 23.
The accompanying chart shows the human resources allocated to the functions depicted in this response.
26.2.2. Technical Platform
Four servers will be made available to registrars to interact with the registry. Provisioning of additional servers is a straightforward procedure that can be triggered by demand thresholds, which is currently set a 80% of any systemʹs total capacity. Adding servers does not disrupt ongoing operations.
Each of the registry locations is able to sustain the entire estimated traffic level by itself. Nevertheless, we expect that traffic load will remain equally distributed among them to provide a better user experience.
The ROC will be monitoring source traffic to gather data that can be used to plan the location of potential new sites aimed when expansion becomes necessary.
26.3. SYSTEM PERFORMANCE
26.3.1. Procedure
To test the whois service, a custom software defined as ʹperf-whoisʹ was written with the purpose of simulating client connections.
The test was executed using:
perf-whois -h 10.1.2.1 -p 43 -n 1000 -q ʹdomain example3.iscʹ -d results⁄
The software then proceeded to generate:
* One stream of 1000 sequential queries
* 2,4,8,16,32,128 parallel streams of 1000 queries each
The software was collects the round-trip-time and the number of queries per second of the whois queries.
26.3.2. Results
26.3.3. Queries per Second
The EXHIBIT ʺ26-Chart-Qps-graph.pngʺ is a graphical view of the number of queries per second collected by the tool.
26.3.4. Round Trip Times
The current Service Level Agreement (SLA), as described in Specification 10 of the Applicants Guidebook, references a maximum of 2000 milliseconds for at least 95% the RTT of the whois service. During our test we did not see any RTT values go higher than 229 ms.
Since we are planning to deploy four (4) high performance Whois servers, we expect to exceed the SLA with the setup that we currently have in place.
The EXHIBIT ʺ26-Chart-Rtt-graph.pngʺ is a graphical view of the raw data as collected by the tool.
26.3.5. Server Load
During the performance test, we collected CPU usage (system and user). We did not observe the system to be even slightly stressed during the procedure. The CPU usage levels increased to a maximum of 70%, clearly with enough capacity to keep performing other functions.
The EXHIBIT ʺ26-Chart-Vmstat-graph.pngʺ show the results of the CPU usage of the server during the test.
26.4. ABOUT THIS RESPONSE
This answer meets the requirements of this question:
* Our Whois protocols, interfaces, and data conform to all relevant internet standards, best practices, and RFCs.
* We support a searchable whois via our Whois Tiered Access interface.
* Access to our Tiered Whois Service is protected by security and access control.
* All of our Whois services are protected against foreseeable attacks.
* Our Whois service is highly robust and scalable, with dynamic load balancing, geographic distribution, high levels of security and access control, and fast fail-over.
* Our Whois service is fully integrated into our registry technical approach and operations.
* Our Whois service complies with Specifications 4 and 10 of the Registry Agreement.
This answer exceeds the requirements of this question:
* We provide a searchable Whois service using a RESTful web service interface that allows searching by several registration fields and with combinations of search operators. We provide a service that is compliant with relevant privacy protection laws.
* Our Whois services are protected by access controls and rate limitations. Advanced features are constrained so that they may be used only by known users who have been granted access credentials.
| gTLD | Full Legal Name | E-mail suffix | Detail | | .team | Uniregistry, Corp. | internet.pro | View |
TABLE OF CONTENTS
26.1 WHOIS SERVICE
26.1.1 Architecture
26.1.2 Port 43 Whois
26.1.3 Tiered Access Web⁄RESTful Interface
26.1.4 Privacy and Transparency
26.1.5 Abuse Mitigation
26.2 RESOURCING PLANS
26.2.1 Human Resources
26.2.2 Technical Platform
26.3 SYSTEM PERFORMANCE
26.3.1 Procedure
26.3.2 Results
26.3.3 Queries per Second
26.3.4 Round Trip Times
26.3.5 Server Load
26.4 ABOUT THIS RESPONSE
- - - - -
26.1. WHOIS SERVICE
26.1.1. Architecture
Our whois service is highly robust, geographically scalable, flexible, allows resources to be added or replaced without service disruption, and executes seamless failover. As shown in EXHIBIT ʺ26-Figure-Whois-Architecture.pngʺ it is located in three data centers. The location of the third data center will be determined by a security assessment to be performed in mid 2012. Each data center is internally redundant with local Load Balancers (LB) and firewalls, and each provides backup for the other. Global LB apportions the query traffic among the two centers. Each facility can handle the entire anticipated whois traffic load.
The LB servers provide two distinct forms of access: Port 43 Whois (RFC 3912), providing classic Whois service; and Tiered Whois Access using a RESTful web interface supporting various search facilities, and returns answers in XML.
When a user contacts the whois service, the LBs will route the user to the most appropriate data center and server. Should a server or a data center be unavailable, the LBs will spread the work among the rest of the servers to improve reliability. EXHIBIT ʺ26-Figure-Whois-Overview.jpgʺ further shows the front-end to back-end communication path.
26.1.1.1. Scalability
Every element of the whois service platform can be expanded without disrupting operations, and each single server can provide all necessary components of the system. Hence, a server can be placed in any location as chosen by the Registry Operations Center (ROC). In case of a large demand spike, such as DoS attacks or unpredicted traffic bursts, additional servers can be quickly deployed to distribute the load on a temporary basis.
26.1.1.2. Frequency of Updates
Whois servers query a database cluster that is part of our live database replication system.
This means that servers are up to date quickly after the submission of the operation. The servers are designed to be able to handle user queries even when isolated from the main database cluster replication mechanism. When replication is not possible, the system falls back to periodic (1 hour) updates.
26.1.2. Port 43 Whois
Our standard Whois service implementation consists of a high capacity Internet server that answers RFC 3912 requests on TCP port 43, waits for a query string and returning a text response. The system supports various anti-abuse mechanisms to protect the service.
26.1.2.1. Software
The whois server is a custom designed solution that uses our front-end architecture to interact with high performance back-end components.
Servers can be provisioned individually to increment the service capacity transparently. Systems architecture allows servers either to have their own read-only replica database, or to share a cluster among them for increased-demand scenarios.
26.1.2.1.1. Development Process
The Agile software development process used for this service is the same that is explained in our answer to Question 24.
26.1.2.1.2. Features
Our Whois system implements the following features:
* Input timeouts to limit resource usage (default 4 seconds).
* Input length verification to prevent resource exhaustion attacks (default 1024 bytes).
* Response Caching
* Statistics collection
26.1.2.2. Query Format
RFC 3912 specifies the format in which a Whois query is to be sent to the server. After the client has initiated the TCP connection to port 43 of a Whois server, the server expects to receive a valid query within the input timeout interval.
Any mixture of upper- or lower-case letters may be used in a query; the protocol is not case sensitive.
Queries are encoded using either US-ASCII or UTF-8; this allows for extended character sets while keeping backwards compatibility with older implementations.
To maintain compatibility with whois clients that use keywords before the query (usually to restrict the search to a specific type of object) the whois server is also capable of understanding queries with the CONTACT, HOST, DOMAIN or REGISTRAR prefixes: DOMAIN example.tld[CR][LF]
To permit querying of an IDN domain name, either the IDNʹs A-Label or the U-Label is allowed in the query string.
26.1.2.3. Query Response
The whois response consists of US-ASCII encoded text with a set of key⁄value pairs and informative notes describing the object queried and legal disclaimers.
Data objects are represented in key⁄value pairs. Lines start with a key followed by a colon ʹ:ʹ and a space as delimiters, followed by the value.
Fields that contain multiple values for the same key repeat the key at the beginning of the line.
This format conforms to Specification 4 of the Registry Agreement.
The EXHIBIT: ʺ26-Table-WHOIS-Responses.pdfʺ contains examples of the response for a WHOIS query for a domain, registrar and name server.
All of the fields specified in the response will conform with the mappings specified in the RFCs related to EPP: RFC 5730, RFC 5731, RFC 5732, RFC 5733, RFC 5734 and RFC 5910.
26.1.3. Tiered Access Web⁄RESTful Interface
26.1.3.1. Summary
To overcome the limitations of the Whois protocol as specified in RFC 3912 we have developed a tiered system that supports varying levels of access to Whois information.
The Tiered Access system uses a web-based RESTful (Representational State Transfer) interface to query the registry.
Tiered Access to Whois data is subject to strict security and access controls to ensure that access is limited to identifiable qualified users.
All transfers are encrypted using the HTTPS protocol.
Tiered Access queries can either be general exact-match queries similar to the port-43 service, or wildcard search strings that can yield more than one result. The particular information that is made available to the service user is configurable according to registry policy.
The registry operator can grant bulk data access to qualified organizations. Such use will be governed by a contract that sets forth the conditions and limitations of such access. Bulk data access is performed using a specialized RESTful interface based on HTTPS.
Currently the RESTful interface lacks any IETF standardization. ISC participates in this effort within the IETF and will adjust its operational implementation to be RFC compliant once such an RFC exists.
26.1.3.2. Searchability
The Tiered Access RESTful⁄Web-whois service is not bound to the same protocol technology restrictions as the port 43 (RFC 3912). Consequently there is room for innovation in the way clients interact with the service.
The system allows the user to query the whois database using keywords. These keywords will be partially matched against the following database fields:
* Domain name;
* contact names (including registrant), and:
** Postal Addresses;
** City;
** State;
** Country; and
** Any other subfields as needed
In addition to the partially matched queries, the system will also support exact match on the following fields:
* Registrar ID;
* Name server (using a Fully Qualified Domain Name);
* IP addresses (IPv4 and IPv6)
Multiple keywords may be combined using the following boolean operations: AND, OR and NOT.
Search results will consist of lists of objects that match the userʹs search criteria.
This search capability meets or exceeds the requirements of Specification 4 of the Registry Agreement.
26.1.3.3. Architecture
The Tiered Access interface to the whois system uses the same underlying architecture as described previously in this answer. The only difference is the way the system is queried and the format of the responses.
The architecture uses a RESTful interface, as described in http:⁄⁄en.wikipedia.org⁄wiki⁄Representational_state_transfer.
When issuing a Tiered Access query the following HTTP methods are supported:
* GET - This is used to obtain information about an object.
* HEAD - This is used to check object existence without obtaining the actual data.
26.1.3.4. Query Format
All the queries to the system are performed through HTTPS (HTTP Secure) using URLs crafted to contain the query information. These are described below.
26.1.3.4.1. Exact Matches
For exact match searches the user will issue an HTTP query of the following form: https:⁄⁄whois.nic.TEAM⁄rest⁄OBJECT⁄NAME where OBJECT corresponds to any of the following keywords:
* domain - for domain objects;
* host - for name servers;
* contact - for contact objects; and
* registrar - for registrar information
NAME corresponds to the object ID that the client wishes to retrieve.
26.1.3.4.2. Searchable Keywords
Searchable Whois accommodates those cases where customers such as law enforcement require additional capabilities not available via traditional Port 43 whois. To access the searchable part of the Tiered Access service, customers must have obtained authorization credentials by registering into the Web whois system, and providing at least:
* Email Address
* Desired Password
* First Name
* Last Name
* Affiliation or Capacity
Once the requester has submitted the registration form, an email address will be sent to verify the email address. This allow us to certify that the email is valid, and that it is in use by the current requester.
For a searchable Tiered Access Whois query the user will issue an HTTPS query of the following form:
https:⁄⁄USER:PASSWORD@whois.nic.TEAM⁄search⁄OBJECT⁄KEYWORDS?key=value
USER:PASSWORD provides the authentication credentials to use the RESTful interface.
OBJECT corresponds to any of the following keywords:
* domain - for domain objects;
* host - for name servers;
* contact - for contact objects; and
* registrar - for registrar information
KEYWORDS correspond to partially matched string corresponding to the identifier of the object, for example, the query:
https:⁄⁄foo:bar@whois.nic.TEAM⁄search⁄domain⁄exam?country=US&state=CA
Will result in the list of domain names that start with exam* and that have a registrant in the United States. By default the system uses the AND boolean operator to perform the search. However a + and ! character can be prepended to the value string to indicate OR or NOTʹ operations.
For example, a query similar to the one described above but for domain names where the registrant is NOT in the US would be:
https:⁄⁄foo:bar@whois.nic.TEAM⁄search⁄domain⁄exam?country=!US
Note that this interface is still under development. We are tracking the efforts of the IETF WIERDS working group in this area. Our interface will evolve in response to the IETFʹs work.
26.1.3.5. Query Response
The Tiered Access interface allows the output to be in XML format. XML tools such as XSLT and stylesheets make it possible to convert or re-format the data as desired.
26.1.3.5.1. XML Format
The current proposed format for the XML response, will use namespaces as similar as possible to those provided in RFC 5731, RFC 5732, RFC 5733 and RFC 5734.
The following exhibit shows an example of a whois response for example.TEAM.:
https:⁄⁄whois.nic.TEAM⁄rest⁄domain⁄example.tld.
See EXHIBIT: ʺ26-Exhibit-Restful-Whois.pdfʺ.
The format consist of a ʺresponseʺ tag that contains exactly one object, in this example, the domain object example.tld.
Any objects mentioned within the response object will be returned in the ʺadditionalʺ section using the same object-notation format.
This format is subject to change when the IETF working group standardizes the interface.
26.1.4. Privacy and Transparency
ISC SRS implements the ability to specify the fields that can be publicly displayed as described in RFC 5733. Fields marked to prohibit disclosure are not shown to public or unauthorized users. Registrars can set the level of privacy based on the relevant jurisdiction and will be required to comply with applicable privacy protection laws. Uniregistry will provide registrars with a set of default privacy level protections based on the country of the registrant, to the extent that such privacy protections are known. As the party collecting data, registrars are best positioned to provide the required notifications, warnings or terms of service to their customers as dictated by jurisdictional requirements. The RFC 5733 mechanism is combined with appropriate language in the registrar agreement to facilitate compliance with jurisdictional requirements on the information that is presented to third parties and under what circumstances.
ISC SRS also implements the ability to remove Contact objects when those are not required for other active registrations, allowing inactive registrants to remove their personal information from the registry database, allowing compliance with all current privacy requirements at the required jurisdictions.
To promote transparency, Uniregistry will implement a service in which registrants can opt-in through their registrar, allowing a registrant to receive notice whenever domain name contact information is accessed via one of the whois querying mechanisms.
Certain jurisdictions, notably the European Union, have implemented data protection regulations and principles that may conflict with one another and with which there has been tension and ongoing discussion in relation to ICANN policies and requirements. While Uniregistry cannot track and implement multiple conflicting data protection requirements on a global basis, the primary commercial relationship is between the registrar and the registrant.
Uniregistry will continue to monitor policy developments in this area, which principally occur in venues such as the Internet Governance Forum and the ICANN Government Advisory Committee, to remain abreast of best practices in this area. Uniregistry will require its accredited registrars to maintain compliance with relevant regulations in their respective jurisdictions, and receive input from impacted registrars to detemine how Uniregistryʹs Whois practices can best accomodate the continued expansion of domain name availability into jurisdictions under-served by local registrars and which may present conflicts that may need to be addressed with the appropriate authority in such jurisdictions.
26.1.5. Abuse Mitigation
Whois services are subject to multiple forms of attack, some of them well known in the industry. The first and most common line of defense is to rate-limit the number of queries one client can perform according to various criteria.
Since it is not possible to envision every type of attack against a whois server, the registry will collect queries in real time and stream them into an analysis system to detect unusual patterns and behaviors, feeding the ROC with the information it needs for defense.
The provision of Whois services will be subject to terms prohibiting the use of Whois data for mass marketing and other inappropriate uses. Uniregistry will actively seek to detect these activities, investigate third party reports of misuse of Whois data, and de-accredit registrars if they or their resellers are found to be facilitating or engaging in such activies. Uniregistry will also seek judicially-available sanctions against non-registrar abusers of Whois data in violation of the terms of service.
26.2. RESOURCING PLANS
Costs and procurement of the resources described here are detailed in our response to Question 47.
26.2.1. Human Resources
See EXHIBIT: 26-Chart-Resourcing.png
The resourcing plan specific to this response follows the principles, guidelines and information set forth in our response to Question 23.
The accompanying chart shows the human resources allocated to the functions depicted in this response.
26.2.2. Technical Platform
Four servers will be made available to registrars to interact with the registry. Provisioning of additional servers is a straightforward procedure that can be triggered by demand thresholds, which is currently set a 80% of any systemʹs total capacity. Adding servers does not disrupt ongoing operations.
Each of the registry locations is able to sustain the entire estimated traffic level by itself. Nevertheless, we expect that traffic load will remain equally distributed among them to provide a better user experience.
The ROC will be monitoring source traffic to gather data that can be used to plan the location of potential new sites aimed when expansion becomes necessary.
26.3. SYSTEM PERFORMANCE
26.3.1. Procedure
To test the whois service, a custom software defined as ʹperf-whoisʹ was written with the purpose of simulating client connections.
The test was executed using:
perf-whois -h 10.1.2.1 -p 43 -n 1000 -q ʹdomain example3.iscʹ -d results⁄
The software then proceeded to generate:
* One stream of 1000 sequential queries
* 2,4,8,16,32,128 parallel streams of 1000 queries each
The software was collects the round-trip-time and the number of queries per second of the whois queries.
26.3.2. Results
26.3.3. Queries per Second
The EXHIBIT ʺ26-Chart-Qps-graph.pngʺ is a graphical view of the number of queries per second collected by the tool.
26.3.4. Round Trip Times
The current Service Level Agreement (SLA), as described in Specification 10 of the Applicants Guidebook, references a maximum of 2000 milliseconds for at least 95% the RTT of the whois service. During our test we did not see any RTT values go higher than 229 ms.
Since we are planning to deploy four (4) high performance Whois servers, we expect to exceed the SLA with the setup that we currently have in place.
The EXHIBIT ʺ26-Chart-Rtt-graph.pngʺ is a graphical view of the raw data as collected by the tool.
26.3.5. Server Load
During the performance test, we collected CPU usage (system and user). We did not observe the system to be even slightly stressed during the procedure. The CPU usage levels increased to a maximum of 70%, clearly with enough capacity to keep performing other functions.
The EXHIBIT ʺ26-Chart-Vmstat-graph.pngʺ show the results of the CPU usage of the server during the test.
26.4. ABOUT THIS RESPONSE
This answer meets the requirements of this question:
* Our Whois protocols, interfaces, and data conform to all relevant internet standards, best practices, and RFCs.
* We support a searchable whois via our Whois Tiered Access interface.
* Access to our Tiered Whois Service is protected by security and access control.
* All of our Whois services are protected against foreseeable attacks.
* Our Whois service is highly robust and scalable, with dynamic load balancing, geographic distribution, high levels of security and access control, and fast fail-over.
* Our Whois service is fully integrated into our registry technical approach and operations.
* Our Whois service complies with Specifications 4 and 10 of the Registry Agreement.
This answer exceeds the requirements of this question:
* We provide a searchable Whois service using a RESTful web service interface that allows searching by several registration fields and with combinations of search operators. We provide a service that is compliant with relevant privacy protection laws.
* Our Whois services are protected by access controls and rate limitations. Advanced features are constrained so that they may be used only by known users who have been granted access credentials.