gTLD	Full Legal Name	E-mail suffix	Detail
.dog	Koko Mill, LLC	donuts.co	View

Q23 CHAR: 22971

TLD Applicant is applying to become an ICANN accredited Top Level Domain (TLD) registry. TLD Applicant meets the operational, technical, and financial capability requirements to pursue, secure and operate the TLD registry. The responses to technical capability questions were prepared to demonstrate, with confidence, that the technical capabilities of TLD Applicant meet and substantially exceed the requirements proposed by ICANN.

The following response describes our registry services, as implemented by Donuts and our partners. Such partners include Demand Media Europe Limited (DMEL) for back-end registry services; AusRegistry Pty Ltd. (ARI) for Domain Name System (DNS) services and Domain Name Service Security Extensions (DNSSEC); an independent consultant for abuse mitigation and prevention consultation; Equinix and SuperNap for datacenter facilities and infrastructure; and Iron Mountain Intellectual Property Management, Inc. (Iron Mountain) for data escrow services. For simplicity, the term “company” and the use of the possessive pronouns “we”, “us”, “our”, “ours”, etc., all refer collectively to Donuts and our subcontracted service providers.

DMEL is a wholly-owned subsidiary of DMIH Limited, a well-capitalized Irish corporation whose ultimate parent company is Demand Media, Inc., a leading content and social media company listed on the New York Stock Exchange (ticker: DMD). DMEL is structured to operate a robust and reliable Shared Registration System by leveraging the infrastructure and expertise of DMIH and Demand Media, Inc., which includes years of experience in the operation side for domain names in both gTLDs and ccTLDs for over 10 years.

1.0. EXECUTIVE SUMMARY

We offer all of the customary services for proper operation of a gTLD registry using an approach designed to support the security and stability necessary to ensure continuous uptime and optimal registry functionality for registrants and Internet users alike.

2.0. REGISTRY SERVICES

2.1. Receipt of Data from registrars

The process of registering a domain name and the subsequent maintenance involves interactions between registrars and the registry. These interactions are facilitated by the registry through the Shared Registration System (SRS) through two interfaces:

- EPP: A standards-based XML protocol over a secure network channel.
- Web: A web based interface that exposes all of the same functionality as EPP yet accessible through a web browser.

Registrants wishing to register and maintain their domain name registrations must do so through an ICANN accredited registrar. The XML protocol, called the Extensible Provisioning Protocol (EPP) is the standard protocol widely used by registrars to communicate provisioning actions. Alternatively, registrars may use the web interface to create and manage registrations.

The registry is implemented as a “thick” registry meaning that domain registrations must have contact information associated with each. Contact information will be collected by registrars and associated with domain registrations.

2.1.1. SRS EPP Interface

The SRS EPP Interface is provided by a software service that provides network based connectivity. The EPP software is highly compliant with all appropriate RFCs including:

- RFC 5730 Extensible Provisioning Protocol (EPP)
- RFC 5731 Extensible Provisioning Protocol (EPP) Domain Name Mapping
- RFC 5732 Extensible Provisioning Protocol (EPP) Host Mapping
- RFC 5733 Extensible Provisioning Protocol (EPP) Contact Mapping
- RFC 5734 Extensible Provisioning Protocol (EPP) Transport over TCP
- RFC 5910 Domain Name System (DNS) Security Extensions for Extensible Provisioning Protocol (EPP)
- RFC 3915 Domain Registry Grace Period Mapping for EPP

2.1.1.1. SRS EPP Interface Security Considerations

Security precautions are put in place to ensure transactions are received only from authorized registrars in a private, secure manner. Registrars must provide the registry with narrow subnet ranges, allowing the registry to restrict network connections that originate only from these pre-arranged networks. The source IP address is verified against the authentication data received from the connection to further validate the source of the connection. Registrars may only establish a limited number of connections and the network traffic is rate limited to ensure that all registrars receive the same quality of service. Network connections to the EPP server must be secured with TLS. The revocation status and validity of the certificate are checked.

Successful negotiation of a TLS session begins the process of authentication using the protocol elements of EPP. Registrars are not permitted to continue without a successful EPP session establishment. The EPP server validates the credential information passed by the registrar along with validation of:

- Certificate revocation status
- Certificate chain
- Certificate Common Name matches the Common Name the registry has listed for the source IP address
- User name and password are correct and match those listed for the source IP address

In the event a registrar creates a level of activity that threatens the service quality of other registrars, the service has the ability to rate limit individual registrars.

2.1.1.2. SRS EPP Interface Stability Considerations

To ensure the stability of the EPP Interface software, strict change controls and access controls are in place. Changes to the software must be approved by management and go through a rigorous testing and staged deployment procedure.

