Back

26 Whois

gTLDFull Legal NameE-mail suffixDetail
.bradescoBanco Bradesco S.A.pppadvogados.com.brView
26.1 --A HIGH-LEVEL WHOIS SYSTEM DESCRIPTION--
The registry will operate a Whois service on Port 43 according to Specification 4 and in accordance with RFC 3912. The registry will also provide a free public query-based directory service on the web at http:⁄⁄whois.nic.«stringforcode». The Whois directory will display domain name, registrar, and nameserver data. The fields will be formatted to conform to the mappings specified in EPP RFCs 5730, 5731, 5732, 5733 and 5734.

The Whois directory will support standard and Boolean searches (including AND, OR and NOT logical operators). Search results will include domain names matching the search criteria. We will implement appropriate measures to avoid abuse of the feature and ensure that the feature is in compliance with any applicable privacy laws or policies.

We will offer searchability on the web-based Directory Service. We will offer partial match capabilities on the following fields: domain name, contacts and registrant’s name, and contact and registrant’s full postal address. We will offer exact match capabilities on the following fields: registrar ID, nameserver name, and nameserver’s IP address for in-zone hosts (glue records).

The user will choose one or more search criteria, combine them by Boolean operators (AND, OR, NOT) and provide partial or exact match regular expressions for each of the criterion name-value pairs. The domain names matching the search criteria will be returned to the user.

Mitigation against abuse is achieved via black⁄white listing of IP addresses of known parties. We also configure a maximum hit threshold per IP range. The threshold applies to hits within a certain time, both from a single IP and a network.

Our Whois service meets Specifications 4 and 10 of the new gTLD Registry Agreement:
- Whois service available via port 43 in accordance with RFC 3912, and a web-based Directory Service at whois.nic.«stringforcode» providing free public query-based access.
- The format of responses follows a semi-free text format, followed by a blankline and a legal disclaimer specifying the rights of Registry Operator, and of the user querying the database.
- Each data object is be represented as a set of key⁄value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value.
- For fields where more than one value exists, multiple key⁄value pairs with the same key shall be allowed (for example to list multiple name servers). The first key⁄value pair after a blank line should be considered the start of a new record, and should be considered as identifying that record, and is used to group data, such as hostnames and IP addresses, or a domain name and registrant information, together.
- RDDS availability SLA
- RDDS update time SLA
- RDDS query RTT SLA

Whois output meets the requirements listed in Specification 4 (Registration Data Publication Services). Additionally, each field can be toggled on or off for display on a per-zone basis to ensure compliance with any applicable privacy laws or policies. In other words, the Whois can be configured to accommodate more stringent privacy policies than the full disclosure that is possible. We will comply with Specification 4 such that the data objects listed will be displayed for public Whois records as follows: Domain Name Data Objects:
Domain Name
Domain ID
Whois Server
Referral URL
Updated Date
Creation Date
Expiration Date
Sponsoring Registrar
Sponsoring Registrar IANA ID
Status
DNSSEC
Registrant Data Objects:
Registrant ID
Registrant Name
Registrant Organization
Registrant Street1
Registrant City
Registrant State⁄Province
Registrant Postal Code
Registrant Country
Registrant Phone
Registrant Phone Ext
Registrant Fax
Registrant Fax Ext
Registrant Email
Admin Contact Data Objects:
Admin ID
Admin Name
Admin Organization
Admin Street1
Admin City
Admin State⁄Province
Admin Postal Code
Admin Country
Admin Phone
Admin Phone Ext
Admin Fax
Admin Fax Ext
Admin Email
Tech Contact Data Object:
Tech ID
Tech Name
Tech Organization
Tech Street
Tech City
Tech State⁄Province
Tech Postal Code
Tech Country
Tech Phone
Tech Phone Ext
Tech Fax
Tech Fax Ext
Tech Email
Registrar Data Objects:
Registrar Name
Address fields
Phone Number
Fax Number
Whois Server
Referral URL
Admin Contact
Phone Number
Fax Number
Email
Technical Contact
Phone Number
Fax Number
Email
Last update of Whois database
Nameserver Data Objects:
Server Name
IP Addresses
Registrar
Whois Server
Referral URL
Last update of Whois database

