Back

23 Provide name and full description of all the Registry Services to be provided

gTLDFull Legal NameE-mail suffixDetail
.immodotimmobilie GmbHdotimmobilie.deView
Technical operations of the Registry will be outsourced to “TLD-Box Registrydienstleistungen GmbH”, and a signed contract for the provision of those services with TLD-Box exists. A more detailed description of that outsourcing relation is described in response to question 31.

The Registry operating the proposed gTLD will provide the following Registry Services (Services are numbered according to the Questions and Notes in ICANN’s application guidebook):

(A), (i): “Receipt of data from registrars concerning registration of domain names and name servers”: The interface for receipt of such data (Shared Registry Service – SRS) is fully based on the Extensible Provisioning Protocol (EPP) and conforms to the relevant RFCs (see answer to Question 25). Beyond the standard EPP object mappings and commands, no proprietary EPP extensions are used (unless ICANN requirements necessitate the use of draft level specifications, i.e. for the Trademark Clearing House integration). This Registry Service is operated on a cluster of at least two physically independent servers as an active-active load-balanced group which interact with a clustered registry database backend (detailed in response to Question 33). Access to that interface is controlled by two-factor authentication mechanisms with one factor being the IP address of the registrar’s EPP client and the second factor being the registrar’s credentials (username⁄password). Traffic is encrypted with TLS. Access attempts from an IP addresses that is not registered with the Registry Operator are denied. A detailed specification of the EPP interface is contained in answer to Question 25, while the architecture of the EPP frontend is included in response to Question 32. The software used to provide the EPP service is readily available at the time of this writing. The software is based on the EPP software used to provide Registry services for the “.at”, “.no” and “.bh” ccTLDs with the domain lifecycle and periods adapted to the requirements for new gTLDs. The EPP service is available over both IPv4 and IPv6 transport.

(ii): “Provision to registrars of status information relating to the zone servers for the TLD”: The registry operator will operate an announcement mailing list where updates regarding the operational status of the zone servers of the TLD will be posted. Additionally, registrars can query for the zone server status of an individual domain name under the TLD via the EPP or WHOIS interfaces – both interfaces will contain the relevant EPP status values (refer to the answer to Question 27 Registration Life Cycle which lists the domain’s zone server status depending on the domain status).

(B), (iii): “Dissemination of TLD zone files”: Zone generation and the subsequent DNSSEC signing of that zone is performed in parallel on two physically separate zone generators based on the current data in the registry database. After performing offline checks for the integrity of the zone file, the TLD zone file is loaded onto two hidden master nameservers (the zone file of the second zone generator is only used in case of an emergency situation with the first zone generator). These hidden masters supply the public nameserver network with the current zone file. For zone dissemination the standard DNS mechanisms of NOTIFY and IXFR⁄AXFR, protected by TSIG, are used. Integrity checks are performed to detect errors such as incomplete zone generation, incorrect DNSSEC key usage, key signing keys not matching DS records in the parent zone or an NSEC⁄NSEC3 chain problem.

The DNS query based verification procedures include the following set of checks on the published KSK and ZSK:

** Check if the published KSK matches a published DS-Record in the parent zone
** Check if the signature of the SOA and the Zone-NS-Records are included and correct
** Query (with DO-bit set) for 20 predefined existing domain names, check the results and validate the received signatures
** Query (with DO-bit set) for 20 predefined non-existing zone names, check the results and validate the received signatures
** Query (with DO-bit set) for 20 new (or changed) domains since the last zone generation, check the result and validate the received signatures (the zone generator generates a diff-file with the changes made and the verification tools choose 20 records randomly)
** Query (with DO-bit set) for the predefined end-of-zone-record of the zone, check the results and validate the received signatures.

Only if these checks succeed is the zone file propagated to the hidden masters – otherwise the rollout of this zone file is stopped and operations staff is notified. Consistency checks of the loaded zonefile are also performed on the hidden masters. Zone file access as required by ICANN is also provided. These procedures are the result of practical experience and knowledge gained from operating the “.at” TLD for over 15 years.

