Back

26 Whois

gTLDFull Legal NameE-mail suffixDetail
.AMPAMP Limitedrodenbaugh.comView
The KSregistry (KSR) provides both web and command line (port 43) publicly accessible RDDS (WHOIS) which offers a central location for all authoritative TLD related information when registering or modifying a domain name. The RDDS (WHOIS) information is reflected in real-time to the public.
The RDDS (WHOIS) service is a public service for interested stakeholders such as registries, registrars, individuals, law enforcement, and trademark owners that require detailed information on one of the following categories of information:

- Domain name including status, creation, and expiration date
- Information on domain registrant, administration, technical and billing contact
- Name server and IP address
- Registrar information

This information will provide the public with the ability to get in touch with the domain holder for any reason that requires action to be taken (e.g. trademark issues, violations with registry policies, offensive content, etc.). In addition to the search capabilities, the service has methods of limiting abuse.

The RDDS (WHOIS) service is in compliance with RFC 3912 and Specifications 4 and 6 of the registry agreement and global best practices.

KSR is already running a RDDS (WHOIS) server in full compliance with RFC 3912. The service has been in place for over 11 years without any major incidents. Experienced personnel are on board for operating and maintaining the RDDS (WHOIS) service.


A. Searchable RDDS (WHOIS)


The KSR RDDS (WHOIS) includes a web-based searchable service for registrars only which reveals more detailed information, satisfying the requirements for a score of 2.

Fig. 2 in attachment Q26_Figure2.pdf shows the complete list of all possible queries which can be made.

For security reasons and legal restrictions some search capabilities are only available in the registrar web-based RDDS (WHOIS). This includes partial match capabilities regarding the registrantʹs postal address.


B. Abuse Protections

There are technical restrictions in place for all RDDS (WHOIS) types to prevent the abuse of the data from such methods as data mining or DDOS (Distributed Denial of Service). Following best practices, KSR protects the web-based whois service with CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) and port 43 whois service with IP limitations.

In addition to these technical restrictions, the registry policy disallows data mining or comparable approaches of collecting data.


C. Technical Overview

The RDDS (WHOIS) service is set up as a two server cluster with a redundant load balancer in front of it to ensure a highly available solution (n+1 redundancy).

The server software is running on a SuSE Linux Enterprise Server and is configured to be scalable, allowing KSR to be extended by simply adding additional servers to the setup during regular operations.

The sizing of the servers and the databases are calculated to meet the needs of the individual business case and are able to handle a sustained and significant load. The available RDDS (WHOIS) servers are always active at one regional site and may be switched to another regional site within minutes as necessary. There are two different sites available for running the RDDS (WHOIS) service.

- Primary Site: St. Ingbert, Germany
- Secondary Site: Munich, Germany

All sites have a permanent highly secure VPN connection to the (current) primary site in order to synchronize the complete SRS, EPP, DNS⁄DNSSEC, escrow and RDDS (WHOIS) related database information. All network traffic between the VPN gateways will be encrypted using 1024 bit RSA keys. The complete availability of KSR information at all times allows for a safe failover from the primary site to the secondary or disaster site within minutes.

The RDDS (WHOIS) information data is stored in a MySQL database which is setup as an active⁄active database cluster. This cluster is permanently replicated to all other sites. The RDDS (WHOIS) data is also stored daily by the KSR backup system. The backups are also sent to the secondary site.

In addition to the performance aspect of the RDDS (WHOIS) service, the KSR detects abusive usage levels such as those that occur from excessive numbers of queries from one source. This is accomplished by checking the source IP of the request on the port 43 RDDS (WHOIS). The web-based RDDS (WHOIS) comes with an additional CAPTCHA mechanism in order to prevent abuse.

Further protections to the WHOIS service from incidents like DDOS (Distributed Denial Of Service) attacks are assured by an IDS (Intrusion Detection System) which provides KSR overall protection.

Daily generated escrow data files containing all RDDS (WHOIS) related data are stored at the NCC Group as the KSR escrow provider.

The full RDDS (WHOIS) architecture is described in fig. 1 in attachment Figure Q26_Figure1.


D. Quality Measurements and Validation of Compliance with Specifications 4 and 10