In addition to the RFC-compliant functions, the system allows character sets that are not ASCII as additional Whois display fields (Local Language contact details).

The registry system will implement abuse-prevention measures, such as white-listing contracted registrars’ IP address ranges for search, black-listing known bad-actors or previous violators, and capping the number of Whois searches possible during a time frame.

The registry administration will comply with applicable laws and policies regarding privacy (see Question 28: Abuse Prevention and Mitigation). The registry, in conjunction with the Vice President for Policy of Minds + Machines, will balance the ICANN Whois data display requirements with local laws, and will ensure compliance by users through enforcement of registration policies.

Third party access to zone files will be provided according to the requirements detailed in Section 2 of Specification 4. The zone files will match the file format standard, and use of data by users will only be permitted for lawful purposes. Bulk access to the zone files will be provided to ICANN and Emergency Operators as specified.

Thin registration data (domain name, registrar, Whois server, referral URL, nameservers, status, update date, creation date and expiration date) access will be granted to ICANN periodically, and thick registration data will be made available in case of a registrar failure.

The registry Whois service complies with RFC 3912 by listening on TCP port 43 for requests from Whois clients. Anyone with Internet access can use the Whois portal to check the registration data for a domain name. The Whois server replies with text content, and terminates in ASCII. As soon as the output is finished the Whois server closes the connection to the client.

--RESOURCE ALLOCATION--
The registry system, Espresso, is already in operation and regularly supports Whois requests for current TLDs. The Minds + Machines software development team will update the registry system code to meet IETF Whois RFC specifications as necessary. Since the Whois function is already built and operational, the software development team allocates personnel resources as needed when changes are required.

26.2 Relevant network diagram: Please see the attached diagram, “Q 26 Whois,” which shows the interrelationships of the Whois with the internal and external registry components.

26.3 --IT AND INFRASTRUCTURE RESOURCES--
The technical resources required to run Whois are adequate, on hand, committed, and readily available. The registry will operate two instances of Whois at the primary registry location, one primary and one hot standby backup; and another two Whois servers at the secondary location.

In the event of failure of one hardware component at the primary registry location, the backup server will handle all transactions until the failed server becomes available again. For further details about failover of Whois, see Question 39: Registry Continuity and Question 41: Failover. Any fail-over of the application or Whois service will not affect registrar transactions as fail-over testing has proven only seconds of downtime.

26.4 --INTERCONNECTIVITY WITH OTHER REGISTRY SYSTEMS--
Connectivity between the Internet, the Primary Site, and the Secondary Remote Site is via multiple redundant connections, as further described in Question 32: Architecture. In addition, connections between servers on the internal Registry Network are via redundant multi-homed 1 Gbps Ethernet. Connectivity between the primary and secondary registry facility (for replication) is via redundant SSH connections. In addition, a third data backup in a remote location is connected for disaster recovery.

High capacity routers and switches are used to route traffic to registry services (see response to Question 32: Architecture). Load balancing is used to distribute load across resources.

Internet connectivity will be supplied via a 100Mbps solution with fully diverse connections to multiple Internet service providers. Further details can be found in Question 32: Architecture and Question 35: DNS. The Registry Internet connections at both the Primary and Secondary Sites will be provisioned to support burstable 1 Gbps capacity.

When an update, for example, to a domain registrant record is made to the registry database, Whois automatically reflects these changes because it is an element of the overall SRS. There is never inaccuracy of the published data because of this configuration.

26.5 --DATA CENTER CONNECTIVITY--
Our primary NOC is a co-location facility hosted by IX2, in Los Angeles, US. At the core of all IX2 connectivity, IX2 owns and maintains redundant 432+ strand Corning single-mode dark fiber. The redundant fiber traverses diverse paths to and from multiple IX2 data centers including IX2ʹs space in One Wilshire Buildingʹs ʺMeet-Me-Roomʺ and adjacent buildings occupied by IX2. IX2 also has direct dark-fiber to multiple Tier 1 carriers (Level3, Cogent, AT&T, Verizon, etc.) as well as low-hop connectivity to hundreds of ISP backbone networks. Many Tier 1 providers also co-locate within IX2ʹs data centers. Over IX2ʹs fiber connections, IX2 can transport many types of circuits from; TDM OC192 Sonet, to 10Gig Ethernet, down to TDM T1, to 10⁄100 FastEthernet.