(iv) “Operation of the Registry Zone servers”: The TLD zone servers will consist of a mix of Anycast and Unicast servers in order to ensure high availability in accordance with ICANN SLA requirements and to achieve a high level of diversity in terms of software and IP connectivity. A stable high-performance DNS network with 100% availability is one of the major key components of a successful gTLD operation. As a result the DNS network is carefully designed to fulfil those requirements. Anycast-DNS with multiple geographic locations is utilized to minimize latency, distribute traffic and increase resilience against attacks. Unicast servers are used to increase diversity across the DNS network. The zone for the TLD will not contain any wildcards or other means to modify NXDOMAIN responses. More details about the DNS network structure is contained in response to Question 35.

(C), (v) “Dissemination of contact and other information concerning domain name registrations” (WHOIS service): A port-43 WHOIS (and a lightweight alternative) as well as a web-based WHOIS will be provided. In accordance with Specification 4 of the Registry Agreement, the WHOIS service is fully compliant with RFC 3912, and provides information about domain names, registrars and nameservers. Free public access to that information is granted. Web based access is also supported. The service is based on a scalable and redundant architecture to meet the required SLAs. To address privacy considerations, rate limiting on a per-IP-address basis is employed on the WHOIS interfaces. In addition to the WHOIS service, the Registry will also offer a “Domain Availability Service” using the “Finger” protocol as defined in RFC 1288. This service can be used by registrars to check whether a domain name is available or not but does not provide any other information. The implementation is fully RFC compliant. Since finger is a very simple protocol with a minimum of overhead, requests can be processed quickly by the registry systems, which saves on computing resources for both the registry and registrar. The Finger service is a read-only interface and does not pose any security risks for the registry. Instead, providing such an interface (which is functionally identical to the IRIS dchk) offloads pure “availability” checks from the more heavyweight WHOIS and EPP interfaces which help to improve the overall performance of those services.
(D) “Internationalized Domain Names”: The registry will offer IDNs as detailed in the response to Question 44. IDN support in the proposed registry will strictly adhere to all relevant standards. Only labels with explicitly permitted code points will be allowed. The registry will be conservative in allowing additional code points and will only allow code points that do not carry risks such as user confusion or technical issues caused by lack of client support etc.

(E) “DNS Security Extensions (DNSSEC)”: The registry will perform zone signing activities in accordance with ICANN requirements and industry best practice. The respective Delegation Signer (DS) Records will in full compliance with established procedures be sent to IANA for inclusion in the root zone to establish a chain of Trust. The EPP interface of the Registry will also accept key material to extend that chain of trust down to individual domain name registrations. Further information about DNSSEC procedures is contained in response to question 43.

Regarding ICANN’s “Consensus Policies”, the Registry will provide the necessary services to comply with these policies (as well as any Temporary Policies as adopted by ICANN). This includes support for ICANN’s UDPR and URS processes. The Registry Operator will also restrict Registrar use of the “Add Grace Period” (AGP) as required by the “Add Grace Period Limits Policy”.

The registry system (software, documentation, test infrastructure) providing the above mentioned Registry Services is readily available at the time of this writing and most of the components are in production use by one or more TLDs.

All registry services are based on well-known industry standards and implement RFCs developed by the Internet Engineering Task Force.

The Registry will not operate any services that are specific or unique to the particular TLD. Hence, it is expected that potential registrars will require only minimal effort to connect to the Registry Systems to be able to perform registrations of domain names under the TLD.

Registrar Web: Registrars will be provided with a “Registrar Web”, a web site specifically targeted at registrars that will support registration procedures and allow registrars to change the configuration of their Registry account. This will include administration of their EPP login (particularly their client IP addresses) details, invoice downloads and financial functions such as topping up prepaid credit with the registry. Terms and conditions as well as registry policies are also available for download. Moreover the registrar web page provides statistics to registrars, gives them an overview of transactions requiring payment and shows available credit.

Registrar Helpdesk

A helpdesk will also be provided for registrars. This helpdesk will handle technical, legal and administrative inquiries from registrars. Helpdesk agents can be reached via email, telephone and fax. A professional ticketing system and qualified agents will ensure that all queries are handled within an appropriate turnaround time. Helpdesk services will be available during working hours on business days and an additional emergency contact will be available 24⁄7.

Security