KSR takes several measurements in order to ensure ongoing Service Level Agreement (SLA) checking, RFC compliance, and compliance with Specifications 4 and 10 of the registry agreement. For the following, KSR refers to the RDDS (WHOIS) as RDDS (Registration Data Directory Services) in order to describe the collective of RDDS (WHOIS) and web-based RDDS (WHOIS) services.

In order to facilitate the registry performance specification (Specification 10), the following checks are performed on the RDDS (WHOIS) periodically:

- RDDS availability
- RDDS query RTT
- Web-based RDDS query RTT
- RDDS update time
- RDDS test

All available RDDS (WHOIS) search patterns are randomly checked with a data parser compliant with RFC 3912 and Specification 4 in order to check if the data output satisfies the given requirements.

A non-registry partner also validates RFC 3912 compliance. KSR also performs backwards RFC compliance checks on the non-registry partner through its registry partnership with Internetwire. All software enhancements or corrections go through the change management process. This includes full regression testing with the complete SRS system. Provided that all quality tests and the change is approved by the Change Management Board (CMB), a change will be made in the OT&E system. Once the testing phase in the OT&E is done and no problems are found while testing with the registrars, the software change of the new version will be made in production.


E. System Capacity

KSR sizing calculations have been performed to assess the hardware resources necessary to support the expected volume of transactions from the business case for this TLD and are based on available statistics from the monthly ICANN registry reports of existing gTLDs like .Com, .Org, .Info and the ccTLD .Be.

Taking into account that the KSR is setup and designed to host multiple strings, the maximum number of this specific string does not fully load the maximum capacity of the system.

KSR is capable of handling up to the following volumes as a maximum with the current capability of the hardware:

For this TLD the expected number of domain name registrations will be significantly less than 9,000 over a period of 3 years.

Max. RDDS (WHOIS) capacity of KSR: 200,000,000 queries⁄month

If the system reporting and alerts indicate that the current volumes of data or transactions is reaching 75% of the maximum capacity of the system, the system will be upgraded by adding additional servers to the setup. This can be done during regular operations without requiring any downtime.

KSR used the gathered statistics to derive blended base and peak transaction volume expectations per domain. Calculations of traffic presented below are derived strictly from peak transaction volumes in support of conservative estimates and the intent that a margin of error should result in over-provisioning registry services, versus under-provisioning.

First Year:
RDDS up to 78 queries per domain per month

For a 9K domain name registry:
RDDS up to 702,000 queries per month

Note: benchmark calculations from values from public registry data are raised by 50% for RDDS in the first year in respect to related registry launch activities.

Second Year:

RDDS up to 52 queries per domain per month

For a 9K domain name registry:
RDDS up to 468,000 queries per month


F. Hardware Specifications

The hardware specifications are based on the analysis from the system capacity numbers.

KSRʹs primary and secondary data center were chosen to fit a common architecture, providing the following benefits:

- at least TIER III certification
- n+1 redundancy on power supply, cooling network
- at least one 1 Gbit uplink provider
- latest fire prevention system
- 10 Gbit internal network transfer for KSR systems

The detailed hardware list is described in the table in fig. 3 in attachment Q26_Figure3.pdf.

RDDS plans are consistent with the technical, operational, and financial approach as described in the application


G. Roles and Resources

G.1 Resources

Key-Systems GmbH has gathered experience in various roles in the domain business for more than ten years and has access to extensive knowledge in the domain business. This deep industry knowledge and experience has also been transferred to KSregistry GmbH, the technical provider of the KSregistry system (KSR) and is evident in many trusted persons serving in different roles throughout the company.

The table in (fig. 4 in attachment Q26_Figure4.pdf) shows how the roles described above are planned for the SRS system. All resources at KSregistry are dedicated to the registry business. The calculations differ between the project phase and the years after the operational start. The project phase requires more resources as there is much planning, managing, and development required. All resources are engaged in the domain industry only and are experts in their field.

However, as the resources are shared and are not dedicated exclusively to one SRS project, the columns contain the number of resources available for this role and the percentage of all people working for this specific TLD. This percentage is the guaranteed time the resources for this SRS project assure.

G.2 Roles

Engineering Role

The designated engineering role includes the software developers of the entire SRS and all related interfaces (EPP, RDDS (WHOIS), escrow, etc.). All engineers are also integrated into 3rd level support of the SRS and related interfaces. The members of the engineering role are located in two geographically separate locations in Germany (St. Ingbert and Munich).