Our secondary NOC, managed by Tucows at Q9, in Brampton, CA ,is directly connected to major Internet backbones and regional ISPs available in the vicinity of the Q9 data center. In addition, Q9 has a 1Gb Fibre connection to 151 Front (co-location facility) and a 1Gb Fibre connection to Tucows’ main office at 96 Mowat Ave. The office at 96 Mowat Ave has a 1Gb Fibre connection to 151 Front (co-location facility) creating a 3 x 1Gb triangle between the Q9 data center, 151 Front and 96 Mowat. At the Q9 data center, Tucows has a 1Gb Internet connection to Allstream. At the 151 Front, Tucows has a 1Gb Internet connection with Cogent and a 1Gb Internet connection with Level3. Tucows peers with TORIX and Rogers at 151 Front and, if needed, can aggregate up to 3Gb of Internet traffic to the Q9 datacenter via the 2 x 1Gb links to 151 Front and 96 Mowat + 1 Gb from Allstream. Tucows currently owns all its IP blocks, has its own ASN and BGP configuration and retains full control of peering and IP space. Tucows is fully autonomous and do not rely on third parties to provide or manage network peering capabilities.

Tucows maintains a dedicated, high-speed, low-latency, path-diverse network between its facilities in each geographic region. These regional networks are used to provide reliable, cost-effective connectivity based in different Tucows data centers within the same region.

The secondary NOC provides customers with a redundant Internet connection, a 100 per cent availability SLA and the flexibility to scale to higher bandwidth requirements.

Q9 maintains a dedicated, high-speed, low-latency path-diverse network between its facilities in each geographic region. These regional networks are used to provide reliable, cost-effective connectivity for customers with multi-site solutions based in different Q9 data centers within the same region. Solutions range from traditional switched Ethernet to dedicated wavelengths.



26.6 --FREQUENCY OF SYNCHRONIZATION BETWEEN SERVERS--
Updates from the SRS to the Whois servers happens in real-time via an asynchronous publish⁄subscribe messaging architecture. These are updated in each slave within the required SLA of 95% ≤ 60 minutes. See Question 30: Security and Question 32: Architecture for further details.

26.7 --POTENTIAL FORMS OF ABUSE OF SEARCHABLE WHOIS, AND MITIGATION--
Because the IETF Whois protocol has no provisions for strong security, the Whois directory service is vulnerable to abuse of access control, integrity, and confidentiality. The registry system Espresso features several functions to mitigate data mining, server overload, and access abuse, as explained below.

The web interface for Whois can be configured through the Espresso Registry administrative area. CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) is used on the web form to mitigate data mining. Network and IP limits are configurable to prevent overloading the Whois server with malicious or extraneous requests. Whois look-ups will be set to 100 requests every 60 minutes for unknown IP ranges. Network limits will be set to 1000 request every 1440 minutes for unknown networks. When the limits are reached, the requests will be restricted and a message will be displayed notifying the user that the limit has been reached. The message also provides instructions to the user to contact the registry if they would like to have their IP or Network range white-listed. Whois request records will be archived, in order to provide law enforcement officials with any necessary information they require for enforcement.

A blacklist is used to block IP addresses or networks of known bad actors. Similarly, a white list may be used to allow trusted users greater Whois look-up access. Terms of use will be displayed on the Whois interface, notifying all users of the terms and conditions for access to the Whois database.

The registry system logs all Whois queries. A server status field displays the number of active requests for a specified time range. The request logs can be searched by the minute, hour, day, month, year, and since delegation. These logs can be output and downloaded as comma-separated value (CSV) files and subsequently used to generate any type of report required.

The Whois server is constantly monitored to ensure 100% uptime. The monitoring tool outputs reports showing the number of queries, and response rates over variable time periods. Whois service will be in full compliance with the final specification of ICANN’s Registration Data Publication Services Document.

