Back

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

gTLDFull Legal NameE-mail suffixDetail
.expertRed Circle, LLCfreundandbrackey.comView
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.
gTLDFull Legal NameE-mail suffixDetail
.عربLeague of Arab Stateslas.intView
The League of Arab States (LAS) has engaged the Telecommunications Regulatory Authority UAE (TRA) to deliver registry services for this TLD. This response describes the Registry Services for this TLD as provided by TRA.


1 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]

1.1 Receipt of Data from Registrars

The day-to-day function of the Registry, as perceived by Internet users, involves the receipt of data from Registrars and making the necessary changes to the Shared Registry System (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 either 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.

TRA 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.

1.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 Requests for Comments (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 TRA’s EPP service comply with RFC 3735 Guidelines for Extending the Extensible Provisioning Protocol (EPP).

1.1.1.1 Security for EPP Service

To avoid abuse and to mitigate potential fraudulent operations, the EPP server software employs a number of security mechanisms which 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, in order to reduce unwanted fraudulent and disingenuous activities. Additionally, secure communication to the EPP interface is a requirement, 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 TRA’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 all of the 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 TRA Certificate Authority (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 (DoS), the EPP server can be configured to rate limit activities by individual Registrars.

1.1.1.2 Stability Considerations

The security measures that restrict Registrars to a limit of connections and operations 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, with the relevant pieces of this information being replicated to the DNS within seconds of alteration; thus ensuring that a strong consistency between the SRS and DNS is maintained at all times.

1.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.

1.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 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. Upon login, any existing user sessions are invalidated and a new session is generated, thereby mitigating session-fixation attacks and reducing the possibility that sessions could be compromised.

1.1.3 Securing and Maintaining Consistency of Registry-Registrar Interaction Systems

TRA ensures all systems through which Registrars can interact with the SRS remain consistent with each other and apply the same security rules. Additionally, TRA 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 be known only 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 identifiable to the specific Registrar’s user account, their IP address and the time of the operation.

1.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 vital importance to Registrars and Internet users alike. TRA will ensure that any change from normal operations is communicated to the relevant stakeholders as soon as is appropriate. Such communication may 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 registry-wide or restricted to a single DNS node, will result in the appropriate status communication being sent.

1.2.1 Communication Policy

TRA maintains close communication with Registrars regarding performance and consistency of the TLD zone servers. A contact database containing relevant contact information for each Registrar is maintained. In many cases, this will include 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 performed with 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, how it affects the consistency or accessibility of the TLD zone servers and the estimated time for full restoration are included within the communication.

The TLD zone server infrastructure has been designed in such a way that no down time is expected. Only individual sites will potentially require downtime for maintenance; however the DNS service itself will continue to operate at 100% availability.

1.2.2 Security and Stability Considerations

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

1.3 Zone File Access Provider Integration

Individuals or organisations who 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 that is accessible via secure File Transfer Protocol (FTP) at an agreed URL. TRA will fully comply with the processes and procedures as dictated by the Centralised Zone Data Access (CZDA or what it evolves into) Provider for adding and removing Zone File access consumers from 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.

1.4 Zone File Update

To ensure changes within the SRS are rapidly and securely reflected in the zone file, TRA 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 TRA’s network, with the exception of externally located secondary services (discussed in 2.5). 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 publically 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 TRA’s TLD zone update procedures. These mechanisms ensure that updates are quickly propagated while the data remains consistent within each incremental update, regardless of the speed or order of individual update transactions. Mechanisms separate to RFC 2136-compliant transfer processes exist in order to ensure domain information is consistent with the SRS on each TLD zone server within 10 minutes of a change.

1.5 Operation of Zone Servers

TRA uses ARI Registry Services (ARI) to deliver DNS services for the TLD. The following section describes ARI’s TLD zone server service.

1.5.1 Security and Operational Considerations of Zone Server Operations

The TLD zone servers comply with all relevant RFCs for DNS, DNSSEC and 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 loss in accessibility 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, in order 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, TRA reduces the scope for alteration of DNS data by following strict DNS operational practices:
– Requirement that ARI TLD zone servers are not shared with other services.
– TRA’s primary authoritative TLD zone server is inaccessible from outside their network with the strict and only exception of ARI’s TLD zone server network.
– TLD zone servers only serve authoritative information.
– The TLD zone is signed with DNSSEC and a published DNSSEC Practice⁄Policy Statement.

1.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. TRA 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.

1.6.1 Security and Stability Considerations

TRA 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 which 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 a fast and available service. TRA has the ability to white list 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.

1.6.1.1 Port 43 WhoIs

A port 43-based WhoIs service that complies 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, in order to restrict data mining efforts, it has dynamic limits on queries per IP address. In the event of identified malicious use of the service, access from a single IP address or address ranges can be limited or blocked.

1.6.1.2 Web Based WhoIs

TRA’s web-based WhoIs service provides information that is 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.

1.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 within an Arabic IDN aware browser.

The inclusion of IDNs into the TLD zones is supported by TRA. All of the Registry services, such as the EPP service, SRS Web Interface and Registration Data Directory Services (RDDS) (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.

1.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.

1.7.1.1 Prevent Cross Language Registrations

Domains registered within a particular language are restricted to just 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.

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

TRA 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).

1.8 Domain Name System Security Extensions (DNSSEC)

DNSSEC provides a set of extensions to the DNS that allows 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 intended by the domain owner.
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 received 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.

1.8.1 Stability and Operational Considerations for DNSSEC

1.8.1.1 DNSSEC Practice Statement

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

1.8.1.2 Receipt of Public Keys from Registrars

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

1.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. TRA and ARI, as the zone server provider, ensure the TLD zone servers are accessible and offer consistent responses over UDP and TCP.

The increased UDP & TCP traffic which results from DNSSEC is accounted for in both network path access and TLD zone server capacity. TRA and ARI will ensure that capacity planning appropriately accommodates the expected increase in traffic over time.
TRA and ARI comply 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 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.


2 APPROACHES TO SECURITY AND STABILITY

Stability and security of the Internet is a key consideration for the Registry system. To ensure that the Registry services are reliably secured and remain stable under all conditions, TRA 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 applying that principle to procedures and processes, it is ensured that access is given only to that which is necessary to perform tasks. TRA has a comprehensive approach to security which is modelled off the ISO27001 series of standards and explored further in the relevant questions of this response.

By ensuring all the services adhere to all relevant standards, TRA ensures 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.