Additional stability is achieved by carefully regulating the available computing resources. A policy of conservative usage thresholds leaves an equitable amount of computing resources available to handle spikes and service management.

2.1.2. SRS Web Interface

The SRS web interface is an alternative way to access EPP functionality using a web interface, providing the features necessary for effective operations of the registry. This interface uses the HTTPS protocol for secure web communication. Because users can be located worldwide, as with the EPP interface, the web interface is available to all registrars over multiple network paths.
Additional functionality is available to registrars to assist them in managing their account. For instance, registrars are able to view their account balance in near real time as well as the status of the registry services. In addition, notifications that are sent out in email are available for viewing.

2.1.2.1. Web Interface Security Considerations

Only registrars are authorized to use the SRS web interface, and therefore the web interface has several security measures to prevent abuse. The web interface requires an encrypted network channel using the HTTPS protocol. Attempts to access the interface through a clear channel are redirected to the encrypted channel.

The web interface restricts access by requiring each user to present authentication credentials before proceeding. In addition to the typical user name and password combinations, the web interface also requires the user to possess a hardware security key as a second factor of authentication.

Registrars are provided a tool to create and manage users that are associated with their account. With these tools, they can set access and authorization levels for their staff.

2.1.2.2. Web Interface Stability Considerations

Both the EPP interface and web interface use a common service provider to perform the work required to fulfill their requests. This provides consistency across both interfaces and ensures all policies and security rules are applied.

The software providing services for both interfaces executes on a farm of servers, distributing the load more evenly ensuring stability is maintained.

2.2. Dissemination of TLD Zone Files

2.2.1. Communication of Status Information of TLD Zone Servers to Registrars

The status of TLD zone servers and their ability to reflect changes in the SRS is of great importance to registrars and Internet users alike. We ensure that any change from normal operations is communicated to the relevant stakeholders as soon as is appropriate. Such communication might be prior to the status change, during the status change and⁄or after the status change (and subsequent reversion to normal) — as appropriate to the party being informed and the circumstance of the status change.

Normal operations are:

- DNS servers respond within SLAs for DNS resolution.
- Changes in the SRS are reflected in the zone file according to the DNS update time SLA.

The SLAs are those from Specification 10 of the Registry Agreement.

A deviation from normal operations, whether it is registry wide or restricted to a single DNS node, will result in the appropriate status communication being sent.

2.2.2. Communication Policy

We maintain close communication with registrars regarding the performance and consistency of the TLD zone servers.

A contact database containing relevant contact information for each registrar is maintained. In many cases, this includes multiple forms of contact, including email, phone and physical mailing address. Additionally, up-to-date status information of the TLD zone servers is provided within the SRS Web Interface.

Communication using the registrar contact information discussed above will occur prior to any maintenance that has the potential to effect the access to, consistency of, or reliability of the TLD zone servers. If such maintenance is required within a short timeframe, immediate communication occurs using the above contact information. In either case, the nature of the maintenance and how it affects the consistency or accessibility of the TLD zone servers, and the estimated time for full restoration, are included within the communication.

That being said, the TLD zone server infrastructure has been designed in such a way that we expect no downtime. Only individual sites will potentially require downtime for maintenance; however the DNS service itself will continue to operate with 100% availability.

2.2.3. Security and Stability Considerations

We restrict zone server status communication to registrars, thereby limiting the scope for malicious abuse of any maintenance window. Additionally, we ensure registrars have effective operational procedures to deal with any status change of the TLD nameservers and will seek to align its communication policy to those procedures.

2.3. Zone File Access Provider Integration

Individuals or organizations that wish to have a copy of the full zone file can do so using the Zone Data Access service. This process is still evolving; however the basic requirements are unlikely to change. All registries will publish the zone file in a common format accessible via secure FTP at an agreed URL.

DMEL will fully comply with the processes and procedures dictated by the Centralized Zone Data Access Provider (CZDA Provider or what it evolves into) for adding and removing Zone File access consumers from its authentication systems. This includes:

- Zone file format and location.
- Availability of the zone file access host via FTP.
- Logging of requests to the service (including the IP address, time, user and activity log).
- Access frequency.

2.4. Zone File Update

To ensure changes within the SRS are reflected in the zone file rapidly and securely, we update the zone file on the TLD zone servers following a staged but rapid propagation of zone update information from the SRS, outwards to the TLD zone servers - which are visible to the Internet. As changes to the SRS data occur, those changes are updated to isolated systems which act as the authoritative primary server for the zone, but remain inaccessible to systems outside our network. The primary servers notify the designated secondary servers, which service queries for the TLD zone from the public. Upon notification, the secondary servers transfer the incremental changes to the zone and publicly present those changes.