26.8 --RESOURCE ALLOCATION--
The SRS registry system, Espresso, is already operational and regularly supports Whois requests for the current TLD operated by Minds + Machines, .FM. The software development team will update the registry system code to meet IETF WHOIS RFC specifications as necessary. The CTO allocates personnel resources as needed to maintain the Whois infrastructure, and to update the code and hardware when changes are required. The Network Operations Managers and technical staff maintain the hardware that supports the Whois function. The Database Developers and Administrators ensure that the Whois element of the application is able to access real-time data from the registry database. The Director of Legal Affairs and the compliance administrator assures that the Whois function and data displayed complies with ICANN consensus policy, privacy policies, and applicable laws and regulations. The Registrar Customer Service technical support personnel assist registrars with Whois access, including white-listing known and trusted IP ranges.

Our registry functions are outsourced to Minds + Machines. Their staff resource allocation follows. All costs associated with the technical functioning of the registry are covered by Minds + Machines as per our contract with them. Please see the attachment to “Q 24 Staff” for complete descriptions of each staff position.

Title Startup Yr1 Yr2 Yr3
----- ------- --- --- ---
CTO 2% 2% 2% 2%
Director Legal Affairs 2% 2% 2% 2%
Compliance Administrator -- 5% 5% 5%
Registrar CS Tech 1 2% 2% 2% 2%
Registrar CS Tech 2 -- -- 2% 2%
Network Operations Mgr 2% 2% 2% 2%
Network Engineer 1 2% 2% 2% 2%
Network Engineer 2 -- -- 2% 2%
Network Engineer 3 -- -- -- 2%
Espresso Application Dev 10% 10% 10% 10%
Espresso Application Dev 2 -- -- 10% 10%
Espresso Application Dev 3 -- -- -- 10%
Database Developer 5% 5% 5% 5%
Database Developer 2 -- -- -- 5%
Information Security Officer 5% 5% 5% 5%
Database Administrator -- 5% 5% 5%
Database Administrator 2 -- -- -- 5%
gTLDFull Legal NameE-mail suffixDetail
.BASKETBALLFédération Internationale de Basketball (FIBA)gmail.comView
Question 26 Whois
26.1 --A HIGH-LEVEL WHOIS SYSTEM DESCRIPTION--
The registry will operate a Whois service on Port 43 according to Specification 4 and in accordance with RFC 3912. The registry will also provide a free public query-based directory service on the web at http:⁄⁄whois.nic.basketball. The Whois directory will display domain name, registrar, and nameserver data. The fields will be formatted to conform to the mappings specified in EPP RFCs 5730, 5731, 5732, 5733 and 5734.

The Whois directory will support standard and Boolean searches (including AND, OR and NOT logical operators). Search results will include domain names matching the search criteria. We will implement appropriate measures to avoid abuse of the feature and ensure that the feature is in compliance with any applicable privacy laws or policies.

We will offer searchability on the web-based Directory Service. We will offer partial match capabilities on the following fields: domain name, contacts and registrant’s name, and contact and registrant’s full postal address. We will offer exact match capabilities on the following fields: registrar ID, nameserver name, and nameserver’s IP address for in-zone hosts (glue records).

The user will choose one or more search criteria, combine them by Boolean operators (AND, OR, NOT) and provide partial or exact match regular expressions for each of the criterion name-value pairs. The domain names matching the search criteria will be returned to the user.

Mitigation against abuse is achieved via black⁄white listing of IP addresses of known parties. We also configure a maximum hit threshold per IP range. The threshold applies to hits within a certain time, both from a single IP and a network.

Our Whois service meets Specifications 4 and 10 of the new gTLD Registry Agreement:
- Whois service available via port 43 in accordance with RFC 3912, and a web-based Directory Service at whois.nic.basketball providing free public query-based access.
- The format of responses follows a semi-free text format, followed by a blankline and a legal disclaimer specifying the rights of Registry Operator, and of the user querying the database.
- Each data object is be represented as a set of key⁄value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value.
- For fields where more than one value exists, multiple key⁄value pairs with the same key shall be allowed (for example to list multiple name servers). The first key⁄value pair after a blank line should be considered the start of a new record, and should be considered as identifying that record, and is used to group data, such as hostnames and IP addresses, or a domain name and registrant information, together.
- RDDS availability SLA
- RDDS update time SLA
- RDDS query RTT SLA

