Back

26 Whois

gTLDFull Legal NameE-mail suffixDetail
.اتصالاتEmirates Telecommunications Corporation (trading as Etisalat)centralnic.comView
Except where specified this answer refers to the operations of the Applicantʹs outsource Registry Service Provider, CentralNic.

Whois is one of the oldest Internet protocols still in use. It allows interested persons to retrieve information relating to Internet resources (domain names and IP addresses). Whois services are operated by the registries of these resources, namely TLD registries and RIRs.

Whois is described by RFC 3912, which serves as a description of existing systems rather than requiring specific behaviours from clients and servers. The protocol is a query-response protocol, in which both the query and the response are opaque to the protocol, and their meanings are known only the server and to the human user who submits a query. Whois has a number of limitations, but remains ubiquitous as a means for obtaining information about name and number resources.


26.1. Compliance

The Whois service for the TLD will comply with RFC3912 and Specifications 4 and 10 of the New gTLD Registry Agreement. The service will be provided to the general public at no cost. If ICANN specify alternative formats and protocols (such as WEIRDS) then CentralNic will implement these as soon as reasonably practicable.

CentralNic will monitor its Whois system to confirm compliance. Monitoring stations will check the behaviour and response of the Whois service to ensure the correctness of Whois records. CentralNic will maintain a public Whois contact to which bug reports and other questions about the Whois service can be directed.

The Whois service will additionally comply with all requisite data protection laws (with regards to the collection and retention of personal data), including all relevant European Union privacy directives.

26.2. Domain Name

By default, any query is assumed to be a domain name unless a keyword is prepended to the query. If the domain exists, then registration is returned, including the following fields:

Domain ROID
Domain Name
Domain U-label (if IDN)
Creation Date
Last Updated
Expiration Date
EPP status codes
Registrant Contact Information
Administrative Contact Information
Technical Contact Information
Billing Contact Information (if any)
Sponsoring Registrar ID
Sponsoring Registrar Contact Information
DNS servers (if any)
DNSSEC records (if any)
An example of a domain whois response is included in Appendix 26.1. The Domain ROID is the Repository Object Identifier as described in RFC 5730, §2.8. The ROID field corresponds to the “domain:roid” element of EPP “info” responses.

A domain may be associated with one or more status codes. These are represented in Whois responses as phrases rather than EPP mnemonics. A domain may have any of the following status codes:

PENDING CREATE - a “domain:create” command has been received through the SRS, but the registration has not yet been finalised as an out-of-band review process has not yet been completed.
ADD PERIOD - the domain is in the Add Grace Period
CLIENT HOLD - the registrar has added the clientHold status
DELETE PROHIBITED - this may be present if the domain has either clientDeleteProhibited or serverDeleteProhibited (or both)
INACTIVE - the domain has no DNS servers
PENDING DELETE - the domain has left the Redemption Grace Period and is scheduled for deletion
PENDING DELETE RESTORABLE - the domain is in the Redemption Grace Period
PENDING RESTORE - a restore request has been received, but the Restore Report has not been received
PENDING TRANSFER - there is an active inter-registrar transfer for the domain
RENEW PERIOD - the domain is either in the Renew Grace Period or the Auto-Renew Grace Period
RENEW PROHIBITED - this may be present if the domain has either clientRenewProhibited or serverRenewProhibited (or both)
SERVER HOLD - the registry has added the serverHold status
TRANSFER PERIOD - the domain is in the Transfer Grace Period
TRANSFER PROHIBITED - this may be present if the domain has either clientTransferProhibited or serverTransferProhibited (or both)
UPDATE PROHIBITED - this may be present if the domain has either clientUpdateProhibited or serverUpdateProhibited (or both)
OK - present if none of the above apply.
The Registrant, Administrative, Technical and Billing Contact sections of the Whois record display the contact information for the contact objects that are associated with the domain. The information displayed replicates the information showed for a contact query (see below). The server shows similar information for the sponsoring registrar.