The Registry Operator takes significant measures against (1) the unauthorized disclosure, alteration, insertion or destruction of Registry data and (2) the unauthorized access to or disclosure of information or resources on the internet. This includes a detailed security policy (contained in answer to Question 30), a secure architecture (see response to Question 32), a multi-layered backup strategy (details in response to Question 37) and a domain name lifecycle that makes it extremely unlikely that third parties can gain control over the registration record of a domain (see response to Question 27).

Stability

The operation of the TLD and the Registry Services offered do not involve any technology or business practice that has the potential to adversely affect the stability of the TLD’s services and⁄or the DNS as a whole. All protocols used are based on authoritative standards published by well-established and recognized standards organizations. For example, the DNS service provided for the TLD is in strict compliance with the relevant RFCs created by the Internet Engineering Task Force and as a result will be fully compatible with existing and deployed internet technology. Specifically, the TLD will not engage in any DNS “tricks” such as wildcard or NXDOMAIN redirection and will ensure that no conditions affecting the throughput, response time, consistency or coherence of responses to Internet servers or end systems arise.

In order to fulfill the functions described above, the Registry Backend Operator also performs operations of standard business components, such as:

Permanent office location infrastructure in two cities (Vienna and Salzburg), including three meeting rooms, with additional emergency office space contracted.
Rented datacenter space at various locations.

Billing and Financial administration and infrastructure

Technical office infrastructure such as IT systems (file storage, email⁄fax systems, document management), call-center enabled PBXes with integrated mobile devices, Teleconferencing equipment, fail-safe networking infrastructure between office locations themselves, and between office and datacenter locations.

These basic “business building blocks” are established since nearly 15 years, and are used for the day to day operations of the registry backend operations. Since some of the the elements listed above are assumed to be standard business commodities that are not specific to the operations of a gTLD registry, they are not described in further detail in subsequent answers (eg. enterprise PBX).

A number of the Registry Back-end Operator’s staff are actively engaged in numerous working groups within the Internet Engineering Task Force, particularly those focused on DNS, ENUM, emergency services and geographic location. In addition several of these employees are authors of published and draft IETF RFCs.
gTLDFull Legal NameE-mail suffixDetail
.hamburgHamburg Top-Level-Domain GmbHdothamburg.deView
*** DISCLAIMER ***

THE RESPONSE FOR THE QUESTIONS 23-44 MAY USE ANGLE BRACKETS (THE “〈” and “〉” CHARACTERS, or < and >), WHICH SEEM TO NOT BE PROPERLY RENDERED IN TAS DUE TO SECURITY CONCERNS. HENCE, THE ANSWER AS DISPLAYED IN TAS MAY NOT RENDER THE FULL RESPONSE AS INTENDED.

Technical operations of the Registry will be outsourced to “TLD-Box Registrydienstleistungen GmbH”, and a signed contract for the provision of those services with TLD-Box exists. A more detailed description of that outsourcing relation is described in response to question 31.

The Registry operating the proposed gTLD will provide the following Registry Services (Services are numbered according to the Questions and Notes in ICANN’s application guidebook):

(A), (i): “Receipt of data from registrars concerning registration of domain names and name servers”: The interface for receipt of such data (Shared Registry Service – SRS) is fully based on the Extensible Provisioning Protocol (EPP) and conforms to the relevant RFCs (see answer to Question 25). Beyond the standard EPP object mappings and commands, no proprietary EPP extensions are used (unless ICANN requirements necessitate the use of draft level specifications, i.e. for the Trademark Clearing House integration). This Registry Service is operated on a cluster of at least two physically independent servers as an active-active load-balanced group which interact with a clustered registry database backend (detailed in response to Question 33). Access to that interface is controlled by two-factor authentication mechanisms with one factor being the IP address of the registrar’s EPP client and the second factor being the registrar’s credentials (username⁄password). Traffic is encrypted with TLS. Access attempts from an IP addresses that is not registered with the Registry Operator are denied. A detailed specification of the EPP interface is contained in answer to Question 25, while the architecture of the EPP frontend is included in response to Question 32. The software used to provide the EPP service is readily available at the time of this writing. The software is based on the EPP software used to provide Registry services for the “.at”, “.no” and “.bh” ccTLDs with the domain lifecycle and periods adapted to the requirements for new gTLDs. The EPP service is available over both IPv4 and IPv6 transport.