The mechanisms for ensuring consistency within and between updates are fully implemented in our TLD zone update procedures. These mechanisms ensure updates are quickly propagated while the data remains consistent within each incremental update, regardless of the speed or order of individual update transactions.

2.5. Operation of Zone Servers

ARI maintains TLD zone servers which act as the authoritative servers to which the TLD is delegated.

2.5.1. Security and Operational Considerations of Zone Server Operations

The potential risks associated with operating TLD zone servers are recognized by us such that we will perform the steps required to protect the integrity and consistency of the information they provide, as well as to protect the availability and accessibility of those servers to hosts on the Internet. The TLD zone servers comply with all relevant RFCs for DNS and DNSSEC, as well as BCPs for the operation and hosting of DNS servers. The TLD zone servers will be updated to support any relevant new enhancements or improvements adopted by the IETF.

The DNS servers are geographically dispersed across multiple secure data centers in strategic locations around the world. By combining multi-homed servers and geographic diversity, ARI’s zone servers remain impervious to site level, supplier level or geographic level operational disruption.

The TLD zone servers are protected from accessibility loss by malicious intent or misadventure, via the provision of significant over-capacity of resources and access paths. Multiple independent network paths are provided to each TLD zone server and the query servicing capacity of the network exceeds the extremely conservatively anticipated peak load requirements by at least 10 times, to prevent loss of service should query loads significantly increase.

As well as the authentication, authorization and consistency checks carried out by the registrar access systems and DNS update mechanisms, ARI reduces the scope for alteration of DNS data by following strict DNS operational practices:

- TLD zone servers are not shared with other services.
- The primary authoritative TLD zone server is inaccessible outside ARI’s network.
- TLD zone servers only serve authoritative information.
- The TLD zone is signed with DNSSEC and a DNSSEC Practice⁄Policy Statement published.

2.6. Dissemination of Domain Registration Information

Domain name registration information is required for a variety of purposes. Our registry provides this information through the required WHOIS service through a standard text based network protocol on port 43. Whois also is provided on the registry’s web site using a standard web interface. Both interfaces are publically available at no cost to the user and are reachable worldwide.

The information displayed by the Whois service consists not only of the domain name but also of relevant contact information associated with the domain. It also identifies nameserver delegation and the registrar of record. This service is available to any Internet user, and use of it does not require prior authorization or permission.

2.6.1. Whois Port 43 Interface

The Whois port 43 interface consists of a standard Transmission Control Protocol (TCP) server that answers requests for information over port 43 in compliance with IETF RFC 3912. For each query, the TCP server accepts the connection over port 43 and then waits for a set time for the query to be sent. This communication occurs via clear, unencrypted ASCII text. If a properly formatted and valid query is received, the registry database is queried for the registration data. If registration data exists, it is returned to the service where it is then formatted and delivered to the requesting client. Each query connection is short-lived. Once the output is transmitted, the server closes the connection.

2.6.2. Whois Web Interface

The Whois web interface also uses clear, unencrypted text. The web interface is in an HTML format suitable for web browsers. This interface is also available over an encrypted channel on port 43 using the HTTPS protocol.

2.6.3. Security and Stability Considerations

Abuse of the Whois system through data mining is a concern as it can impact system performance and reduce the quality of service to legitimate users. The Whois system mitigates this type of abuse by detecting and limiting bulk query access from single sources. It does this in two ways: 1) by rate limiting queries by non-authorized parties; and 2) by ensuring all queries result in responses that do not include data sets representing significant portions of the registration database.
In addition, the Whois web interface adds a simple challenge-response CAPCHA that requires a user to type in the characters displayed in image format.
Both systems have blacklist functionality to provide a complete block to individual IPs or IP ranges.

2.7. Internationalized Domain Names (IDNs)

An Internationalized Domain Name (IDN) contains at least one label that is displayed in a specific language script in IDN aware software. We will offer registration of second level IDN labels at launch,
IDNs are published into the TLD zone. The SRS EPP and Web Interfaces also support IDNs.
The IDN implementation is fully compliant with the IDNA 2008 suite of standards (RFC 5890, 5891, 5892 and 5893) as well as the ICANN Guidelines for the Implementation of IDN Version 3.0 〈http:⁄⁄www.icann.org⁄en⁄resources⁄idn⁄implementation-guidelines〉. To ensure stability and security, we have adopted a conservative approach in our IDN registration policies, as well as technical implementation.