System Administration Role

The system administrators take care of the infrastructure of the SRS system. This includes the entire network, hardware, and system installations, as well as the cluster setup of the databases and all data backups which are made. Further, the installation of the hardware security module is performed by this role. This includes network setup, operating system installation, and HSM activation.

The members of the administration role are spread across two geographically separate locations inside of Germany (St. Ingbert and Munich).

Quality Management Role

The Quality Management (QM) role takes care of each software component which is integrated into the SRS system and related interfaces. After a development cycle is finished, the QM performs full integration testing of the entire system. The testing is performed on a separate testing system (OT&E) which mirrors the production system. The QM ensures production readiness of each and every software upgrade including emergency software patches. No software or system change will be promoted to production without the explicit approval of the QM.

Change Management (CM) ⁄ Project Management (PM)

The CM and PM role ensures that all steps in the development and system change processes are assessed, approved, implemented and reviewed in a controlled manner. This role filters requests so that only useful, valid and approved changes are implemented. They are also responsible for managing development efforts and changes to ensure that the changes are applied in accordance with predefined processes. They also chair the Change Advisory Board (CAB) and the Emergency Change Advisory Board (ECAB). These boards are comprised of selected people from other functions within the company. The project and change management role reviews and closes requests for change and reports to management.


H. Whois Output Fields

Query on domain name data displays the following information:

Domain Name
Domain ID
WHOIS Server
Referral URL
Domain Last Updated Date
Domain Registration Date
Domain Expiration Date
Sponsoring registrar
Sponsoring registrar IANA ID
Domain Status
Registrant, Administrative, Technical and Billing Contact
Information including
Contact ID
Contact Name
Contact Organization
Contact Address, City, State⁄Province, Country
Contact Postal Code
Contact Phone, Fax, E-mail
Name Servers associated with this domain
DNSSEC information

Example Request: Query for domain “example.string”
Example Response:
Domain Name: EXAMPLE.STRING
Domain ID: 213232132-TLD
WHOIS Server: WHOIS.example.string
Referral URL: http:⁄⁄www.example.string
Updated Date: 2011-07-22T01:44:02Z
Creation Date: 2011-06-01T23:45:33Z
Registry Expiry Date: 2012-06-01T23:59:59Z
Sponsoring Registrar: EXAMPLE REGISTRAR
Sponsoring Registrar IANA ID: 1234567890
Domain Status: clientTransferProhibited
Registrant ID: 123456-STR
Registrant Name: EXAMPLE REGISTRANT
Registrant Organization: EXAMPLE ORGANIZATION
Registrant Street: 123 EXAMPLE STREET
Registrant City: SOMEWHERE
Registrant State⁄Province: AP
Registrant Postal Code: 12345
Registrant Country: EX
Registrant Phone: +1.5555522222
Registrant Fax: +1.55555544444
Registrant Email: EMAIL@EXAMPLE.STRING
Admin ID: 392839283-STR
Admin Name: EXAMPLE REGISTRANT ADMINISTRATIVE
Admin Organization: EXAMPLE REGISTRANT ORGANIZATION
Admin Street: 123 EXAMPLE STREET
Admin City: SOMEWHERE
Admin State⁄Province: AP
Admin Postal Code: 12345
Admin Country: EX
Admin Phone: +1.5555551212
Admin Phone Ext: 1234
Admin Fax: +1.5555551213
Admin Fax Ext:
Admin Email: EMAIL@EXAMPLE.STRING
Tech ID: 392811183-STR
Tech Name: EXAMPLE REGISTRAR TECHNICAL
Tech Organization: EXAMPLE REGISTRAR LLC
Tech Street: 123 EXAMPLE STREET
Tech City: SOMEWHERE
Tech State⁄Province: AP
Tech Postal Code: 12345
Tech Country: EX
Tech Phone: +1.1235551234
Tech Phone Ext: 1234
Tech Fax: +1.5555551213
Tech Fax Ext: 93
Tech Email: EMAIL@EXAMPLE.STRING
Billing ID: 112811183-STR
Billing Name: EXAMPLE REGISTRAR BILLING
Billing Organization: EXAMPLE REGISTRAR LLC
Billing Street: 123 EXAMPLE STREET
Billing City: SOMEWHERE
Billing State⁄Province: AP
Billing Postal Code: 12345
Billing Country: EX
Billing Phone: +1.1235551234
Billing Phone Ext: 1234
Billing Fax: +1.5555551213
Billing Fax Ext: 93
Billing Email: EMAIL@EXAMPLE.STRING
Name Server: NS01.EXAMPLEREGISTRAR.STRING
Name Server: NS02.EXAMPLEREGISTRAR.STRING
DNSSEC: signedDelegation
DNSSEC: unsigned0