Whois output meets the requirements listed in Specification 4 (Registration Data Publication Services). Additionally, each field can be toggled on or off for display on a per-zone basis to ensure compliance with any applicable privacy laws or policies. In other words, the Whois can be configured to accommodate more stringent privacy policies than the full disclosure that is possible. We will comply with Specification 4 such that the data objects listed will be displayed for public Whois records as follows:

Domain Name Data Objects:
Domain Name
Domain ID
Whois Server
Referral URL
Updated Date
Creation Date
Expiration Date
Sponsoring Registrar
Sponsoring Registrar IANA ID
Status
DNSSEC
Registrant Data Objects:
Registrant ID
Registrant Name
Registrant Organization
Registrant Street1
Registrant City
Registrant State⁄Province
Registrant Postal Code
Registrant Country
Registrant Phone
Registrant Phone Ext
Registrant Fax
Registrant Fax Ext
Registrant Email
Admin Contact Data Objects:
Admin ID
Admin Name
Admin Organization
Admin Street1
Admin City
Admin State⁄Province
Admin Postal Code
Admin Country
Admin Phone
Admin Phone Ext
Admin Fax
Admin Fax Ext
Admin Email
Tech Contact Data Object:
Tech ID
Tech Name
Tech Organization
Tech Street
Tech City
Tech State⁄Province
Tech Postal Code
Tech Country
Tech Phone
Tech Phone Ext
Tech Fax
Tech Fax Ext
Tech Email
Registrar Data Objects:
Registrar Name
Address fields
Phone Number
Fax Number
Whois Server
Referral URL
Admin Contact
Phone Number
Fax Number
Email
Technical Contact
Phone Number
Fax Number
Email
Last update of Whois database
Nameserver Data Objects:
Server Name
IP Addresses
Registrar
Whois Server
Referral URL
Last update of Whois database

In addition to the RFC-compliant functions, the system allows character sets that are not ASCII as additional Whois display fields (Local Language contact details).

The registry system will implement abuse-prevention measures, such as white-listing contracted registrars’ IP address ranges for search, black-listing known bad-actors or previous violators, and capping the number of Whois searches possible during a time frame.

The registry administration will comply with applicable laws and policies regarding privacy (see Question 28: Abuse Prevention and Mitigation). The registry, in conjunction with the Vice President for Policy of Minds + Machines, will balance the ICANN Whois data display requirements with local laws, and will ensure compliance by users through enforcement of registration policies.

Third party access to zone files will be provided according to the requirements detailed in Section 2 of Specification 4. The zone files will match the file format standard, and use of data by users will only be permitted for lawful purposes. Bulk access to the zone files will be provided to ICANN and Emergency Operators as specified.

Thin registration data (domain name, registrar, Whois server, referral URL, nameservers, status, update date, creation date and expiration date) access will be granted to ICANN periodically, and thick registration data will be made available in case of a registrar failure.

The registry Whois service complies with RFC 3912 by listening on TCP port 43 for requests from Whois clients. Anyone with Internet access can use the Whois portal to check the registration data for a domain name. The Whois server replies with text content, and terminates in ASCII. As soon as the output is finished the Whois server closes the connection to the client.
--RESOURCE ALLOCATION--
The registry system, Espresso, is already in operation and regularly supports Whois requests for current TLDs. The Minds + Machines software development team will update the registry system code to meet IETF Whois RFC specifications as necessary. Since the Whois function is already built and operational, the software development team allocates personnel resources as needed when changes are required.

26.2 Relevant network diagram: Please see the attached diagram, “Q 26 Whois,” which shows the interrelationships of the Whois with the internal and external registry components.

26.3 --IT AND INFRASTRUCTURE RESOURCES--
The technical resources required to run Whois are adequate, on hand, committed, and readily available. The registry will operate two instances of Whois at the primary registry location, one primary and one hot standby backup; and another two Whois servers at the secondary location.