(ii): “Provision to registrars of status information relating to the zone servers for the TLD”: The registry operator will operate an announcement mailing list where updates regarding the operational status of the zone servers of the TLD will be posted. Additionally, registrars can query for the zone server status of an individual domain name under the TLD via the EPP or WHOIS interfaces – both interfaces will contain the relevant EPP status values (refer to the answer to Question 27 Registration Life Cycle which lists the domain’s zone server status depending on the domain status).

(B), (iii): “Dissemination of TLD zone files”: Zone generation and the subsequent DNSSEC signing of that zone is performed in parallel on two physically separate zone generators based on the current data in the registry database. After performing offline checks for the integrity of the zone file, the TLD zone file is loaded onto two hidden master nameservers (the zone file of the second zone generator is only used in case of an emergency situation with the first zone generator). These hidden masters supply the public nameserver network with the current zone file. For zone dissemination the standard DNS mechanisms of NOTIFY and IXFR⁄AXFR, protected by TSIG, are used. Integrity checks are performed to detect errors such as incomplete zone generation, incorrect DNSSEC key usage, key signing keys not matching DS records in the parent zone or an NSEC⁄NSEC3 chain problem.

The DNS query based verification procedures include the following set of checks on the published KSK and ZSK:

** Check if the published KSK matches a published DS-Record in the parent zone
** Check if the signature of the SOA and the Zone-NS-Records are included and correct
** Query (with DO-bit set) for 20 predefined existing domain names, check the results and validate the received signatures
** Query (with DO-bit set) for 20 predefined non-existing zone names, check the results and validate the received signatures
** Query (with DO-bit set) for 20 new (or changed) domains since the last zone generation, check the result and validate the received signatures (the zone generator generates a diff-file with the changes made and the verification tools choose 20 records randomly)
** Query (with DO-bit set) for the predefined end-of-zone-record of the zone, check the results and validate the received signatures.

Only if these checks succeed is the zone file propagated to the hidden masters – otherwise the rollout of this zone file is stopped and operations staff are notified. Consistency checks of the loaded zonefile are also performed on the hidden masters. Zone file access as required by ICANN is also provided. These procedures are the result of practical experience and knowledge gained from operating the “.at” TLD for over 15 years.

(iv) “Operation of the Registry Zone servers”: The TLD zone servers will consist of a mix of Anycast and Unicast servers in order to ensure high availability in accordance with ICANN SLA requirements and to achieve a high level of diversity in terms of software and IP connectivity. A stable high-performance DNS network with 100% availability is one of the major key components of a successful gTLD operation. As a result the DNS network is carefully designed to fulfil those requirements. Anycast-DNS with multiple geographic locations is utilized to minimize latency, distribute traffic and increase resilience against attacks. Unicast servers are used to increase diversity across the DNS network. The zone for the TLD will not contain any wildcards or other means to modify NXDOMAIN responses. More details about the DNS network structure is contained in response to Question 35.

(C), (v) “Dissemination of contact and other information concerning domain name registrations” (WHOIS service): A port-43 WHOIS (and a lightweight alternative) as well as a web-based WHOIS will be provided. In accordance with Specification 4 of the Registry Agreement, the WHOIS service is fully compliant with RFC 3912, and provides information about domain names, registrars and nameservers. Free public access to that information is granted. Web based access is also supported. The service is based on a scalable and redundant architecture to meet the required SLAs. To address privacy considerations, rate limiting on a per-IP-address basis is employed on the WHOIS interfaces. In addition to the WHOIS service, the Registry will also offer a “Domain Availability Service” using the “Finger” protocol as defined in RFC 1288. This service can be used by registrars to check whether a domain name is available or not but does not provide any other information. The implementation is fully RFC compliant. Since finger is a very simple protocol with a minimum of overhead, requests can be processed quickly by the registry systems, which saves on computing resources for both the registry and registrar. The Finger service is a read-only interface and does not pose any security risks for the registry. Instead, providing such an interface (which is functionally identical to the IRIS dchk) offloads pure “availability” checks from the more heavyweight WHOIS and EPP interfaces which helps to improve the overall performance of those services.
(D) “Internationalized Domain Names”: The registry will offer IDNs as detailed in the response to Question 44. IDN support in the proposed registry will strictly adhere to all relevant standards. Only labels with explicitly permitted code points will be allowed. The registry will be conservative in allowing additional code points and will only allow code points that do not carry risks such as user confusion or technical issues caused by lack of client support etc.