Domains may have 0-13 DNS servers. If a domain name has no DNS servers, then the ʺINACTIVEʺ status code appears in the Status section. If the registrant provided DS records for their DNSSEC-signed domain, then these are included. For each DS record, then the key tag, algorithm, digest type and digest are displayed.


26.3. Contact

Users can query for information about a contact by submitting a query of the form ʺcontact [ID]ʺ, where ʺ[ID]ʺ is the contact ID equivalent to the “contact:id” element in EPP “info” responses. This is also the ID used when referring to contacts in domain responses.

The following information is included in Dontact records:

Contact ID
Sponsoring Registrar
Creation Date
Last Updated Date
EPP Status Codes
Contact Name
Organisation
Street Address (1-3 fields)
City
State⁄Province
Postcode
Country Code (2 character ISO-3166 code)
Phone number (e164a format)
Fax number (e164a format)
Email address
An example of a contact object whois response is included in Appendix 26.2. A contact object may be associated with one or more status codes. These are represented in Whois responses as phrases rather than EPP code mnemonics. A contact object may have any of the following status codes:

DELETE PROHIBITED - present if the contact object has either clientDeleteProhibited or serverDeleteProhibited (or both)
TRANSFER PROHIBITED - present if the contact object has either clientTransferProhibited or serverTransferProhibited (or both)
UPDATE PROHIBITED - present if the contact object has either clientUpdateProhibited or serverUpdateProhibited (or both)
PENDING TRANSFER - there is an active inter-registrar transfer for the contact object
LINKED - the contact object is associated with one or more domain names. A LINKED contact object automatically has the DELETE PROHIBITED status

26.4. Host Objects

Users can query for information about a host object by submitting a query of the form ʺnameserver [HOST]ʺ. The following information is included in host records:

Server Name
IPv4 address (if any)
IPv6 address (if any)
EPP status codes
Sponsoring Registrar
Creation Date
Referral URL (if any)
An example of a host whois response is included in Appendix 26.3. A host object may have an IPv4 or IPv6 address if the host is ʺin-bailiwickʺ, ie subordinate to a domain name within a TLD operated by the registry. IP address information is not shown for ʺout-of-bailiwickʺ hosts.

Host objects may only have two status codes:

INACTIVE - the host is not associated with any domain names
LINKED - the host is associated with one or more domain names
The Referral URL is the website of the Sponsoring Registrar for this host. If the host is subordinate to a domain name in the TLD, this will be the sponsoring registrar of the parent name. If the host is out-of-bailiwick, then the sponsoring registrar is the registrar who issued the original “create” request.


26.5. Character Encoding

Responses are encoded as UTF-8. Queries are assumed to be encoded in UTF-8.


26.6. IDN Support

The Whois service supports Internationalised Domain Names. Users may submit queries for IDN domains using either the U-label or the A-label.


26.7. Bulk Access

CentralNic will provide up-to-date registration data to ICANN on a weekly basis (the day to be designated by ICANN). CentralNic will provide the following data for all registered domain names: domain name, repository object id (roid), registrar id (IANA ID), statuses, last updated date, creation date, expiration date, and name server names. For sponsoring registrars it will provide: registrar name, registrar repository object id (roid), hostname of registrar Whois server, and URL of registrar. Data will be provided in the format specified in Specification 2 for Data Escrow (including encryption, signing, etc.) but including only the fields mentioned in the above.

At ICANNʹs request, CentralNic will provide ICANN with up-to-date data for the domain names of de-accredited registrar to facilitate a bulk transfer. The data will be provided in the format specified in Specification 2 for Data Escrow. The file will only contain data related to the domain names of the losing registrar. CentralNic will provide the data within 2 business days.


26.8. Load Projections

As described in §31, CentralNicʹs existing Whois system receives an average of 0.36 queries per day for each domain name in the registry, including misses for non-existent objects as well as hits.