Query on name server name data displays the following information:

Name Server Host Name
Name Server IP Addresses if applicable
Sponsoring registrar
Name Server Creation Date
Name Server Last Updated Date

Example Request: Query for name server ns1.example.string
Example Response:
Server Name: NS1.EXAMPLE.STRING
IP Address: 192.0.3.123
IP Address: 2001:0DB8::1
Registrar: Example Registrar, Inc.
Creation Date: 2011-06-01T23:45:33Z
Updated Date: 2011-07-22T01:44:02Z

Query on registrar displays the following information:

Registrar ID
Registrar Name
Registrar Status
Registrar Address, City, State⁄Province, Country
Registrar Postal Code
Registrar Phone, Fax, E-mail
Registrar Creation Date
Registrar Last Updated Date
Administrative, Technical Contact
Information including
Contact Phone, Fax, E-mail

Example request: Query for registrar Example Registrar, Inc.
Example response:
Registrar Name: Example Registrar, Inc.
Street: 4231 King Street
City: London
State⁄Province: XY
Postal Code: 123445
Country: XR
Phone Number: +1.3105559999
Fax Number: +1.3105559911
Email: registrar@example.string
Admin Contact: Pete Registrar
Phone Number: +1.3105551213
Fax Number: +1.3105551213
Email: pete@example-registrar.string
Technical Contact: Karlo Schlapp
Phone Number: +1.5610555222
Fax Number: +1.33105551111
Email: karlo@example-registrar.string


I. List of Attachments

- Q26_Figure1.pdf
- Q26_Figure2.pdf
- Q26_Figure3.pdf
- Q26_Figure4.pdf
gTLDFull Legal NameE-mail suffixDetail
.designSTARTING DOTjwgroupe.comView
Question 26: RDDS (WHOIS)

The KSregistry (KSR) provides both web and command line (port 43) publicly accessible RDDS (WHOIS) which offers a central location for all authoritative TLD related information when registering or modifying a domain name. The RDDS (WHOIS) information is reflected in real-time to the public.
The RDDS (WHOIS) service is a public service for interested stakeholders such as registries, registrars, individuals, law enforcement, and trademark owners that require detailed information on one of the following categories of information:

- Domain name including status, creation, and expiration date
- Information on domain registrant, administration, technical and billing contact
- Name server and IP address
- Registrar information

This information will provide the public with the ability to get in touch with the domain holder for any reason that requires action to be taken (e.g. trademark issues, violations with registry policies, offensive content, etc.). In addition to the search capabilities, the service has methods of limiting abuse.

The RDDS (WHOIS) service is in compliance with RFC 3912 and Specifications 4 and 6 of the registry agreement and global best practices.

KSR is already running a RDDS (WHOIS) server in full compliance with RFC 3912. The service has been in place for over 11 years without any major incidents. Experienced personnel are on board for operating and maintaining the RDDS (WHOIS) service.


A. Searchable RDDS (WHOIS)


The KSR RDDS (WHOIS) includes a web-based searchable service for registrars only which reveals more detailed information, satisfying the requirements for a score of 2.

Fig. 2 in attachment Q26_Figure2.pdf shows the complete list of all possible queries which can be made.

For security reasons and legal restrictions some search capabilities are only available in the registrar web-based RDDS (WHOIS). This includes partial match capabilities regarding the registrantʹs postal address.


B. Abuse Protections

There are technical restrictions in place for all RDDS (WHOIS) types to prevent the abuse of the data from such methods as data mining or DDOS (Distributed Denial of Service). Following best practices, KSR protects the web-based whois service with CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) and port 43 whois service with IP limitations.

In addition to these technical restrictions, the registry policy disallows data mining or comparable approaches of collecting data.


C. Technical Overview

