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
.brusselsDNS.be vzwdns.beView
Response to Question 23 (Registry Services)

The applicant, DNS.be (being the ʺRegistry Operatorʺ) will outsource the
technical operations of the Registry to ʺTLD-Box Registrydienstleistungen GmbHʺ,
and a signed contract for the provision of those services with TLD-Box
(hereinafter referred to as the ʺBack-End Registry Operatorʺ) 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 IP addresses that are 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, the zone file is propagated to the hidden
masters - otherwise the rollout of this zone file is stopped and operations
staff is notified. Consistency checks of the loaded zone file is 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, mainly delivered by DNS.be.
An additional anycast mesh will be foreseen by IPCom (daughter of nic.at) 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 gTLD 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 name servers. 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 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 UDRP 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ʺ.

A ʺSunriseʺ will be foreseen for the proposed gTLD, more information about that
process can be found in the answer to question 18b.

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 by DNS.be (the registry
operator itself) 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 Back-End Registry 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 Back-End Registry
Operations.
Since some of 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 Back-End Registry 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.