(E) “DNS Security Extensions (DNSSEC)”: The registry will perform zone signing activities in accordance with ICANN requirements and industry best practice. The respective Delegation Signer (DS) Records will in full compliance with established procedures be sent to IANA for inclusion in the root zone to establish a chain of Trust. The EPP interface of the Registry will also accept key material to extend that chain of trust down to individual domain name registrations. Further information about DNSSEC procedures is contained in response to question 43.

Regarding ICANN’s “Consensus Policies”, the Registry will provide the necessary services to comply with these policies (as well as any Temporary Policies as adopted by ICANN). This includes support for ICANN’s UDPR and URS processes. The Registry Operator will also restrict Registrar use of the “Add Grace Period” (AGP) as required by the “Add Grace Period Limits Policy”.

The registry system (software, documentation, test infrastructure) providing the above mentioned Registry Services is readily available at the time of this writing and most of the components are in production use by one or more TLDs.

All registry services are based on well-known industry standards and implement RFCs developed by the Internet Engineering Task Force.

The Registry will not operate any services that are specific or unique to the particular TLD. Hence, it is expected that potential registrars will require only minimal effort to connect to the Registry Systems to be able to perform registrations of domain names under the TLD.

Registrar Web: Registrars will be provided with a “Registrar Web”, a web site specifically targeted at registrars that will support registration procedures and allow registrars to change the configuration of their Registry account. This will include administration of their EPP login (particularly their client IP addresses) details, invoice downloads and financial functions such as topping up prepaid credit with the registry. Terms and conditions as well as registry policies are also available for download. Moreover the registrar web page provides statistics to registrars, gives them an overview of transactions requiring payment and shows available credit.

Registrar Helpdesk

A helpdesk will also be provided for registrars. This helpdesk will handle technical, legal and administrative inquiries from registrars. Helpdesk agents can be reached via email, telephone and fax. A professional ticketing system and qualified agents will ensure that all queries are handled within an appropriate turnaround time. Helpdesk services will be available during working hours on business days and an additional emergency contact will be available 24⁄7.

Security

The Registry Operator takes significant measures against (1) the unauthorized disclosure, alteration, insertion or destruction of Registry data and (2) the unauthorized access to or disclosure of information or resources on the internet. This includes a detailed security policy (contained in answer to Question 30), a secure architecture (see response to Question 32), a multi-layered backup strategy (details in response to Question 37) and a domain name lifecycle that makes it extremely unlikely that third parties can gain control over the registration record of a domain (see response to Question 27).

Stability

The operation of the TLD and the Registry Services offered do not involve any technology or business practice that has the potential to adversely affect the stability of the TLD’s services and⁄or the DNS as a whole. All protocols used are based on authoritative standards published by well-established and recognized standards organizations. For example, the DNS service provided for the TLD is in strict compliance with the relevant RFCs created by the Internet Engineering Task Force and as a result will be fully compatible with existing and deployed internet technology. Specifically, the TLD will not engage in any DNS “tricks” such as wildcard or NXDOMAIN redirection and will ensure that no conditions affecting the throughput, response time, consistency or coherence of responses to Internet servers or end systems arise.

In order to fulfill the functions described above, the Registry Backend Operator also performs operations of standard business components, such as:

Permanent office location infrastructure in two cities (Vienna and Salzburg), including three meeting rooms, with additional emergency office space contracted.
Rented datacenter space at various locations.

Billing and Financial administration and infrastructure

Technical office infrastructure such as IT systems (file storage, email⁄fax systems, document management), call-center enabled PBXes with integrated mobile devices, Teleconferencing equipment, fail-safe networking infrastructure between office locations themselves, and between office and datacenter locations.

These basic “business building blocks” are established since nearly 15 years, and are used for the day to day operations of the registry backend operations. Since some of the the elements listed above are assumed to be standard business commodities that are not specific to the operations of a gTLD registry, they are not described in further detail in subsequent answers (eg. enterprise PBX).

A number of the Registry Back-end Operator’s staff are actively engaged in numerous working groups within the Internet Engineering Task Force, particularly those focused on DNS, ENUM, emergency services and geographic location. In addition several of these employees are authors of published and draft IETF RFCs.