The RDDS (WHOIS) service is set up as a two server cluster with a redundant load balancer in front of it to ensure a highly available solution (n+1 redundancy).

The server software is running on a SuSE Linux Enterprise Server and is configured to be scalable, allowing KSR to be extended by simply adding additional servers to the setup during regular operations.

The sizing of the servers and the databases are calculated to meet the needs of the individual business case and are able to handle a sustained and significant load. The available RDDS (WHOIS) servers are always active at one regional site and may be switched to another regional site within minutes as necessary. There are two different sites available for running the RDDS (WHOIS) service.

- Primary Site: St. Ingbert, Germany
- Secondary Site: Munich, Germany

All sites have a permanent highly secure VPN connection to the (current) primary site in order to synchronize the complete SRS, EPP, DNS⁄DNSSEC, escrow and RDDS (WHOIS) related database information. All network traffic between the VPN gateways will be encrypted using 1024 bit RSA keys. The complete availability of KSR information at all times allows for a safe failover from the primary site to the secondary or disaster site within minutes.

The RDDS (WHOIS) information data is stored in a MySQL database which is setup as an active⁄active database cluster. This cluster is permanently replicated to all other sites. The RDDS (WHOIS) data is also stored daily by the KSR backup system. The backups are also sent to the secondary site.

In addition to the performance aspect of the RDDS (WHOIS) service, the KSR detects abusive usage levels such as those that occur from excessive numbers of queries from one source. This is accomplished by checking the source IP of the request on the port 43 RDDS (WHOIS). The web-based RDDS (WHOIS) comes with an additional CAPTCHA mechanism in order to prevent abuse.

Further protections to the WHOIS service from incidents like DDOS (Distributed Denial Of Service) attacks are assured by an IDS (Intrusion Detection System) which provides KSR overall protection.

Daily generated escrow data files containing all RDDS (WHOIS) related data are stored at the NCC Group as the KSR escrow provider.

The full RDDS (WHOIS) architecture is described in fig. 1 in attachment Figure Q26_Figure1.


D. Quality Measurements and Validation of Compliance with Specifications 4 and 10

KSR takes several measurements in order to ensure ongoing Service Level Agreement (SLA) checking, RFC compliance, and compliance with Specifications 4 and 10 of the registry agreement. For the following, KSR refers to the RDDS (WHOIS) as RDDS (Registration Data Directory Services) in order to describe the collective of RDDS (WHOIS) and web-based RDDS (WHOIS) services.

In order to facilitate the registry performance specification (Specification 10), the following checks are performed on the RDDS (WHOIS) periodically:

- RDDS availability
- RDDS query RTT
- Web-based RDDS query RTT
- RDDS update time
- RDDS test

All available RDDS (WHOIS) search patterns are randomly checked with a data parser compliant with RFC 3912 and Specification 4 in order to check if the data output satisfies the given requirements.

A non-registry partner also validates RFC 3912 compliance. KSR also performs backwards RFC compliance checks on the non-registry partner through its registry partnership with Internetwire. All software enhancements or corrections go through the change management process. This includes full regression testing with the complete SRS system. Provided that all quality tests and the change is approved by the Change Management Board (CMB), a change will be made in the OT&E system. Once the testing phase in the OT&E is done and no problems are found while testing with the registrars, the software change of the new version will be made in production.


E. System Capacity

KSR sizing calculations have been performed to assess the hardware resources necessary to support the expected volume of transactions from the business case for the .design gTLD and are based on available statistics from the monthly ICANN registry reports of existing gTLDs like .Com, .Org, .Info and the ccTLD .Be.

Taking into account that the KSR is setup and designed to host multiple strings, the maximum number of this specific string does not fully load the maximum capacity of the system.

KSR is capable of handling up to the following volumes as a maximum with the current capability of the hardware:

For the .design gTLD the expected number of domain name registrations will be significantly less than 9,000 over a period of 3 years.

Max. RDDS (WHOIS) capacity of KSR: 200,000,000 queries⁄month

If the system reporting and alerts indicate that the current volumes of data or transactions is reaching 75% of the maximum capacity of the system, the system will be upgraded by adding additional servers to the setup. This can be done during regular operations without requiring any downtime.

KSR used the gathered statistics to derive blended base and peak transaction volume expectations per domain. Calculations of traffic presented below are derived strictly from peak transaction volumes in support of conservative estimates and the intent that a margin of error should result in over-provisioning registry services, versus under-provisioning.