All IDN registrations must be requested using the A-label form, and accompanied by an RFC 5646 language tag identifying the corresponding language table published by the registry. The candidate A-label is processed according to the registration protocol as specified in Section 4 of RFC 5891, with full U-label validation. Specifically, the “Registry Restrictions” steps specified in Section 4.3 of RFC 5891 are implemented by validating the U-label against the identified language table to ensure that the set of characters in the U-label is a proper subset of the character repertoire listed in the language table.

2.7.1. IDN Stability Considerations

To avoid the intentional or accidental registration of visually similar characters, and to avoid identity confusion between domains, there are several restrictions on the registration of IDNs.
Domains registered within a particular language are restricted to only the characters of that language. This avoids the use of visually similar characters within one language which mimic the appearance of a label within another language, regardless of whether that label is already within the DNS or not.
Child domains are restricted to a specific language and registrations are prevented in one language being confused with a registration in another language; for example Cyrillic а (U+0430) and Latin a (U+0061).

2.8. DNSSEC

DNSSEC provides a set of extensions to the DNS that allow an Internet user (normally the resolver acting on a user’s behalf) to validate that the DNS responses they receive were not manipulated en-route.
This type of fraud, commonly called ‘man in the middle’, allows a malicious party to misdirect Internet users. DNSSEC allows a domain owner to sign their domain and to publish the signature, so that all DNS consumers who visit that domain can validate that the responses they receive are as the domain owner intended.

Registries, as the operators of the parent domain for registrants, must publish the DNSSEC material received from registrants, so that Internet users can trust the material they receive from the domain owner. This is commonly referred to as a “chain of trust.” Internet users trust the root (operated by IANA), which publishes the registries’ DNSSEC material, therefore registries inherit this trust. Domain owners within the TLD subsequently inherit trust from the parent domain when the registry publishes their DNSSEC material.

In accordance with new gTLD requirements, the TLD zone will be DNSSEC signed and the receipt of DNSSEC material from registrars for child domains is supported in all provisioning systems.

2.8.1. Stability and Operational Considerations for DNSSEC

2.8.1.1. DNSSEC Practice Statement

ARI’s DNSSEC Practice Statement is included in our response to Question 43. The DPS following the guidelines set out in the draft IETF DNSOP DNSSEC DPS Framework document.

2.8.1.2. Resolution Stability

DNSSEC is considered to have made the DNS more trustworthy; however some transitional considerations need to be taken into account. DNSSEC increases the size and complexity of DNS responses. ARI ensures the TLD zone servers are accessible and offer consistent responses over UDP and TCP.

The increased UDP and TCP traffic which results from DNSSEC is accounted for in both network path access and TLD zone server capacity. ARI will ensure that capacity planning appropriately accommodates the expected increase in traffic over time.

ARI complies with all relevant RFCs and best practice guides in operating a DNSSEC-signed TLD. This includes conforming to algorithm updates as appropriate. To ensure Key Signing Key Rollover procedures for child domains are predictable, DS records will be published as soon as they are received via either the EPP server or SRS Web Interface. This allows child domain operators to rollover their keys with the assurance that their timeframes for both old and new keys are reliable.

3.0. APPROACH TO SECURITY AND STABILITY

Stability and security of the Internet is an important consideration for the registry system. To ensure that the registry services are reliably secured and remain stable under all conditions, DMEL takes a conservative approach with the operation and architecture of the registry system.

By architecting all registry services to use the least privileged access to systems and data, risk is significantly reduced for other systems and the registry services as a whole should any one service become compromised. By continuing that principal through to our procedures and processes, we ensure that only access that is necessary to perform tasks is given. ARI has a comprehensive approach to security modeled of the ISO27001 series of standards and explored further in the relevant questions of this response.

By ensuring all our services adhering to all relevant standards, DMEL ensures that entities which interact with the registry services do so in a predictable and consistent manner. When variations or enhancements to services are made, they are also aligned with the appropriate interoperability standards.

gTLD	Full Legal Name	E-mail suffix	Detail
.网站	Global Website TLD Asia Limited	namesphere.asia	View

We have engaged ARI Registry Services (ARI) to deliver services for this TLD. This response describes the registry services for our TLD, as provided by ARI.

1 INTRODUCTION

ARI’s Managed TLD Registry Service is a complete offering, providing all of the required registry services. What follows is a description of each of those services.

2 REGISTRY SERVICES
The following sections describe the registry services provided. Each of these services has, where required, been designed to take into account the requirements of consensus policies as documented here:
[http:⁄⁄www.icann.org⁄en⁄resources⁄Registrars⁄consensus-policies]
At the time of delegation into the root this TLD will not be offering any unique Registry services.

2.1 Receipt of Data from Registrars