In the event of failure of one hardware component at the primary registry location, the backup server will handle all transactions until the failed server becomes available again. For further details about failover of Whois, see Question 39: Registry Continuity and Question 41: Failover. Any fail-over of the application or Whois service will not affect registrar transactions as fail-over testing has proven only seconds of downtime.

26.4 --INTERCONNECTIVITY WITH OTHER REGISTRY SYSTEMS--
Connectivity between the Internet, the Primary Site, and the Secondary Remote Site is via multiple redundant connections, as further described in Question 32: Architecture. In addition, connections between servers on the internal Registry Network are via redundant multi-homed 1 Gbps Ethernet. Connectivity between the primary and secondary registry facility (for replication) is via redundant SSH connections. In addition, a third data backup in a remote location is connected for disaster recovery.

High capacity routers and switches are used to route traffic to registry services (see response to Question 32: Architecture). Load balancing is used to distribute load across resources.

Internet connectivity will be supplied via a 100Mbps solution with fully diverse connections to multiple Internet service providers. Further details can be found in Question 32: Architecture and Question 35: DNS. The Registry Internet connections at both the Primary and Secondary Sites will be provisioned to support burstable 1 Gbps capacity.

When an update, for example, to a domain registrant record is made to the registry database, Whois automatically reflects these changes because it is an element of the overall SRS. There is never inaccuracy of the published data because of this configuration.

26.5 --DATACENTER CONNECTIVITY--
Our primary datacenter is at a co-location facility hosted by IX2, in Los Angeles, US. At the core of all IX2 connectivity, IX2 owns and maintains redundant 432+ strand Corning single-mode dark fiber. The redundant fiber traverses diverse paths to and from multiple IX2 datacenters including IX2ʹs space in One Wilshire Buildingʹs ʺMeet-Me-Roomʺ and adjacent buildings occupied by IX2. IX2 also has direct dark-fiber to multiple Tier 1 carriers (Level3, Cogent, AT&T, Verizon, etc.) as well as low-hop connectivity to hundreds of ISP backbone networks. Many Tier 1 providers also co-locate within IX2ʹs datacenters. Over IX2ʹs fiber connections, IX2 can transport many types of circuits from; TDM OC192 Sonet, to 10Gig Ethernet, down to TDM T1, to 10⁄100 FastEthernet.

Our secondary datacenter, managed by Tucows at Q9, in Brampton, CA, is directly connected to major Internet backbones and regional ISPs available in the vicinity of the Q9 datacenter. In addition, Q9 has a 1Gb Fibre connection to 151 Front (co-location facility) and a 1Gb Fibre connection to Tucows’ main office at 96 Mowat Ave. The office at 96 Mowat Ave has a 1Gb Fibre connection to 151 Front (co-location facility) creating a 3 x 1Gb triangle between the Q9 datacenter, 151 Front and 96 Mowat. At the Q9 datacenter, Tucows has a 1Gb Internet connection to Allstream. At the 151 Front, Tucows has a 1Gb Internet connection with Cogent and a 1Gb Internet connection with Level3. Tucows peers with TORIX and Rogers at 151 Front and, if needed, can aggregate up to 3Gb of Internet traffic to the Q9 datacenter via the 2 x 1Gb links to 151 Front and 96 Mowat + 1 Gb from Allstream. Tucows currently owns all its IP blocks, has its own ASN and BGP configuration and retains full control of peering and IP space. Tucows is fully autonomous and do not rely on third parties to provide or manage network peering capabilities.

Tucows maintains a dedicated, high-speed, low-latency, path-diverse network between its facilities in each geographic region. These regional networks are used to provide reliable, cost-effective connectivity based in different Tucows datacenters within the same region.

The secondary datacenter provides customers with a redundant Internet connection, a 100 per cent availability SLA and the flexibility to scale to higher bandwidth requirements.

Q9 maintains a dedicated, high-speed, low-latency path-diverse network between its facilities in each geographic region. These regional networks are used to provide reliable, cost-effective connectivity for customers with multi-site solutions based in different Q9 datacenters within the same region. Solutions range from traditional switched Ethernet to dedicated wavelengths.