First Year:
RDDS up to 78 queries per domain per month

For a 9K domain name registry:
RDDS up to 702,000 queries per month

Note: benchmark calculations from values from public registry data are raised by 50% for RDDS in the first year in respect to related registry launch activities.

Second Year:

RDDS up to 52 queries per domain per month

For a 9K domain name registry:
RDDS up to 468,000 queries per month


F. Hardware Specifications

The hardware specifications are based on the analysis from the system capacity numbers.

KSRʹs primary and secondary data center were chosen to fit a common architecture, providing the following benefits:

- at least TIER III certification
- n+1 redundancy on power supply, cooling network
- at least one 1 Gbit uplink provider
- latest fire prevention system
- 10 Gbit internal network transfer for KSR systems

The detailed hardware list is described in the table in fig. 3 in attachment Q26_Figure3.pdf.

RDDS plans are consistent with the technical, operational, and financial approach as described in the application


G. Roles and Resources

G.1 Resources

Key-Systems GmbH has gathered experience in various roles in the domain business for more than ten years and has access to extensive knowledge in the domain business. This deep industry knowledge and experience has also been transferred to KSregistry GmbH, the technical provider of the KSregistry system (KSR) and is evident in many trusted persons serving in different roles throughout the company.

The table in (fig. 4 in attachment Q26_Figure4.pdf) shows how the roles described above are planned for the SRS system. All resources at KSregistry are dedicated to the registry business. The calculations differ between the project phase and the years after the operational start. The project phase requires more resources as there is much planning, managing, and development required. All resources are engaged in the domain industry only and are experts in their field.

However, as the resources are shared and are not dedicated exclusively to one SRS project, the columns contain the number of resources available for this role and the percentage of all people working for this specific TLD. This percentage is the guaranteed time the resources for this SRS project assure.

G.2 Roles

Engineering Role

The designated engineering role includes the software developers of the entire SRS and all related interfaces (EPP, RDDS (WHOIS), escrow, etc.). All engineers are also integrated into 3rd level support of the SRS and related interfaces. The members of the engineering role are located in two geographically separate locations in Germany (St. Ingbert and Munich).

System Administration Role

The system administrators take care of the infrastructure of the SRS system. This includes the entire network, hardware, and system installations, as well as the cluster setup of the databases and all data backups which are made. Further, the installation of the hardware security module is performed by this role. This includes network setup, operating system installation, and HSM activation.

The members of the administration role are spread across two geographically separate locations inside of Germany (St. Ingbert and Munich).

Quality Management Role

The Quality Management (QM) role takes care of each software component which is integrated into the SRS system and related interfaces. After a development cycle is finished, the QM performs full integration testing of the entire system. The testing is performed on a separate testing system (OT&E) which mirrors the production system. The QM ensures production readiness of each and every software upgrade including emergency software patches. No software or system change will be promoted to production without the explicit approval of the QM.

Change Management (CM) ⁄ Project Management (PM)

The CM and PM role ensures that all steps in the development and system change processes are assessed, approved, implemented and reviewed in a controlled manner. This role filters requests so that only useful, valid and approved changes are implemented. They are also responsible for managing development efforts and changes to ensure that the changes are applied in accordance with predefined processes. They also chair the Change Advisory Board (CAB) and the Emergency Change Advisory Board (ECAB). These boards are comprised of selected people from other functions within the company. The project and change management role reviews and closes requests for change and reports to management.


H. Whois Output Fields

Query on domain name data displays the following information:

Domain Name
Domain ID
WHOIS Server
Referral URL
Domain Last Updated Date
Domain Registration Date
Domain Expiration Date
Sponsoring registrar
Sponsoring registrar IANA ID
Domain Status
Registrant, Administrative, Technical and Billing Contact
Information including
Contact ID
Contact Name
Contact Organization
Contact Address, City, State⁄Province, Country
Contact Postal Code
Contact Phone, Fax, E-mail
Name Servers associated with this domain
DNSSEC information