The number of daily queries per domain for each existing gTLD was calculated using figures for the month of November 2011 published by ICANN. This analysis may be found in Appendix 26.6. It shows little correlation between the number of domains in the TLD and the number of queries that each domain receives. Smaller gTLDs such as .aero and .museum receive more queries per domain than larger gTLDs, but .jobs (which is much larger than either .aero or .museum) received more queries per domain than either. It should be noted that the high volumes observed for .XXX are very likely due to activities surrounding the Landrush and initial launch of that TLD.

CentralNic believes that the query rate observed for its own registry system is mainly affected by its efforts to deter abuse, and outreach to registrars, who often use whois to perform availability checks, to encourage them to EPP instead. CentralNic believes this query rate will also apply for the TLD. A projection of query load for the Whois system for the first 24 months of operation can be found in Appendix 26.4. This model also includes data transit rates and bandwidth projections for the same period. As can be seen, the data and bandwidth requirements are relatively small compared to those for the Shared Registry System and authoritative DNS.


26.9. Technical Implementation

A diagram describing the infrastructure supporting the Whois service may be found in Figure 26.1. During normal operations, the Whois service is operated at the primary operations centre in London. During failover conditions, it is operated at the Disaster Recovery site in the Isle of Man (see §34).

Queries pass through the firewalls to one of two front-end load balancers. Round-robin DNS distributes queries between the devices. Load balancers are configured in High Availability mode so that if one a server fails, the other will resume service on its IP address until the server can be restored. Queries are distributed to backend application servers via weighted least connections algorithm.


26.9.1. Application Server Architecture

Application servers are built on commodity hardware running CentOS. The service is provided using the mod_whois Apache module (see http:⁄⁄modwhois.sf.net⁄) which causes Apache to listen on port 43 and accept queries, which are then handled using a PHP script, which generates and returns the response.


26.9.2. Caching

Application servers use caching to reduce database load. Subsequent identical queries are returned a cached record until the cache expires, after which a new record is generated. Records are currently cached for 600 seconds (ten minutes), so if a domain is updated immediately after its Whois record has been cached, the updated record will be visible after ten minutes. This compares favourably to the 60 minute requirement in the gTLD Service Level Agreement. Records are cached in a shared Memached server. Memcached is a high-performance caching server used by some of the largest sites in the world, including Wikipedia, Flickr, Wordpress.com and Craigslist.


26.9.2. Database

The Whois service draws data directly from the primary database. The query volume required to sustain the Whois service is comparable to that of a modest web application such as a small e-commerce site, and as a result a dedicated database for the Whois system is not required. As can be seen in Figure 26.1, a separate logging database is used to aggregate log data for use with the rate limiting system.


26.10. Web based Whois Service

CentralNic provides a web interface to the Whois service on its website. In addition, Applicant will provide a similar service on the TLD registry website. The web Whois acts as a proxy to the port 43 Whois service: users enter a query into a form, and a server-side process submits the query to the Whois server, and displays the response. This service will not be subjected to the rate limiting described above, but users will be required to complete a CAPTCHA to prevent high-volume automated access.


26.11. Searchable Whois Service

Applicant will provide a Searchable Whois Service (SWS). This service will be made available on the TLD website. The SWS provides third parties with a search interface that allows queries for partial matches against a number of domain name properties, including:

domain name (partial match)
registrant name, organisation, address, email
administrative, technical and billing contact information
Nameservers
Nameserver IPv4⁄IPv6 address
Access to the SWS is restricted. Users must submit an account request via the website, and agree to the terms and conditions which governs their access to the the system. These terms are included as Appendix 26.5. Once their request has been reviewed and approved, they are issued with credentials which permit them to login to the SWS.

To prevent abuse of the SWS, users may only make fifty queries per day initially. This limit can be increased upon request and demonstration of legitimate need.


26.12. Anti-Abuse Mechanisms

CentralNic has implemented measures to mitigate the threat of abuse of the Whois service. The primary threat to the Whois service are so-called ʺdictionaryʺ attacks, where an attacker attempts to enumerate the database by flooding the server with queries for domains taken from a precompiled list: as zone files are easy to obtain, this presents a threat to the privacy of contact information in the registry database. The information harvested can be used to compile email databases for spamming, or to send domain renewal scam letters, for example.