The day-to-day functions of the registry, as perceived by Internet users, involves the receipt of data from Registrars and making the necessary changes to the SRS database. Functionality such as the creation, renewal and deletion of domains by Registrars, on behalf of registrants, is provided by two separate systems:
– An open protocol-based provisioning system commonly used by Registrars with automated domain management functionality within their own systems.
– A dedicated website providing the same functionality for user interaction.
Registrants (or prospective registrants) who wish to manage their existing domains or credentials, register new domains or delete their domains will have their requests carried out by Registrars using one of the two systems described below.
ARI operates Extensible Provisioning Protocol (EPP) server software and distributes applicable toolkits to facilitate the receipt of data from Registrars in a common format. EPP offers a common protocol for Registrars to interact with SRS data and is favoured for automating such interaction in the Registrar’s systems. In addition to the EPP server, Registrars have the ability to use a web-based management interface (SRS Web Interface), which provides functions equivalent to the EPP server functionality.

2.1.1 EPP

The EPP software allows Registrars to communicate with the SRS using a standard protocol. The EPP server software is compliant with all appropriate RFCs and will be updated to comply with any relevant new RFCs or other new standards, as and when they are finalised. All standard EPP operations on SRS objects are supported.
Specifically, the EPP service complies with the following standards:
– RFC 5730 Extensible Provisioning Protocol (EPP)
– RFC 5731 Extensible Provisioning Protocol (EPP) Domain Name Mapping
– RFC 5732 Extensible Provisioning Protocol (EPP) Host Mapping
– RFC 5733 Extensible Provisioning Protocol (EPP) Contact Mapping
– RFC 5734 Extensible Provisioning Protocol (EPP) Transport over TCP
– RFC 5910 Domain Name System (DNS) Security Extensions for the Extensible Provisioning Protocol (EPP)
– RFC 3915 Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)
– Extensions to ARI’s EPP service comply with RFC 3735 Guidelines for Extending the Extensible Provisioning Protocol (EPP)

2.1.1.1 Security for EPP Service

To avoid abuse and to mitigate potential fraudulent operations, the EPP server software uses a number of security mechanisms that restrict the source of incoming connections and prescribe the authentication and authorisation of the client. Connections are further managed by command rate limiting and are restricted to only a certain number for each Registrar, to help reduce unwanted fraudulent and other activities. Additionally, secure communication to the EPP interface is required, lowering the likelihood of the authentication mechanisms being compromised.
The EPP server has restrictions on the operations it is permitted to make to the data within the registry database. Except as allowed by the EPP protocol, the EPP server cannot update the credentials used by Registrars for access to the SRS. These credentials include those used by Registrars to login to ARI’s SRS Web Interface and the EPP service.
Secure communication to the EPP server is achieved via the encryption of EPP sessions. The registry system and associated toolkits support AES 128 and 256 via TLS.
The Production and Operational Testing and Evaluation (OTE) EPP service is protected behind a secure firewall that only accepts connections from registered IP addresses. Registrars are required to supply host IP addresses that they intend to use to access the EPP service.
Certificates are used for encrypted communications with the registry. Registrars require a valid public⁄private key pair signed by the ARI CA to verify authenticity. These certificates are used to establish a TLS secure session between client and server.
EPP contains credential elements in its specification which are used as an additional layer of authentication. In accordance with the EPP specification, the server does not allow client sessions to carry out any operations until credentials are verified.
The EPP server software combines the authentication and authorisation elements described above to ensure the various credentials supplied are associated with the same identity. This verification requires that:
– The username must match the common name in the digital certificate.
– The certificate must be presented from a source IP listed against the Registrar whose common name appears in the certificate.
– The username and password must match the user name and password listed against the Registrar’s account with that source IP address.
To manage normal operations and prevent an accidental or intentional Denial of Service, the EPP server can be configured to rate limit activities by individual Registrars.

2.1.1.2 Stability Considerations

The measures that restrict Registrars to a limit of connections and operations for security purposes also serve to keep the SRS and the EPP server within an acceptable performance and resource utilisation band. Therefore, scaling the service is an almost linear calculation based on well-defined parameters.
The EPP server offers consistent information between Registrars and the SRS Web Interface. The relevant pieces of this information are replicated to the DNS within seconds of alteration, thus ensuring that a strong consistency between the SRS and DNS is maintained at all times.

2.1.2 SRS Web Interface

The registry SRS Web Interface offers Registrars an alternative SRS interaction mechanism to the EPP server. Available over HTTPS, this interface can be used to carry out all operations which would otherwise occur via EPP, as well as many others. Registrars can use the SRS Web Interface, the EPP server interface or both – with no loss of consistency within the SRS.

2.1.2.1 Security and Consistency Considerations for SRS Web Interface