Example Request: Query for domain “example.string”
Example Response:
Domain Name: EXAMPLE.STRING
Domain ID: 213232132-TLD
WHOIS Server: WHOIS.example.string
Referral URL: http:⁄⁄www.example.string
Updated Date: 2011-07-22T01:44:02Z
Creation Date: 2011-06-01T23:45:33Z
Registry Expiry Date: 2012-06-01T23:59:59Z
Sponsoring Registrar: EXAMPLE REGISTRAR
Sponsoring Registrar IANA ID: 1234567890
Domain Status: clientTransferProhibited
Registrant ID: 123456-STR
Registrant Name: EXAMPLE REGISTRANT
Registrant Organization: EXAMPLE ORGANIZATION
Registrant Street: 123 EXAMPLE STREET
Registrant City: SOMEWHERE
Registrant State⁄Province: AP
Registrant Postal Code: 12345
Registrant Country: EX
Registrant Phone: +1.5555522222
Registrant Fax: +1.55555544444
Registrant Email: EMAIL@EXAMPLE.STRING
Admin ID: 392839283-STR
Admin Name: EXAMPLE REGISTRANT ADMINISTRATIVE
Admin Organization: EXAMPLE REGISTRANT ORGANIZATION
Admin Street: 123 EXAMPLE STREET
Admin City: SOMEWHERE
Admin State⁄Province: AP
Admin Postal Code: 12345
Admin Country: EX
Admin Phone: +1.5555551212
Admin Phone Ext: 1234
Admin Fax: +1.5555551213
Admin Fax Ext:
Admin Email: EMAIL@EXAMPLE.STRING
Tech ID: 392811183-STR
Tech Name: EXAMPLE REGISTRAR TECHNICAL
Tech Organization: EXAMPLE REGISTRAR LLC
Tech Street: 123 EXAMPLE STREET
Tech City: SOMEWHERE
Tech State⁄Province: AP
Tech Postal Code: 12345
Tech Country: EX
Tech Phone: +1.1235551234
Tech Phone Ext: 1234
Tech Fax: +1.5555551213
Tech Fax Ext: 93
Tech Email: EMAIL@EXAMPLE.STRING
Billing ID: 112811183-STR
Billing Name: EXAMPLE REGISTRAR BILLING
Billing Organization: EXAMPLE REGISTRAR LLC
Billing Street: 123 EXAMPLE STREET
Billing City: SOMEWHERE
Billing State⁄Province: AP
Billing Postal Code: 12345
Billing Country: EX
Billing Phone: +1.1235551234
Billing Phone Ext: 1234
Billing Fax: +1.5555551213
Billing Fax Ext: 93
Billing Email: EMAIL@EXAMPLE.STRING
Name Server: NS01.EXAMPLEREGISTRAR.STRING
Name Server: NS02.EXAMPLEREGISTRAR.STRING
DNSSEC: signedDelegation
DNSSEC: unsigned0

Query on name server name data displays the following information:

Name Server Host Name
Name Server IP Addresses if applicable
Sponsoring registrar
Name Server Creation Date
Name Server Last Updated Date

Example Request: Query for name server ns1.example.string
Example Response:
Server Name: NS1.EXAMPLE.STRING
IP Address: 192.0.3.123
IP Address: 2001:0DB8::1
Registrar: Example Registrar, Inc.
Creation Date: 2011-06-01T23:45:33Z
Updated Date: 2011-07-22T01:44:02Z

Query on registrar displays the following information:

Registrar ID
Registrar Name
Registrar Status
Registrar Address, City, State⁄Province, Country
Registrar Postal Code
Registrar Phone, Fax, E-mail
Registrar Creation Date
Registrar Last Updated Date
Administrative, Technical Contact
Information including
Contact Phone, Fax, E-mail

Example request: Query for registrar Example Registrar, Inc.
Example response:
Registrar Name: Example Registrar, Inc.
Street: 4231 King Street
City: London
State⁄Province: XY
Postal Code: 123445
Country: XR
Phone Number: +1.3105559999
Fax Number: +1.3105559911
Email: registrar@example.string
Admin Contact: Pete Registrar
Phone Number: +1.3105551213
Fax Number: +1.3105551213
Email: pete@example-registrar.string
Technical Contact: Karlo Schlapp
Phone Number: +1.5610555222
Fax Number: +1.33105551111
Email: karlo@example-registrar.string


I. List of Attachments

- Q26_Figure1.pdf
- Q26_Figure2.pdf
- Q26_Figure3.pdf
- Q26_Figure4.pdf