The Whois service implements rate-limiting to impede dictionary attacks. For each query, a counter associated with the client IP address is incremented. For subsequent queries, this counter determines the number of queries received within the previous hour. If the number of queries exceeds a pre-set maximum (currently 240 queries per hour), then the server returns an error, warning the user that they have exceeded the permitted query rate. If the user stops sending queries, then eventually the query rate will drop below the limit, and subsequent queries will be permitted. If the user continues to send queries, and the query rate exceeds the limit by a further 25% (300 queries per hour), then the IP address is permanently blocked. For queries over IPv6 (where an attacker might have access to billions of IP addresses), the enclosing ⁄48 will be blocked.

Experience indicates that is an effective mechanism for preventing abuse of the Whois. The rate limit has been tuned to ensure that legitimate uses of the Whois are allowed, but abusive use of the whois is restricted to levels which are unappealing for attackers.

CentralNic keeps a ʺwhite listʺ of IP addresses used by legitimate users of the Whois service, including law enforcement agencies and other research and anti-abuse entities. Registrar access lists are also incorporated into the white list, and IP addresses registered on ICANNʹs RADAR system will also be included. Queries from IP addresses that appear on the white list are not rate-limited. Interested parties can request addition to the white list by contacting CentralNicʹs public customer service team.

The web-based Whois does not implement rate-limiting, but users of this service must complete a CAPTCHA to access Whois records.


26.12.1. Denial-of-Service attacks

The rate-limiting system in place provides protection against DoS and DDoS attacks, as any host that attempts to flood the Whois service with queries will be quickly blocked. However, a DDoS attack could still saturate upstream links requiring filtering at the edges of CentralNicʹs network, as well as their upstream providers. Continuous surveillance and monitoring of the Whois system (see §42) proactively detects these threats. As the Whois service directly queries the primary SRS database, CentralNic rate-limits on the database backend to prevent an attack against the Whois service from disrupting the SRS.


26.13. Monitoring and Logging

Remote monitoring is used to verify the availability of the service and to record the round-trip times for different queries (warm hit, warm miss). Local monitoring records query volumes.


26.14. Resourcing