The SRS Web Interface contains measures to prevent abuse and to mitigate fraudulent operations. By restricting access, providing user level authentication and authorisation, and protecting the communications channel, the application limits both the opportunity and scope of security compromise.
Registrars are able to create individual users that are associated with their Registrar account. By allocating the specific operations each user can access, Registrars have full control over how their individual staff members interact with the SRS. Users can be audited to identify which operations were conducted and to which objects those operations were applied.
A secure connection is required before credentials are exchanged and once authenticated. On login, any existing user sessions are invalidated and a new session is generated, thereby mitigating session-fixation attacks and reducing possibilities that sessions could be compromised.

2.1.3 Securing and Maintaining Consistency of Registry-Registrar Interaction Systems

ARI ensures all systems through which Registrars interact with the SRS remain consistent with each other and apply the same security rules. Additionally, ARI also ensures that operations on SRS objects are restricted to the appropriate entity. For example:
– In order to initiate a transfer a Registrar must provide the associated domain password (authinfo) which will only be known by the registrant and the current sponsoring Registrar.
– Only sponsoring Registrars are permitted to update registry objects.
All operations conducted by Registrars on SRS objects are auditable and are identifiable to the specific Registrar’s user account, IP address and the time of the operation.

2.2 Disseminate Status Information of TLD Zone Servers to Registrars

The status of TLD zone servers and their ability to reflect changes in the SRS is of great importance to Registrars and Internet users alike. ARI will ensure that any change from normal operations is communicated to the relevant stakeholders as soon as is appropriate. Such communication might be prior to the status change, during the status change and⁄or after the status change (and subsequent reversion to normal) – as appropriate to the party being informed and the circumstance of the status change.
Normal operations are those when:
– DNS servers respond within SLAs for DNS resolution.
– Changes in the SRS are reflected in the zone file according to the DNS update time SLA.
The SLAs are those from Specification 10 of the Registry Agreement.
A deviation from normal operations, whether it is registry wide or restricted to a single DNS node, will result in the appropriate status communication being sent.

2.2.1 Communication Policy

ARI maintains close communication with Registrars regarding the performance and consistency of the TLD zone servers.
A contact database containing relevant contact information for each Registrar is maintained. In many cases, this includes multiple forms of contact, including email, phone and physical mailing address. Additionally, up-to-date status information of the TLD zone servers is provided within the SRS Web Interface.
Communication using the Registrar contact information discussed above will occur prior to any maintenance that has the potential to effect the access to, consistency of, or reliability of the TLD zone servers. If such maintenance is required within a short time frame, immediate communication occurs using the above contact information. In either case, the nature of the maintenance and how it affects the consistency or accessibility of the TLD zone servers, and the estimated time for full restoration, are included within the communication.
That being said, the TLD zone server infrastructure has been designed in such a way that we expect no down time. Only individual sites will potentially require downtime for maintenance; however the DNS service itself will continue to operate with 100% availability.

2.2.2 Security and Stability Considerations

ARI restricts zone server status communication to Registrars, thereby limiting the scope for malicious abuse of any maintenance window. Additionally, ARI ensures Registrars have effective operational procedures to deal with any status change of the TLD nameservers and will seek to align its communication policy to those procedures.

2.3 Zone File Access Provider Integration

Individuals or organisations that wish to have a copy of the full zone file can do so using the Zone Data Access service. This process is still evolving; however the basic requirements are unlikely to change. All registries will publish the zone file in a common format accessible via secure FTP at an agreed URL.

ARI will fully comply with the processes and procedures dictated by the Centralised Zone Data Access Provider (CZDA Provider or what it evolves into) for adding and removing Zone File access consumers from its authentication systems. This includes:

– Zone file format and location
– Availability of the zone file access host via FTP
– Logging of requests to the service (including the IP address, time, user and activity log)
– Access frequency

2.4 Zone File Update

To ensure changes within the SRS are reflected in the zone file rapidly and securely, ARI updates the zone file on the TLD zone servers using software compliant with RFC 2136 (Dynamic Updates in the Domain Name System (DNS UPDATE)) and RFC 2845 (Secret Key Transaction Authentication for DNS (TSIG)).
This updating process follows a staged but rapid propagation of zone update information from the SRS, outwards to the TLD zone servers – which are visible to the Internet. As changes to the SRS data occur, those changes are updated to isolated systems which act as the authoritative primary server for the zone, but remain inaccessible to systems outside ARI’s network. The primary servers notify the designated secondary servers, which service queries for the TLD zone from the public. Upon notification, the secondary servers transfer the incremental changes to the zone and publicly present those changes.
The protocols for dynamic update are robust and mature, as is their implementation in DNS software. The protocols’ mechanisms for ensuring consistency within and between updates are fully implemented in ARI’s TLD zone update procedures. These mechanisms ensure updates are quickly propagated while the data remains consistent within each incremental update, regardless of the speed or order of individual update transactions. ARI has used this method for updating zone files in all its TLDs including the .au ccTLD, pioneering this method during its inception in 2002. Mechanisms separate to RFC 2136-compliant transfer processes exist; to check and ensure domain information is consistent with the SRS on each TLD zone server within 10 minutes of a change.