26.6 --FREQUENCY OF SYNCHRONIZATION BETWEEN SERVERS--
Updates from the SRS to the Whois servers happens in real-time via an asynchronous publish⁄subscribe messaging architecture. These are updated in each slave within the required SLA of 95% ≤ 60 minutes. See Question 30: Security and Question 32: Architecture for further details.

26.7 --POTENTIAL FORMS OF ABUSE OF SEARCHABLE WHOIS, AND MITIGATION--
Because the IETF Whois protocol has no provisions for strong security, the Whois directory service is vulnerable to abuse of access control, integrity, and confidentiality. The registry system Espresso features several functions to mitigate data mining, server overload, and access abuse, as explained below.

The web interface for Whois can be configured through the Espresso Registry administrative area. CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) is used on the web form to mitigate data mining. Network and IP limits are configurable to prevent overloading the Whois server with malicious or extraneous requests. Whois look-ups will be set to 100 requests every 60 minutes for unknown IP ranges. Network limits will be set to 1000 request every 1440 minutes for unknown networks. When the limits are reached, the requests will be restricted and a message will be displayed notifying the user that the limit has been reached. The message also provides instructions to the user to contact the registry if they would like to have their IP or Network range white-listed. Whois request records will be archived, in order to provide law enforcement officials with any necessary information they require for enforcement.

A blacklist is used to block IP addresses or networks of known bad actors. Similarly, a white list may be used to allow trusted users greater Whois look-up access. Terms of use will be displayed on the Whois interface, notifying all users of the terms and conditions for access to the Whois database.

The registry system logs all Whois queries. A server status field displays the number of active requests for a specified time range. The request logs can be searched by the minute, hour, day, month, year, and since delegation. These logs can be output and downloaded as comma-separated value (CSV) files and subsequently used to generate any type of report required.

The Whois server is constantly monitored to ensure 100% uptime. The monitoring tool outputs reports showing the number of queries, and response rates over variable time periods. Whois service will be in full compliance with the final specification of ICANN’s Registration Data Publication Services Document.

26.8 --RESOURCE ALLOCATION--
The SRS registry system, Espresso, is already operational and regularly supports Whois requests for the current TLD operated by Minds + Machines, .FM. The software development team will update the registry system code to meet IETF WHOIS RFC specifications as necessary. The CTO allocates personnel resources as needed to maintain the Whois infrastructure, and to update the code and hardware when changes are required. The Network Operations Managers and technical staff maintain the hardware that supports the Whois function. The Database Developers and Administrators ensure that the Whois element of the application is able to access real-time data from the registry database. The Director of Legal Affairs and the compliance administrator assures that the Whois function and data displayed complies with ICANN consensus policy, privacy policies, and applicable laws and regulations. The Registrar Customer Service technical support personnel assist registrars with Whois access, including white-listing known and trusted IP ranges.

Our registry functions are outsourced to Minds + Machines. Their staff resource allocation follows. All costs associated with the technical functioning of the registry are covered by Minds + Machines as per our contract with them. Please see the attachment to “Q 24 Staff” for complete descriptions of each staff position.

Title Startup Yr1 Yr2 Yr3
----- ------- --- --- ---
CTO 2% 2% 2% 2%
Director Legal Affairs 2% 2% 2% 2%
Compliance Administrator -- 5% 5% 5%
Registrar CS Tech 1 2% 2% 2% 2%
Registrar CS Tech 2 -- -- 2% 2%
Network Operations Mgr 2% 2% 2% 2%
Network Engineer 1 2% 2% 2% 2%
Network Engineer 2 -- -- 2% 2%
Network Engineer 3 -- -- -- 2%
Espresso Application Dev 10% 10% 10% 10%
Espresso Application Dev 2 -- -- 10% 10%
Espresso Application Dev 3 -- -- -- 10%
Database Developer 5% 5% 5% 5%
Database Developer 2 -- -- -- 5%
Information Security Officer 5% 5% 5% 5%
Database Administrator -- 5% 5% 5%
Database Administrator 2 -- -- -- 5%