As can be seen in the Resourcing Matrix found in Appendix 23.2, CentralNic will maintain a team of full-time developers and engineers which will contribute to the development and maintenance of this aspect of the registry system. These developers and engineers will not work on specific subsystems full-time, but a certain percentage of their time will be dedicated to each area. The total HR resource dedicated to this area is equivalent to almost one full-time person (83%.

CentralNic operates a shared registry environment where multiple registry zones (such as CentralNicʹs domains, the .LA ccTLD, this TLD and other gTLDs) share a common infrastructure and resources. Since the TLD will be operated in an identical manner to these other registries, and on the same infrastructure, then the TLD will benefit from an economy of scale with regards to access to CentralNicʹs resources.

CentralNicʹs resourcing model assumes that the ʺdedicatedʺ resourcing required for the TLD (ie, that required to deal with issues related specifically to the TLD and not to general issues with the system as a whole) will be equal to the proportion of the overall registry system that the TLD will use. After three years of operation, the optimistic projection for the TLD states that there will be 1000 domains in the zone. CentralNic has calculated that, if all its TLD clients are successful in their applications, and all meet their optimistic projections after three years, its registry system will be required to support up to 4.5 million domain names. Therefore the TLD will require 0.1% of the total resources available for this area of the registry system.

In the event that registration volumes exceed this figure, CentralNic will proactively increase the size of the Technical Operations, Technical Development and support teams to ensure that the needs of the TLD are fully met. Revenues from the additional registration volumes will fund the salaries of these new hires. Nevertheless, CentralNic is confident that the staffing outlined above is sufficient to meet the needs of the TLD for at least the first 18 months of operation.
gTLDFull Legal NameE-mail suffixDetail
.designTop Level Design, LLCgmail.comView
Except where specified this answer refers to the operations of Top Level Design, LLCʹs outsource Registry Service Provider, CentralNic.

Whois is one of the oldest Internet protocols still in use. It allows interested persons to retrieve information relating to Internet resources (domain names and IP addresses). Whois services are operated by the registries of these resources, namely TLD registries and RIRs.

Whois is described by RFC 3912, which serves as a description of existing systems rather than requiring specific behaviours from clients and servers. The protocol is a query-response protocol, in which both the query and the response are opaque to the protocol, and their meanings are known only the server and to the human user who submits a query. Whois has a number of limitations, but remains ubiquitous as a means for obtaining information about name and number resources.

26.1. Compliance
The Whois service for the TLD will comply with RFC3912 and Specifications 4 and 10 of the New gTLD Registry Agreement. The service will be provided to the general public at no cost. If ICANN specify alternative formats and protocols (such as WEIRDS) then CentralNic will implement these as soon as reasonably practicable.

CentralNic will monitor its Whois system to confirm compliance. Monitoring stations will check the behaviour and response of the Whois service to ensure the correctness of Whois records. CentralNic will maintain a public Whois contact to which bug reports and other questions about the Whois service can be directed.

26.2. Domain Name
By default, any query is assumed to be a domain name unless a keyword is prepended to the query. If the domain exists, then registration is returned, including the following fields:
• Domain ROID
• Domain Name
• Domain U-label (if IDN)
• Creation Date
• Last Updated
• Expiration Date
• EPP status codes
• Registrant Contact Information
• Administrative Contact Information
• Technical Contact Information
• Billing Contact Information (if any)
• Sponsoring Registrar ID
• Sponsoring Registrar Contact Information
• DNS servers (if any)
• DNSSEC records (if any)

An example of a domain whois response is included in Appendix 26.1. The Domain ROID is the Repository Object Identifier as described in RFC 5730, §2.8. The ROID field corresponds to the ʺdomain:roidʺ element of EPP ʺinfoʺ responses.

A domain may be associated with one or more status codes. These are represented in Whois responses as phrases rather than EPP mnemonics. A domain may have any of the following status codes:
• PENDING CREATE - a ʺdomain:createʺ command has been received through the SRS, but the registration has not yet been finalised as an out-of-band review process has not yet been completed.
• ADD PERIOD - the domain is in the Add Grace Period
• CLIENT HOLD - the registrar has added the clientHold status
• DELETE PROHIBITED - this may be present if the domain has either clientDeleteProhibited or serverDeleteProhibited (or both)
• INACTIVE - the domain has no DNS servers
• PENDING DELETE - the domain has left the Redemption Grace Period and is scheduled for deletion
• PENDING DELETE RESTORABLE - the domain is in the Redemption Grace Period
• PENDING RESTORE - a restore request has been received, but the Restore Report has not been received
• PENDING TRANSFER - there is an active inter-registrar transfer for the domain
• RENEW PERIOD - the domain is either in the Renew Grace Period or the Auto-Renew Grace Period
• RENEW PROHIBITED - this may be present if the domain has either clientRenewProhibited or serverRenewProhibited (or both)
• SERVER HOLD - the registry has added the serverHold status
• TRANSFER PERIOD - the domain is in the Transfer Grace Period
• TRANSFER PROHIBITED - this may be present if the domain has either clientTransferProhibited or serverTransferProhibited (or both)
• UPDATE PROHIBITED - this may be present if the domain has either clientUpdateProhibited or serverUpdateProhibited (or both)
• OK - present if none of the above apply.

The Registrant, Administrative, Technical and Billing Contact sections of the Whois record display the contact information for the contact objects that are associated with the domain. The information displayed replicates the information showed for a contact query (see below). The server shows similar information for the sponsoring registrar.

Domains may have 0-13 DNS servers. If a domain name has no DNS servers, then the ʺINACTIVEʺ status code appears in the Status section. If the registrant provided DS records for their DNSSEC-signed domain, then these are included. For each DS record, then the key tag, algorithm, digest type and digest are displayed.

26.3. Contact
Users can query for information about a contact by submitting a query of the form ʺcontact [ID]ʺ, where ʺ[ID]ʺ is the contact ID equivalent to the ʺcontact:idʺ element in EPP ʺinfoʺ responses. This is also the ID used when referring to contacts in domain responses.

The following information is included in Dontact records:
• Contact ID
• Sponsoring Registrar
• Creation Date
• Last Updated Date
• EPP Status Codes
• Contact Name
• Organisation
• Street Address (1-3 fields)
• City
• State⁄Province
• Postcode
• Country Code (2 character ISO-3166 code)
• Phone number (e164a format)
• Fax number (e164a format)
• Email address

An example of a contact object whois response is included in Appendix 26.2. A contact object may be associated with one or more status codes. These are represented in Whois responses as phrases rather than EPP code mnemonics. A contact object may have any of the following status codes:
• DELETE PROHIBITED - present if the contact object has either clientDeleteProhibited or serverDeleteProhibited (or both)
• TRANSFER PROHIBITED - present if the contact object has either clientTransferProhibited or serverTransferProhibited (or both)
• UPDATE PROHIBITED - present if the contact object has either clientUpdateProhibited or serverUpdateProhibited (or both)
• PENDING TRANSFER - there is an active inter-registrar transfer for the contact object
• LINKED - the contact object is associated with one or more domain names. A LINKED contact object automatically has the DELETE PROHIBITED status

26.4. Host Objects
Users can query for information about a host object by submitting a query of the form ʺnameserver [HOST]ʺ. The following information is included in host records:
• Server Name
• IPv4 address (if any)
• IPv6 address (if any)
• EPP status codes
• Sponsoring Registrar
• Creation Date
• Referral URL (if any)

An example of a host whois response is included in Appendix 26.3. A host object may have an IPv4 or IPv6 address if the host is ʺin-bailiwickʺ, ie subordinate to a domain name within a TLD operated by the registry. IP address information is not shown for ʺout-of-bailiwickʺ hosts.

Host objects may only have two status codes:
• INACTIVE - the host is not associated with any domain names
• LINKED - the host is associated with one or more domain names

The Referral URL is the website of the Sponsoring Registrar for this host. If the host is subordinate to a domain name in the TLD, this will be the sponsoring registrar of the parent name. If the host is out-of-bailiwick, then the sponsoring registrar is the registrar who issued the original ʺcreateʺ request.

26.5. Character Encoding
Responses are encoded as UTF-8. Queries are assumed to be encoded in UTF-8.

26.6. IDN Support
The Whois service supports Internationalised Domain Names. Users may submit queries for IDN domains using either the U-label or the A-label.

26.7. Bulk Access
CentralNic will provide up-to-date registration data to ICANN on a weekly basis (the day to be designated by ICANN). CentralNic will provide the following data for all registered domain names: domain name, repository object id (roid), registrar id (IANA ID), statuses, last updated date, creation date, expiration date, and name server names. For sponsoring registrars it will provide: registrar name, registrar repository object id (roid), hostname of registrar Whois server, and URL of registrar. Data will be provided in the format specified in Specification 2 for Data Escrow (including encryption, signing, etc.) but including only the fields mentioned in the above.

At ICANNʹs request, CentralNic will provide ICANN with up-to-date data for the domain names of de-accredited registrar to facilitate a bulk transfer. The data will be provided in the format specified in Specification 2 for Data Escrow. The file will only contain data related to the domain names of the losing registrar. CentralNic will provide the data within 2 business days.

26.8. Load Projections
As described in §31, CentralNicʹs existing Whois system receives an average of 0.36 queries per day for each domain name in the registry, including misses for non-existent objects as well as hits.

The number of daily queries per domain for each existing gTLD was calculated using figures for the month of November 2011 published by ICANN. This analysis may be found in Appendix 26.6. It shows little correlation between the number of domains in the TLD and the number of queries that each domain receives. Smaller gTLDs such as .aero and .museum receive more queries per domain than larger gTLDs, but .jobs (which is much larger than either .aero or .museum) received more queries per domain than either. It should be noted that the high volumes observed for .XXX are very likely due to activities surrounding the Landrush and initial launch of that TLD.

CentralNic believes that the query rate observed for its own registry system is mainly affected by its efforts to deter abuse, and outreach to registrars, who often use whois to perform availability checks, to encourage them to EPP instead. CentralNic believes this query rate will also apply for the TLD. A projection of query load for the Whois system for the first 24 months of operation can be found in Appendix 26.4. This model also includes data transit rates and bandwidth projections for the same period. As can be seen, the data and bandwidth requirements are relatively small compared to those for the Shared Registry System and authoritative DNS.

26.9. Technical Implementation
A diagram describing the infrastructure supporting the Whois service may be found in Figure 26.1. During normal operations, the Whois service is operated at the primary operations centre in London. During failover conditions, it is operated at the Disaster Recovery site in the Isle of Man (see §34).

Queries pass through the firewalls to one of two front-end load balancers. Round-robin DNS distributes queries between the devices. Load balancers are configured in High Availability mode so that if one a server fails, the other will resume service on its IP address until the server can be restored. Queries are distributed to backend application servers via weighted least connections algorithm.

26.9.1. Application Server Architecture
Application servers are built on commodity hardware running CentOS. The service is provided using the mod_whois Apache module (see http:⁄⁄modwhois.sf.net⁄) which causes Apache to listen on port 43 and accept queries, which are then handled using a PHP script, which generates and returns the response.

26.9.2. Caching
Application servers use caching to reduce database load. Subsequent identical queries are returned a cached record until the cache expires, after which a new record is generated. Records are currently cached for 600 seconds (ten minutes), so if a domain is updated immediately after its Whois record has been cached, the updated record will be visible after ten minutes. This compares favourably to the 60 minute requirement in the gTLD Service Level Agreement. Records are cached in a shared Memached server. Memcached is a high-performance caching server used by some of the largest sites in the world, including Wikipedia, Flickr, Wordpress.com and Craigslist.

26.9.2. Database
The Whois service draws data directly from the primary database. The query volume required to sustain the Whois service is comparable to that of a modest web application such as a small e-commerce site, and as a result a dedicated database for the Whois system is not required. As can be seen in Figure 26.1, a separate logging database is used to aggregate log data for use with the rate limiting system.

26.10. Web based Whois Service
CentralNic provides a web interface to the Whois service on its website. In addition, Top Level Design, LLC will provide a similar service on the TLD registry website. The web Whois acts as a proxy to the port 43 Whois service: users enter a query into a form, and a server-side process submits the query to the Whois server, and displays the response. This service will not be subjected to the rate limiting described above, but users will be required to complete a CAPTCHA to prevent high-volume automated access.

26.11. Searchable Whois Service
Top Level Design, LLC will provide a Searchable Whois Service (SWS). This service will be made available on the TLD website. The SWS provides third parties with a search interface that allows queries for partial matches against a number of domain name properties, including:
• domain name (partial match)
• registrant name, organisation, address, email
• administrative, technical and billing contact information
• Nameservers
• Nameserver IPv4⁄IPv6 address

Access to the SWS is restricted. Users must submit an account request via the website, and agree to the terms and conditions which governs their access to the system. These terms are included as Appendix 26.5. Once their request has been reviewed and approved, they are issued with credentials which permit them to login to the SWS.

To prevent abuse of the SWS, users may only make fifty queries per day initially. This limit can be increased upon request and demonstration of legitimate need.

26.12. Anti-Abuse Mechanisms
CentralNic has implemented measures to mitigate the threat of abuse of the Whois service. The primary threat to the Whois service are so-called ʺdictionaryʺ attacks, where an attacker attempts to enumerate the database by flooding the server with queries for domains taken from a precompiled list: as zone files are easy to obtain, this presents a threat to the privacy of contact information in the registry database. The information harvested can be used to compile email databases for spamming, or to send domain renewal scam letters, for example.

The Whois service implements rate-limiting to impede dictionary attacks. For each query, a counter associated with the client IP address is incremented. For subsequent queries, this counter determines the number of queries received within the previous hour. If the number of queries exceeds a pre-set maximum (currently 240 queries per hour), then the server returns an error, warning the user that they have exceeded the permitted query rate. If the user stops sending queries, then eventually the query rate will drop below the limit, and subsequent queries will be permitted. If the user continues to send queries, and the query rate exceeds the limit by a further 25% (300 queries per hour), then the IP address is permanently blocked. For queries over IPv6 (where an attacker might have access to billions of IP addresses), the enclosing ⁄48 will be blocked.

Experience indicates that is an effective mechanism for preventing abuse of the Whois. The rate limit has been tuned to ensure that legitimate uses of the Whois are allowed, but abusive use of the whois is restricted to levels which are unappealing for attackers.

CentralNic keeps a ʺwhite listʺ of IP addresses used by legitimate users of the Whois service, including law enforcement agencies and other research and anti-abuse entities. Registrar access lists are also incorporated into the white list, and IP addresses registered on ICANNʹs RADAR system will also be included. Queries from IP addresses that appear on the white list are not rate-limited. Interested parties can request addition to the white list by contacting CentralNicʹs public customer service team.

The web-based Whois does not implement rate-limiting, but users of this service must complete a CAPTCHA to access Whois records.

26.12.1. Denial-of-Service attacks
The rate-limiting system in place provides protection against DoS and DDoS attacks, as any host that attempts to flood the Whois service with queries will be quickly blocked. However, a DDoS attack could still saturate upstream links requiring filtering at the edges of CentralNicʹs network, as well as their upstream providers. Continuous surveillance and monitoring of the Whois system (see §42) proactively detects these threats. As the Whois service directly queries the primary SRS database, CentralNic rate-limits on the database backend to prevent an attack against the Whois service from disrupting the SRS.

26.13. Monitoring and Logging
Remote monitoring is used to verify the availability of the service and to record the round-trip times for different queries (warm hit, warm miss). Local monitoring records query volumes.

26.14. Resourcing
As can be seen in the Resourcing Matrix found in Appendix 23.2, CentralNic will maintain a team of full-time developers and engineers which will contribute to the development and maintenance of this aspect of the registry system. These developers and engineers will not work on specific subsystems full-time, but a certain percentage of their time will be dedicated to each area. The total HR resource dedicated to this area is equivalent to almost one full-time person (83%).

CentralNic operates a shared registry environment where multiple registry zones (such as CentralNicʹs domains, the .LA ccTLD, this TLD and other gTLDs) share a common infrastructure and resources. Since the TLD will be operated in an identical manner to these other registries, and on the same infrastructure, then the TLD will benefit from an economy of scale with regards to access to CentralNicʹs resources.

CentralNicʹs resourcing model assumes that the ʺdedicatedʺ resourcing required for the TLD (ie, that required to deal with issues related specifically to the TLD and not to general issues with the system as a whole) will be equal to the proportion of the overall registry system that the TLD will use. After three years of operation, the optimistic projection for the TLD states that there will be [32,182] domains in the zone. CentralNic has calculated that, if all its TLD clients are successful in their applications, and all meet their optimistic projections after three years, its registry system will be required to support up to 4.5 million domain names. Therefore the TLD will require 0.72% of the total resources available for this area of the registry system.

In the event that registration volumes exceed this figure, CentralNic will proactively increase the size of the Technical Operations, Technical Development and support teams to ensure that the needs of the TLD are fully met. Revenues from the additional registration volumes will fund the salaries of these new hires. Nevertheless, CentralNic is confident that the staffing outlined above is sufficient to meet the needs of the TLD for at least the first 18 months of operation.