2.5 Operation of Zone Servers

ARI maintains TLD zone servers which act as the authoritative servers to which the TLD is delegated.

2.5.1 Security and Operational Considerations of Zone Server Operations

The potential risks associated with operating TLD zone servers are recognised by ARI such that we will perform the steps required to protect the integrity and consistency of the information they provide, as well as to protect the availability and accessibility of those servers to hosts on the Internet. The TLD zone servers comply with all relevant RFCs for DNS and DNSSEC, as well as BCPs for the operation and hosting of DNS servers. The TLD zone servers will be updated to support any relevant new enhancements or improvements adopted by the IETF.
The DNS servers are geographically dispersed across multiple secure data centres in strategic locations around the world. By combining multi-homed servers and geographic diversity, ARI’s zone servers remain impervious to site level, supplier level or geographic level operational disruption.
The TLD zone servers are protected from accessibility loss by malicious intent or misadventure, via the provision of significant over-capacity of resources and access paths. Multiple independent network paths are provided to each TLD zone server and the query servicing capacity of the network exceeds the extremely conservatively anticipated peak load requirements by at least 10 times, to prevent loss of service should query loads significantly increase.
As well as the authentication, authorisation and consistency checks carried out by the Registrar access systems and DNS update mechanisms, ARI reduces the scope for alteration of DNS data by following strict DNS operational practices:
– TLD zone servers are not shared with other services.
– The primary authoritative TLD zone server is inaccessible outside ARI’s network.
– TLD zone servers only serve authoritative information.
– The TLD zone is signed with DNSSEC and a DNSSEC Practice⁄Policy Statement published.

2.6 Dissemination of Contact or Other Information

Registries are required to provide a mechanism to identify the relevant contact information for a domain. The traditional method of delivering this is via the WhoIs service, a plain text protocol commonly accessible on TCP port 43. ARI also provides the same functionality to users via a web-based WhoIs service. Functionality remains the same with the web-based service, which only requires a user to have an Internet browser.
Using the WhoIs service, in either of its forms, allows a user to query for domain-related information. Users can query for domain details, contact details, nameserver details or Registrar details.
A WhoIs service, which complies with RFC 3912, is provided to disseminate contact and other information related to a domain within the TLD zone.

2.6.1 Security and Stability Considerations

ARI ensures the service is available and accurate for Internet users, while limiting the opportunity for its malicious use. Many reputation and anti-abuse services rely on the availability and accuracy of the WhoIs service, however the potential for abuse of the WhoIs service exists.
Therefore, certain restrictions are made to the access of WhoIs services, the nature of which depend on the delivery method – either web-based or the traditional text-based port 43 service. In all cases, there has been careful consideration given to the benefits of WhoIs to the Internet community, as well as the potential harm to registrants – as individuals and a group – with regard to WhoIs access restrictions.
The WhoIs service presents data from the registry database in real time. However this access is restricted to reading the appropriate data only. The WhoIs service does not have the ability to alter data or to access data not related to the WhoIs service. The access limitations placed on the WhoIs services prevent any deliberate or incidental denial of service that might impact other registry services.
Restrictions placed on accessing WhoIs services do not affect legitimate use. All restrictions are designed to target abusive volume users and to provide legitimate users with a fast and available service. ARI has the ability to ‘whitelist’ legitimate bulk users of WhoIs, to ensure they are not impacted by standard volume restrictions.
The data presentation format is consistent with the canonical representation of equivalent fields, as defined in the EPP specifications and ICANN agreement.

2.6.1.1 Port 43 WhoIs

A port 43-based WhoIs service complying with RFC 3912 is provided and will be updated to meet any other relevant standards or best practice guidelines related to the operation of a WhoIs service.
While the text-based service can support thousands of simultaneous queries, it has dynamic limits on queries per IP address to restrict data mining efforts. In the event of identified malicious use of the service, access from a single IP address or address ranges can be limited or blocked.

2.6.1.2 Web-based WhoIs

ARI’s web-based WhoIs service provides information consistent with that contained within the SRS.
The web-based WhoIs service contains an Image Verification Check (IVC) and query limits per IP address. These restrictions strike a balance between acceptable public usage and abusive use or data mining. The web-based WhoIs service can blacklist IP addresses or ranges to prevent abusive use of the service.

2.7 IDNs – Internationalised Domain Names

An Internationalised Domain Name (IDN) allows registrants to register domains in their native language and have it display correctly in IDN aware software. This includes allowing a language to be read in the manner that would be common for its readers. For example, an Arabic domain would be presented right to left for an Arabic IDN aware browser.
The inclusion of IDNs into the TLD zones is supported by ARI. All the registry services, such as the EPP service, SRS Web Interface and RDPS (web and port 43), support IDNs. However there are some stability and security considerations related to IDNs which fall outside the general considerations applicable individually to those services.

2.7.1 Stability Considerations Specific to IDN

To avoid the intentional or accidental registration of visually similar chars, and to avoid identity confusion between domains, there are several restrictions on the registration of IDNs.

2.7.1.1 Prevent Cross Language Registrations

Domains registered within a particular language are restricted to only the chars of that language. This avoids the use of visually similar chars within one language which mimic the appearance of a label within another language, regardless of whether that label is already within the DNS or not.

2.7.1.2 Inter-language and Intra-language Variants to Prevent Similar Registrations

ARI restricts child domains to a specific language and prevents registrations in one language being confused with a registration in another language, for example Cyrillic а (U+0430) and Latin a (U+0061).

2.8 DNSSEC

DNSSEC provides a set of extensions to the DNS that allow an Internet user (normally the resolver acting on a user’s behalf) to validate that the DNS responses they receive were not manipulated en-route.
This type of fraud, commonly called ‘man in the middle’, allows a malicious party to misdirect Internet users. DNSSEC allows a domain owner to sign their domain and to publish the signature, so that all DNS consumers who visit that domain can validate that the responses they receive are as the domain owner intended.
Registries, as the operators of the parent domain for registrants, must publish the DNSSEC material received from registrants, so that Internet users can trust the material they receive from the domain owner. This is commonly referred to as a ‘chain of trust’. Internet users trust the root (operated by IANA), which publishes the registries’ DNSSEC material, therefore registries inherit this trust. Domain owners within the TLD subsequently inherit trust from the parent domain when the registry publishes their DNSSEC material.
In accordance with new gTLD requirements, the TLD zone will be DNSSEC signed and the receipt of DNSSEC material from Registrars for child domains is supported in all provisioning systems.

2.8.1 Stability and Operational Considerations for DNSSEC

2.8.1.1 DNSSEC Practice Statement

ARI’s DNSSEC Practice Statement is included in our response to Question 43. The DPS following the guidelines set out in the draft IETF DNSOP DNSSEC DPS Framework document.

2.8.1.2 Receipt of Public Keys from Registrars

The public key for a child domain is received by ARI from the Registrar via either the EPP or SRS Web Interface. ARI uses an SHA-256 digest to generate the DS Resource Record (RR) for inclusion into the zone file.

2.8.1.3 Resolution Stability

DNSSEC is considered to have made the DNS more trustworthy; however some transitional considerations need to be taken into account. DNSSEC increases the size and complexity of DNS responses. ARI ensures the TLD zone servers are accessible and offer consistent responses over UDP and TCP.
The increased UDP and TCP traffic which results from DNSSEC is accounted for in both network path access and TLD zone server capacity. ARI will ensure that capacity planning appropriately accommodates the expected increase in traffic over time.
ARI complies with all relevant RFCs and best practice guides in operating a DNSSEC-signed TLD. This includes conforming to algorithm updates as appropriate. To ensure Key Signing Key Rollover procedures for child domains are predictable, DS records will be published as soon as they are received via either the EPP server or SRS Web Interface. This allows child domain operators to rollover their keys with the assurance that their timeframes for both old and new keys are reliable.

3 APPROACH TO SECURITY AND STABILITY

Stability and security of the Internet is an important consideration for the registry system. To ensure that the registry services are reliably secured and remain stable under all conditions, ARI takes a conservative approach with the operation and architecture of the registry system.
By architecting all registry services to use the least privileged access to systems and data, risk is significantly reduced for other systems and the registry services as a whole should any one service become compromised. By continuing that principal through to our procedures and processes, we ensure that only access that is necessary to perform tasks is given. ARI has a comprehensive approach to security modelled of the ISO27001 series of standards and explored further in the relevant questions of this response.
By ensuring all our services adhering to all relevant standards, ARI ensures that entities which interact with the registry services do so in a predictable and consistent manner. When variations or enhancements to services are made, they are also aligned with the appropriate interoperability standards.