Back

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

gTLDFull Legal NameE-mail suffixDetail
.autoUniregistry, Corp.internet.proView
TABLE OF CONTENTS

23.1 SUMMARY
23.2 OPERATIONS
23.2.1 Registry Operations Team
23.2.2 Registry Systems
23.3 SERVICES
23.3.1 Object Registrations
23.3.2 Receipt of Data From Registrars
23.3.3 Dissemination of TLD zone files
23.3.4 Dissemination of contact or other information concerning domain name registrations
23.3.5 Internationalized Domain Names
23.3.6 DNS Security Extensions (DNSSEC)
23.3.7 Registry Operations Center (ROC)
23.3.8 Abuse Mitigation and Prevention
23.4 GENERAL RESOURCING PLANS FOR THE REGISTRY
23.4.1 Human Resources

- - - - -

23.1. SUMMARY

Our various registry services fall into these categories:

* Services to Registrars
** Object Registration and Management (Extensible Provisioning Protocol (EPP) , Registrar Web Interface, Registrar Toolkit)
** Notification, information, and documentation
* Services to Registrants
** Internationalized Domain Name (IDN) registration
** DNSSEC
** Publication of zone file data (DNS name servers)
** Anycast management of replicated DNS servers
* Services to the public
** Classic WHOIS
** Tiered access by registered and authenticated users
* Maintenance services for the registry itself
** Generation of zone files
** DNSSEC signing of zone files
** Dissemination of zone files
** Zone file access
* Abuse Mitigation and Prevention
** Server protection strategies and mechanisms
** Abuse monitoring, recording, and analysis.
** Security and Stability Operational Practices
* Registry Operations Center (ROC)
23.2. OPERATIONS

23.2.1. Registry Operations Team

Registry operations are outsourced to and performed by Internet Systems Consortium, Inc (ISC).

Founded in 1994, ISC has been a vanguard in the growth and stability of the Internet. In addition to its better-known role as a technology leader and developer, ISC is one of the worldʹs most important organizations entrusted with management of Internetʹs essential infrastructures. From respected and prolific standards development for DNS, DNSSEC and IPv6; development and maintenance of the widely-used BIND and DHCP open source software; deployment and operation of critical global Internet services such as F-Root and SNS; to leadership in abuse prevention and mitigation strategies and tools, ISC is the worldʹs preeminent expert in the technology and operation of the Domain Name System.

ISC operates the F-root server, one of the 13 root server complexes on the internet. ISC pioneered use of the anycast routing technology that allows DNS servers to be replicated to improve performance, reliability, and resistance to attack. Today the F-root has 59 anycasted instances that are globally distributed and strategically placed at highly-connected nexus locations. F-root instances are also installed in more remote regions around the world such as in Mongolia and Fiji. This diversity was specifically pursued to increase resilience and performance for small and remote developing countries. This anycast architecture has been adopted by other root server operators and also by many gTLDs and ccTLDs, including .com, .net, and .org. Since shortly after its founding in 1994, ISC has maintained 100% up-time for F-root, and today the servers that implement F-root handle approximately 25% of the Internetʹs root traffic.

ISC provides other critical resources and services such as Secondary DNS for more than 50 ccTLD registries and non-profit organizations (including ICANN). ISC has long operated its own hosting facilities and provided hosting to key Internet open source projects such as Linux, Mozilla, FreeBSD, and the Internet Archive.

As new needs arise, ISC continues to develop and offer new services to support an open and robust Internet. One such project is the Resiliency and Security Forum, which operates the Security Information Exchange (SIE). SIE provides summary or distilled feeds of combined global DNS activities in real time to qualified recipients, which enables a pro-active defense against cybercrime. Recently ISC was a participant in a public⁄private partnership with law enforcement agencies around the world to assist with the largest takedown of a botnet in history.

ISC has one of the worldʹs largest operational deployments of DNSSEC.

ISC and its people are widely trusted around the world. Of the 21 people worldwide (known as the Trusted Community Representatives, or TCRs) who are entrusted with the DNSSEC keys to the root zone, two are ISC employees.

Under such pedigree, ISC has developed the next-generation Registry Services Platform presented in this application.

The Internet Systems Consortium is incorporated in the US state of Delaware, with employees in numerous countries around the world.

23.2.2. Registry Systems

Our systems are state-of-the-art and designed to meet the highest standards of TLD operational performance, reliability, scalability, and security. All components of the technical infrastructure for the registry have been built with 8 to 10 times the forecast capacity for our largest scenario of registration volumes. Thus, the capacity of the technical infrastructure is scaled at a level that covers the full range of projected volumes from ʺWorst Caseʺ to ʺBest Caseʺ without large or incremental capital costs for infrastructure and is easily scalable to higher volumes if required.

The registry is built as several major subsystems, each of which, in turn, is implemented as a collection of subsidiary services. This way we can use the most appropriate technologies for each subsystem and service, to obtain flexibility and scalability while retaining security, robust resilience to load and attack, and high availability.

Many of the major components of the registry system have been in use in commercial services on the Internet. The components that were developed specifically for Registry use have been carefully integrated with and tested with those existing components.

Our registry protects registration data and performance levels across all of its information services. Our system engineers have put a major emphasis on design review, high-reliability engineering methodologies, and structured testing to ensure that consistency and referential integrity is maintained even in the event of a catastrophic incident.

Every aspect of every module is designed and built to be be robust, replicated, and recoverable:

* Multiple data centers, with wide geographic diversity, that mutually support one another for backup and failover.
* Hardware uses redundant elements such as power supplies, RAID storage, and Error Correcting (ECC) memory.
* All network connectivity uses redundant interfaces, geographically differentiated pathways, and automatic fall backs.
* User facing systems are all replicated with no single point of failure and automatic failover to a backup system.
* Load balancing techniques are incorporated to prevent overload of any single user-facing component.
* Firewalls are used to prevent most malicious traffic from even reaching registry systems.
* All registrar and other non-public network service interfaces are protected by access lists, encryption, and authentication.
* Public network service interfaces are protected by rate limiters that can be activated when needed.
* Databases are built using an architecture employing master servers with hot standbys.
* The database has been configured so that rigorous quality and consistency checks are automatically enforced throughout the lifetime of the data.
* Database files can be backed up or moved without interrupting online services.
* All systems are monitored 24x7x365 by a worldwide array of hardware and performance monitors backed by the Registry Operations Center (ROC).
* The Registry Operations Center is backed by a worldwide staff that is ready to assist the operations staff or (in case of disaster) to take over its operation, all without interrupting user services.
* Every transaction is time stamped and permanently logged in journals that can be used for audits or data reconstruction.
* Data, systems, and operations are distributed so that no single event could cause an outage longer than a few seconds while transition occurs. Most systems would have no user perceived outages at all.
The use of replication as a fundamental design element means that the system can scale and adapt in response to equipment, software, or network failures.

23.3. SERVICES

23.3.1. Object Registrations

One of the principal objectives of any Internet Domain Registry is to manage the allocation, registration, and status of Internet Objects: Domain Names, Contacts, and Hosts (name servers).

From the point of view of the registry, a Domain Name comes into existence when it has been registered by an accredited Registrar, there is no requirement of zone file appearance for a domain name to be considered as registered. This is clearly stated in RFC 5731 (section 3.2.1). To be eligible to be included in the TLD zone file, at least two name servers must be associated with the registered domain name. In other words, names that are registered but which do not have at least two name servers are not published into the TLD zone file. Whois data is published for a registered name whether or not that name is included in the TLD zone file.

Contact information is managed as specified in RFC 5733. Our base requirement is that contact information be in English (US-ASCII). However, in order to allow local language communities to make full use of our registry we allow contact information in other languages and their characters sets. This provides the opportunity for fully localized contact or domain records, both of which show information in both English (US-ASCII) as well as the localized languages that might be required.

23.3.1.1. Host Registrations

Host registrations are subjected to a series of checks to prevent unauthorized creation of glue records. In the same manner, periodic audits are performed to detect and flag lame server delegations (name servers to which a domain has been delegated but which have not been configured to serve any data for that domain.)

Host registrations are verified for compliance with RFC 953 and RFC 1035 and compliance with the restrictions related to IDN that have been explained elsewhere in this document.

Periodic audits are performed on contact information to flag potentially inaccurate or incomplete information.

Registrars are notified of suspect contact data via the messaging interfaces in the EPP protocol and our Registrar Web Interface.

23.3.1.2. Blocked Name or ʺDesignated Resolver Nameʺ

ʺBlocked Namesʺ are names which a trademark owner does not want to use but wants to prevent others from using. Blocked names are offered during Sunrise, and go through the same registration path as Sunrise names. With a ʺblocked name,ʺ however, the TM owner indicates in the Sunrise application that it desires a blocked name instead of a resolving name. The WHOIS for a blocked name looks like that of a Sunrise name. The registrant of a blocked name cannot change the nameservers.

23.3.2. Receipt of Data From Registrars

Our Back-end Registry Service provides ICANN-accredited registrars with a standards-based interface to perform domain registration operations.

Registrars may use this service in two ways:

* An Extensible Provisioning Protocol (EPP) interface.
* A Registrar Web interface.
23.3.2.1. Extensible Provisioning Protocol Interface

Our platform implements the standard EPP protocol as described by RFC 5730. We also implement Internet Engineering Task Force (IETF) defined mappings for Domain Names (RFC 5731), Internet Hosts (RFC 5732), and Contacts (RFC 5733). Our EPP is carried over the TCP protocol (RFC 5734) and operates in dual stack IPv4⁄IPv6 mode.

Strong security ensures that this interface may be used only by known entities that have been accredited by both ICANN and our Registry. Use of this secure Registry Service is tightly controlled at multiple levels:

* Secure encrypted channels (TLS) using X.509 Certificate validation back to a known certificate issuing authority.
* Dual static IPv4⁄IPv6 DPI Firewalls to filter out irrelevant and suspect incoming traffic.
* Behavior and anomaly traffic monitoring using IPFIX technologies.
* IPv4⁄IPv6 source address verification (IP address whitelists).
* User authentication (user⁄password) at the application level.
In conformance with standard gTLD registry practices, the Registry Service implements the DNS security extensions for the EPP protocol (RFC 5910), allowing registrars to include secure delegation points to DNSSEC signed zones.

Similarly, the system incorporates Domain Grace Period Mapping (RFC 3915), to comply with TLD extended life cycles.

To support Internationalized Domain Names (IDN), we use a custom EPP extension to specify the language tag in which the domain name has been coded, allowing the application of IDN registration policy as mandated by the TLD manager.

Scalability and high performance are achieved through the use of multiple front-end servers, each running the EPP service. Each Front-end EPP instance is capable of querying multiple Back-end servers that, in turn, have access to a master database for read⁄write operations. In addition there are server and database replicas to support read-only operations (checks, info, etc.) and thus reduce the burden of the read-write database facility.

With EPP, registrars can verify the result of each transaction and have confidence that the operations reported as successful have indeed been processed by the registry.

We time stamp and log all EPP transactions for auditing, capacity planning, offline attack analysis, or forensic reconstruction. We retain these logs indefinitely and securely.

23.3.2.2. Registrar Web Interface

The Registrar Web Interface is designed to complement the EPP Interface, to provide Registrars with backup access to the registry in the unlikely event that its EPP clients are not functional. The Registrar Web Interface supplies a set of domain management functions of the EPP interface and also additional functionality not available within the EPP protocol itself. The Registrar Web Interface provides:

* EPP services
** Management of Internet Objects (domain, hosts and contacts)
** Registrar notification messages
* Financial balance checks and reporting
* Operational and statistical reporting (including DNS server activity)
* Problem and abuse reporting and tracking
* Access to registry support services
Access to the Registrar Web Interface is restricted using the same techniques used for the EPP Interface, which include Signed TLS Certificate, IP address white lists, firewalls, and authentication via login.

23.3.3. Dissemination of TLD zone files

23.3.3.1. DNS Service

No matter how good the registration system, Internet users require that domain names resolve quickly and reliably. Our DNS service provides name resolution for all domain names in our registry.

This registry was constructed on top of an already-operational worldwide publication⁄distribution system and network of name servers. These name servers employ IP-Anycast technology for scalable geographic redundancy, strong defense from Denial of Service attacks, high quality of service, and to give excellent response to widely geographically diverse clients.

DNSSEC and IPv6 are already fully integrated into this network and its component servers.

Our DNS publication system uses both scheduled and on-demand updates. When it is time to perform an update, the process starts by generating all needed certified zone files from the authoritative registry database. Candidate files are validated and checked for errors.

Our system signs each zone with DNSSEC before distribution to the global network of publication servers. Those publication servers are the advertised DNS servers for these domains.

Our DNS master servers compute the changes from the prior zone file and send secure incremental updates via our distribution system. Any lost updates are automatically healed by full-fetch refresh transactions initiated by the publication name servers themselves whenever conditions suggest, or even hint, that incremental synchronization has been lost. A full-fetch refresh can also be initiated by the Registry Operations Center.

Every published zone is stored in a version control system. This allows us to compare zone data as it changes, for recovery, capacity planning, security monitoring, and forensic reconstruction.

23.3.3.2. Zone File Access

In accordance with ICANN requirements, all gTLD registries must offer a zone file access service through which one may download copies of the TLD zone file (as snapshotted once a day.) This service is offered only to registered users. The intent is to facilitate the work of companies, researchers, and individuals who are looking for evidence of malicious conduct.

Eligible individuals and entities may apply for Zone File Access. Access credentials will be issued by the Registry. Those credentials permit controlled retrieval of the zone file images.

23.3.4. Dissemination of contact or other information concerning domain name registrations

23.3.4.1. Port 43 Whois:

Port 43 Whois implements the RFC-3912 Whois protocol specification. This is the classic Whois - it provides public exact-match searches for Internet objects held by the registry.

Our Port 43 Whois servers are geographically distributed in several locations. This improves user experience, performance, reliability, and load distribution.

To prevent abusive behavior, our Port 43 Whois servers implement configurable per-IP rate-limiting controls. In addition, queries are logged for abuse detection, statistical analysis, capacity planning, and reporting.

23.3.4.2. Tiered Access Searchable Whois:

Tiered Access Searchable Whois begins where Port 43 Whois leaves off.

Tiered Access Searchable Whois is a RESTful web service: The query is expressed as part of a URI that is sent by the user to the registry via secure HTTP (HTTPS) as part of a GET or HEAD operation. The default format for the response data is XML. Other formats (such as JSON) may be requested in the URI.

In its basic mode a Tiered Access URI contains a simple match criterion on the name, as with Port 43 Whois. In searchable mode the URI contains search criteria such as partial-match and wildcard searches on the name and use of additional registration fields (such as creation date.)

The searchable mode accommodates situations where customers or law enforcement require capabilities not provided by traditional Port 43 Whois.

Both of these modes facilitate access by user-written software tools. The basic mode interface may be made available to the public. The searchable mode is available only to contracted, identified, credentialed users for lawful public benefit purposes and subject to an agreement to use the data only in compliance with applicable privacy laws and regulations. The searchable mode is also available, in accord with registry procedures, to law enforcement.

Whois queries made to the system, whether they come from the Tiered Access Searchable Whois or the Port 43 Whois are logged for analysis, capacity planning, and abuse detection.

23.3.4.3. Whois API

Tiered Access Searchable Whois is a service for registered and authenticated users to perform wildcard searches on object registrations and retrieve them in a user-friendly way.

An Applications Programming Interface (API) also is provided, thereby enabling information systems to integrate with our RESTful whois service.

If the user of the Tiered Access Searchable Whois system is also the current registrant of a particular domain name, an additional feature is available which allows the user to view whois query reporting information based on the data collected from the monitoring service for that domain name.

Among the items made available to the registrant are:

* Number of times the registrantʹs domain name has appeared on port-43 whois results, over time, and by country;
* General and detailed information on who has been searching for them in the RESTful Whois Interface; and
* Registry system statistics associated with their domain names such as number of DNS queries
23.3.5. Internationalized Domain Names

An Internationalized Domain Name (IDN) is a name that contains at least one non-ASCII character, as permitted according to ICANN and its IDN Implementation Guidelines (http:⁄⁄www.icann.org⁄en⁄topics⁄idn⁄idn-guidelines-02sep11-en.htm), and IETF standards such as RFC 3490, RFC 3491, and RFC 3492.

23.3.5.1. IDN Registrations

The top level domain name for which we are applying is an ASCII string. We will allow registration of second level IDN names within the TLD.

Our registry policy is that when a name is registered it must be bound to a specific language tag. We have defined an EPP extension (which we have prepared as an IETF draft and will submit for approval and subsequent standardization) to convey that tag information. Our name registration procedure validates that the characters in the proposed name are consistent with the language tag. (If no tag is given the registration is treated as if the English language tag had been specified.) Our registry accepts registrations in ASCII (default), and in Cyrillic, French, Italian, German, Portuguese, and Spanish character sets.

As described in our response to Question 28, Uniregistry participates in the ISC Security Information Exchange and other mechanisms for real-time monitoring and takedown of domain names involved in malicious activity. We believe that pro-actively addressing instances of abuse is preferable to unintended consequences which may arise from constraining user options in registration of IDN domain names. Uniregistry will implement any ICANN Consensus Policy which may IDN registration policies, and it will proactively monitor abuses of IDN registrations to determine whether additional policies or protections are necessary.

23.3.5.2. IDN Whois

Our whois implementation allows UTF-8 input by default on the query command, but defaults to ASCII responses in order to provide backwards compatibility for ASCII-only clients. Domain name objects that include characters other than ASCII are shown in the A-LABEL form.

The reason for this behavior, is that port-43 Whois (RFC 3912) does not have a mechanism to signal the use of character encodings. The use of ASCII-only responses guarantees backwards client compatibility. If the response contains characters other than US-ASCII, a disclaimer note is shown referencing a URL where the complete UTF-8 encoded information is available.

The RESTful interface (in XML format by default) are pretty-formatted if rendered using a web-browser. The content is UTF-8 encoded to allow for extended character sets other than US-ASCII. The format of that XML file is detailed in our answer to question 26 (Whois Service), and will be reviewed and kept up-to-date with IETF proposed standards and best current practices.

23.3.6. DNS Security Extensions (DNSSEC)

Our registry backend operator, Internet Systems Consortium (ISC) has significant experience with DNSSEC. ISC participated in the development of the DNSSEC protocol itself within IETF, and is author of one of the earliest and most popular current free open source DNSSEC implementations available (BIND). ISC operates and manages one of the largest portfolios of DNSSEC signed zones and DNSSEC capable servers.

Registrars collect Delegation Signer (DS) information from Registrants and submit it to the Registry using the EPP service covered under RFC 5910 (DS Data Interface) (DNSSEC Mapping for EPP) or via the Registrar Web Interface.

The TLD zone with all of its resource records are signed using the best current practices for DNSSEC operations.

Hardware Security Modules (HSMs) are used to securely store both the Key Signing Keys (KSKs) and (Zone Signing Keys) ZSKs.

Except for the HSMs which will be provisioned after approval of this TLD, our DNSSEC system is fully operational and in daily use by several ccTLDs and commercial second-level DNS zones.

DNSSEC key management, protection, and signing formalities are in accord with developing norms such as those being used on the root zone itself. (See answer to question 43 for additional information)

23.3.7. Registry Operations Center (ROC)

We have centralized registry management, control, reporting, measurement, and repair functions into a facility we call the Registry Operations Center (or ROC).

There is a secure physical facility that serves as the primary home of the ROC.

Backup ROC facilities may be established on a temporary basis should the need arise.

The ROC is the primary point of contact for all registry issues. The ROC can receive input via several means - PSTN telephone, VoIP telephone, web input, e-mail, and text messages, etc. Special access methods are available to registrars and law enforcement.

The ROC assures that all incoming reports are logged, assigned identifiers, triaged, assigned to staff for resolution, and tracked. A strict reporting structure assures that all issues are handled and, if necessary, escalated and assigned additional resources.

The ROC is also a collection point for the receipt and analysis of monitoring and logging data.

The ROC is supported by geographically distributed staff members who are able to provide assistance if needed. Should there be a failure that takes the ROC offline, those remote staff members will have the tools and security credentials to take over operations until the ROC comes back online.

ISC has successfully used these methods for several years to support F-Root and other critical Internet services.

23.3.8. Abuse Mitigation and Prevention

We anticipate that our Registry (like all registries) will be the target of various kinds of abuse.

* We anticipate that our registration, whois, and name servers will be the target of frequent attacks ranging from heavy-load Distributed Denial of Service (DDoS) attacks to sophisticated penetration attempts.
* Registered names may be mis-used in ways that violate the rights of others.
To deal with direct attacks, we do this:

* Armor our networks and systems with firewalls and filters.
* Pre-deploy significant overcapacity to absorb excess load.
* Use system architectures that allow us to shed an individual device that is under attack.
* Use reasonably secure hardware and software which we will keep up-to-date as vulnerabilities are discovered.
* Monitor for attacks and penetrations so that we can initiate countermeasures.
* Have replicated data (and off-site backups), audit trails, and journals to allow recovery from data damage and to assist law enforcement.
In addition we use an Adaptive Intelligent Mitigation (AIM) strategy in which we use a real-time global system to evaluate actual DNS and Whois activity for signs of errors, trouble, abuse, or attack.

To reduce the abuse of names, our Registry Operations Center maintains active contact points for the reporting of abusive behavior. This is backed by procedures and systems to research the abuse claim, to track progress of the handling of that claim, and to take remedial actions.

Our Registry Operations Center also serves as the primary point of contact for law enforcement interactions with the registry.

To redress name-registration abuse, we:

* Implement ICANNʹs Uniform Dispute Resolution Policy (ʺUDRPʺ).
* Implement a sunrise protection and registration program that uses ICANNʹs Trademark Clearinghouse (ʺTMCHʺ).
* Implement ICANNʹs Uniform Rapid Suspension Policy (ʺURSʺ).
23.3.8.1. System Security and Stability

Our systems have been engineered using standards and best current practices in information system security.

Our systems are protected by multiple security mechanisms ranging from firewalls to multiple levels of authentication, IP address white-lists, real-time monitoring, and audit logs of transaction and system events.

We maintain several levels of non-incremental data backup. We perform realtime data replication among our master and hot stand-by nodes. The replication is designed to safeguard against hardware or software failures. To handle human errors -- for instance, erroneous deleting of records -- a comprehensive backup policy is in place.

We participate in trusted security committees and forums so that we can quickly learn of new threats and solutions.

However, new threats arise every day. No system can be totally secured against every threat. Therefore we have procedures, resources, and backups ready to detect problems at an early stage so we can prevent further harm and restore our systems back to full operational status.

23.3.8.2. Monitoring of Whois and DNS Query Streams

The registry offers a service through which network operators, law enforcement, security companies, and research organizations are able to monitor actual DNS and Whois query⁄response activity.

This service is available only under strict access controls and only to credentialed, identified users operating for the public interest under contractual constraints or to law enforcement personnel.

This service passively monitors queries sent to both the Whois and the DNS service. The monitored transactions are classified into set of channels. Subscribers to a channel can view that channelʹs DNS and Whois transaction activity.

This is far more than a simple packet monitoring service because the transactions are preserved in a searchable database for historical analysis.

In addition, this information is used to feed our analysis systems. Among other things the analysis tries to recognize malicious domain name activity. Suspicious behavior is logged and reported to the Registry Operations Center and, if warranted, to the appropriate registrar.

Overall, this system gives us a unique real-time view of our performance.

23.3.8.3. Front Desk for Abuse Reporting and Mitigation

Through our Registry Operations Center (ROC), anyone can report suspicious activity. Requests are assigned a number (ticket number) and entered into a tracking system, so that the request can be tracked as it is being handled by our team.

Requests resulting in a determination of misuse of a domain name generate a notification for the registrar so they can deal with the registrant to resolve the problem.

In case there is no response from the registrar within a reasonable period of time, a take-down policy will come into effect, where the domain name is disabled (not deleted) until matters can be settled.

23.4. GENERAL RESOURCING PLANS FOR THE REGISTRY

The management of UniRegistry and ISC is committed to providing world-class registry services, including all necessary assurances for performance and availability of those services to the community at large.

UniRegistry has secured ISCʹs support for this endeavour due to ISCʹs extensive experience operating critical infrastructure such as F-Root and ISC-SNS. These are globally DNS services which have reliably served millions of users without interruption since they were deployed.

Operations staff with this level of experience will be in charge of all aspects of UniRegistryʹs registry operations, including DNS, EPP, and WHOIS services. As additional guarantees, ISC has 50+ employees with dedicated operations, support and software engineering resources that will be available to contribute to both the initial implementation and to the ongoing operation, monitoring, and maintenance of the registry system. ISCʹs engineering and operations staffs specialize in the technologies that are required to build and operate a registry and its associated systems.

Additionally, ISC has a world-renowned cyber-security engineering team that will create and maintain a proactive approach to security. ISC is actively involved in major Internet industry security organizations like SSAC and various trusted groups. This team will assist and support the appointed UniRegistryʹs Chief Information Security Officer (CISO) and the Computer Incident Response Team (CIRT) when needed.

All resources required for the fulfilment of the obligations derived from the operation of this TLD will be fully available when registries operations begin. These resources have been enumerated through all the responses of this application and have been accounted for in the corresponding business, operations and⁄or disaster recovery plans

UniRegistry has secured geographically diverse locations to base its registry operations, complemented with a third location where operations are to be resumed in the event of a disaster. Diverse disk & tape based backup systems insure a copy of the data survives catastrophic events and remain available at surviving facilities. Those provisions will remain in place over the lifetime of the TLDʹs assignment.

Performance of service and compliance with SLAs is insured due to the over-provisioning that is built in by-design. Ongoing investment in the platform, vendor support and parts to replace failed components are further evidence of the effort that goes into supporting all operational and business functions. Vendor support in particular is an important factor: All critical components of the service platform are covered by 7x24 support contracts with response within 4 or 8 hours. This level of support is supplemented by on-hand spares, allowing the on-site staff to recover from most hardware failures on short notice.

A custom monitoring platform complemented with third party monitoring services and systematic service health checks reinforce the ability to maintain responses within the terms of the SLAs.

The highly critical DNS service is provided with a combination of the ISC-SNS service -- a worldwide, anycast-based DNS secondary service -- and dedicated unicast-based DNS servers.

A comprehensive Disaster Recovery Plan that is tested and reviewed frequently, supported through the UniRegistryʹs Security Policy, guarantees the ability to restore services to maintain aggressive availability targets, insuring services are available to the public at all times.

Failover Testing and other aspects of the disaster recovery planning are managed by a designated person dedicated to that task, our Disaster Recovery Specialist or DRS. The DRS has at his or her disposal resources from the whole organization -- including management resources -- to ensure that the testing plans are executed and its results and lessons are incorporated into the operation toward the future.

The DRS is responsible for obtaining and properly storing machine logs as well as the service monitoring reports that accompany each test depicted below. This information is preserved and considered an integral part of the Test Report, that remains available for reassessing findings or post-mortem analysis.

The Registry Operations Center (ROC) that is supported by a 24x7 call center and custom automation will receive, aggregate and respond to normal and abnormal issues arising from the operation of the registry services. This organization serves as the focal point for response coordination, threat mitigation and effective policy controls implementation.
Costs and procurement of the resources described here are detailed in response to Question 47.

23.4.1. Human Resources

Management Staff

Management provides guidance and support for the deployment and operation of the registry.

Key members of the Registry Operations Group can be viewed in EXHIBIT ʺ23-Key-Resource-Profiles.pdfʺ
gTLDFull Legal NameE-mail suffixDetail
.shoppingUniregistry, Corp.uniregistry.comView
TABLE OF CONTENTS

23.1 SUMMARY
23.2 OPERATIONS
23.2.1 Registry Operations Team
23.2.2 Registry Systems
23.3 SERVICES
23.3.1 Object Registrations
23.3.2 Receipt of Data From Registrars
23.3.3 Dissemination of TLD zone files
23.3.4 Dissemination of contact or other information concerning domain name registrations
23.3.5 Internationalized Domain Names
23.3.6 DNS Security Extensions (DNSSEC)
23.3.7 Registry Operations Center (ROC)
23.3.8 Abuse Mitigation and Prevention
23.4 GENERAL RESOURCING PLANS FOR THE REGISTRY
23.4.1 Human Resources

- - - - -

23.1. SUMMARY

Our various registry services fall into these categories:

* Services to Registrars
** Object Registration and Management (Extensible Provisioning Protocol (EPP) , Registrar Web Interface, Registrar Toolkit)
** Notification, information, and documentation
* Services to Registrants
** Internationalized Domain Name (IDN) registration
** DNSSEC
** Publication of zone file data (DNS name servers)
** Anycast management of replicated DNS servers
* Services to the public
** Classic WHOIS
** Tiered access by registered and authenticated users
* Maintenance services for the registry itself
** Generation of zone files
** DNSSEC signing of zone files
** Dissemination of zone files
** Zone file access
* Abuse Mitigation and Prevention
** Server protection strategies and mechanisms
** Abuse monitoring, recording, and analysis.
** Security and Stability Operational Practices
* Registry Operations Center (ROC)
23.2. OPERATIONS

23.2.1. Registry Operations Team

Registry operations are outsourced to and performed by Internet Systems Consortium, Inc (ISC).

Founded in 1994, ISC has been a vanguard in the growth and stability of the Internet. In addition to its better-known role as a technology leader and developer, ISC is one of the worldʹs most important organizations entrusted with management of Internetʹs essential infrastructures. From respected and prolific standards development for DNS, DNSSEC and IPv6; development and maintenance of the widely-used BIND and DHCP open source software; deployment and operation of critical global Internet services such as F-Root and SNS; to leadership in abuse prevention and mitigation strategies and tools, ISC is the worldʹs preeminent expert in the technology and operation of the Domain Name System.

ISC operates the F-root server, one of the 13 root server complexes on the internet. ISC pioneered use of the anycast routing technology that allows DNS servers to be replicated to improve performance, reliability, and resistance to attack. Today the F-root has 59 anycasted instances that are globally distributed and strategically placed at highly-connected nexus locations. F-root instances are also installed in more remote regions around the world such as in Mongolia and Fiji. This diversity was specifically pursued to increase resilience and performance for small and remote developing countries. This anycast architecture has been adopted by other root server operators and also by many gTLDs and ccTLDs, including .com, .net, and .org. Since shortly after its founding in 1994, ISC has maintained 100% up-time for F-root, and today the servers that implement F-root handle approximately 25% of the Internetʹs root traffic.

ISC provides other critical resources and services such as Secondary DNS for more than 50 ccTLD registries and non-profit organizations (including ICANN). ISC has long operated its own hosting facilities and provided hosting to key Internet open source projects such as Linux, Mozilla, FreeBSD, and the Internet Archive.

As new needs arise, ISC continues to develop and offer new services to support an open and robust Internet. One such project is the Resiliency and Security Forum, which operates the Security Information Exchange (SIE). SIE provides summary or distilled feeds of combined global DNS activities in real time to qualified recipients, which enables a pro-active defense against cybercrime. Recently ISC was a participant in a public⁄private partnership with law enforcement agencies around the world to assist with the largest takedown of a botnet in history.

ISC has one of the worldʹs largest operational deployments of DNSSEC.

ISC and its people are widely trusted around the world. Of the 21 people worldwide (known as the Trusted Community Representatives, or TCRs) who are entrusted with the DNSSEC keys to the root zone, two are ISC employees.

Under such pedigree, ISC has developed the next-generation Registry Services Platform presented in this application.

The Internet Systems Consortium is incorporated in the US state of Delaware, with employees in numerous countries around the world.

23.2.2. Registry Systems

Our systems are state-of-the-art and designed to meet the highest standards of TLD operational performance, reliability, scalability, and security. All components of the technical infrastructure for the registry have been built with 8 to 10 times the forecast capacity for our largest scenario of registration volumes. Thus, the capacity of the technical infrastructure is scaled at a level that covers the full range of projected volumes from ʺWorst Caseʺ to ʺBest Caseʺ without large or incremental capital costs for infrastructure and is easily scalable to higher volumes if required.

The registry is built as several major subsystems, each of which, in turn, is implemented as a collection of subsidiary services. This way we can use the most appropriate technologies for each subsystem and service, to obtain flexibility and scalability while retaining security, robust resilience to load and attack, and high availability.

Many of the major components of the registry system have been in use in commercial services on the Internet. The components that were developed specifically for Registry use have been carefully integrated with and tested with those existing components.

Our registry protects registration data and performance levels across all of its information services. Our system engineers have put a major emphasis on design review, high-reliability engineering methodologies, and structured testing to ensure that consistency and referential integrity is maintained even in the event of a catastrophic incident.

Every aspect of every module is designed and built to be be robust, replicated, and recoverable:

* Multiple data centers, with wide geographic diversity, that mutually support one another for backup and failover.
* Hardware uses redundant elements such as power supplies, RAID storage, and Error Correcting (ECC) memory.
* All network connectivity uses redundant interfaces, geographically differentiated pathways, and automatic fall backs.
* User facing systems are all replicated with no single point of failure and automatic failover to a backup system.
* Load balancing techniques are incorporated to prevent overload of any single user-facing component.
* Firewalls are used to prevent most malicious traffic from even reaching registry systems.
* All registrar and other non-public network service interfaces are protected by access lists, encryption, and authentication.
* Public network service interfaces are protected by rate limiters that can be activated when needed.
* Databases are built using an architecture employing master servers with hot standbys.
* The database has been configured so that rigorous quality and consistency checks are automatically enforced throughout the lifetime of the data.
* Database files can be backed up or moved without interrupting online services.
* All systems are monitored 24x7x365 by a worldwide array of hardware and performance monitors backed by the Registry Operations Center (ROC).
* The Registry Operations Center is backed by a worldwide staff that is ready to assist the operations staff or (in case of disaster) to take over its operation, all without interrupting user services.
* Every transaction is time stamped and permanently logged in journals that can be used for audits or data reconstruction.
* Data, systems, and operations are distributed so that no single event could cause an outage longer than a few seconds while transition occurs. Most systems would have no user perceived outages at all.
The use of replication as a fundamental design element means that the system can scale and adapt in response to equipment, software, or network failures.

23.3. SERVICES

23.3.1. Object Registrations

One of the principal objectives of any Internet Domain Registry is to manage the allocation, registration, and status of Internet Objects: Domain Names, Contacts, and Hosts (name servers).

From the point of view of the registry, a Domain Name comes into existence when it has been registered by an accredited Registrar, there is no requirement of zone file appearance for a domain name to be considered as registered. This is clearly stated in RFC 5731 (section 3.2.1). To be eligible to be included in the TLD zone file, at least two name servers must be associated with the registered domain name. In other words, names that are registered but which do not have at least two name servers are not published into the TLD zone file. Whois data is published for a registered name whether or not that name is included in the TLD zone file.

Contact information is managed as specified in RFC 5733. Our base requirement is that contact information be in English (US-ASCII). However, in order to allow local language communities to make full use of our registry we allow contact information in other languages and their characters sets. This provides the opportunity for fully localized contact or domain records, both of which show information in both English (US-ASCII) as well as the localized languages that might be required.

23.3.1.1. Host Registrations

Host registrations are subjected to a series of checks to prevent unauthorized creation of glue records. In the same manner, periodic audits are performed to detect and flag lame server delegations (name servers to which a domain has been delegated but which have not been configured to serve any data for that domain.)

Host registrations are verified for compliance with RFC 953 and RFC 1035 and compliance with the restrictions related to IDN that have been explained elsewhere in this document.

Periodic audits are performed on contact information to flag potentially inaccurate or incomplete information.

Registrars are notified of suspect contact data via the messaging interfaces in the EPP protocol and our Registrar Web Interface.

23.3.1.2. Blocked Name or ʺDesignated Resolver Nameʺ

ʺBlocked Namesʺ are names which a trademark owner does not want to use but wants to prevent others from using. Blocked names are offered during Sunrise, and go through the same registration path as Sunrise names. With a ʺblocked name,ʺ however, the TM owner indicates in the Sunrise application that it desires a blocked name instead of a resolving name. The WHOIS for a blocked name looks like that of a Sunrise name. The registrant of a blocked name cannot change the nameservers.

23.3.2. Receipt of Data From Registrars

Our Back-end Registry Service provides ICANN-accredited registrars with a standards-based interface to perform domain registration operations.

Registrars may use this service in two ways:

* An Extensible Provisioning Protocol (EPP) interface.
* A Registrar Web interface.
23.3.2.1. Extensible Provisioning Protocol Interface

Our platform implements the standard EPP protocol as described by RFC 5730. We also implement Internet Engineering Task Force (IETF) defined mappings for Domain Names (RFC 5731), Internet Hosts (RFC 5732), and Contacts (RFC 5733). Our EPP is carried over the TCP protocol (RFC 5734) and operates in dual stack IPv4⁄IPv6 mode.

Strong security ensures that this interface may be used only by known entities that have been accredited by both ICANN and our Registry. Use of this secure Registry Service is tightly controlled at multiple levels:

* Secure encrypted channels (TLS) using X.509 Certificate validation back to a known certificate issuing authority.
* Dual static IPv4⁄IPv6 DPI Firewalls to filter out irrelevant and suspect incoming traffic.
* Behavior and anomaly traffic monitoring using IPFIX technologies.
* IPv4⁄IPv6 source address verification (IP address whitelists).
* User authentication (user⁄password) at the application level.
In conformance with standard gTLD registry practices, the Registry Service implements the DNS security extensions for the EPP protocol (RFC 5910), allowing registrars to include secure delegation points to DNSSEC signed zones.

Similarly, the system incorporates Domain Grace Period Mapping (RFC 3915), to comply with TLD extended life cycles.

To support Internationalized Domain Names (IDN), we use a custom EPP extension to specify the language tag in which the domain name has been coded, allowing the application of IDN registration policy as mandated by the TLD manager.

Scalability and high performance are achieved through the use of multiple front-end servers, each running the EPP service. Each Front-end EPP instance is capable of querying multiple Back-end servers that, in turn, have access to a master database for read⁄write operations. In addition there are server and database replicas to support read-only operations (checks, info, etc.) and thus reduce the burden of the read-write database facility.

With EPP, registrars can verify the result of each transaction and have confidence that the operations reported as successful have indeed been processed by the registry.

We time stamp and log all EPP transactions for auditing, capacity planning, offline attack analysis, or forensic reconstruction. We retain these logs indefinitely and securely.

23.3.2.2. Registrar Web Interface

The Registrar Web Interface is designed to complement the EPP Interface, to provide Registrars with backup access to the registry in the unlikely event that its EPP clients are not functional. The Registrar Web Interface supplies a set of domain management functions of the EPP interface and also additional functionality not available within the EPP protocol itself. The Registrar Web Interface provides:

* EPP services
** Management of Internet Objects (domain, hosts and contacts)
** Registrar notification messages
* Financial balance checks and reporting
* Operational and statistical reporting (including DNS server activity)
* Problem and abuse reporting and tracking
* Access to registry support services
Access to the Registrar Web Interface is restricted using the same techniques used for the EPP Interface, which include Signed TLS Certificate, IP address white lists, firewalls, and authentication via login.

23.3.3. Dissemination of TLD zone files

23.3.3.1. DNS Service

No matter how good the registration system, Internet users require that domain names resolve quickly and reliably. Our DNS service provides name resolution for all domain names in our registry.

This registry was constructed on top of an already-operational worldwide publication⁄distribution system and network of name servers. These name servers employ IP-Anycast technology for scalable geographic redundancy, strong defense from Denial of Service attacks, high quality of service, and to give excellent response to widely geographically diverse clients.

DNSSEC and IPv6 are already fully integrated into this network and its component servers.

Our DNS publication system uses both scheduled and on-demand updates. When it is time to perform an update, the process starts by generating all needed certified zone files from the authoritative registry database. Candidate files are validated and checked for errors.

Our system signs each zone with DNSSEC before distribution to the global network of publication servers. Those publication servers are the advertised DNS servers for these domains.

Our DNS master servers compute the changes from the prior zone file and send secure incremental updates via our distribution system. Any lost updates are automatically healed by full-fetch refresh transactions initiated by the publication name servers themselves whenever conditions suggest, or even hint, that incremental synchronization has been lost. A full-fetch refresh can also be initiated by the Registry Operations Center.

Every published zone is stored in a version control system. This allows us to compare zone data as it changes, for recovery, capacity planning, security monitoring, and forensic reconstruction.

23.3.3.2. Zone File Access

In accordance with ICANN requirements, all gTLD registries must offer a zone file access service through which one may download copies of the TLD zone file (as snapshotted once a day.) This service is offered only to registered users. The intent is to facilitate the work of companies, researchers, and individuals who are looking for evidence of malicious conduct.

Eligible individuals and entities may apply for Zone File Access. Access credentials will be issued by the Registry. Those credentials permit controlled retrieval of the zone file images.

23.3.4. Dissemination of contact or other information concerning domain name registrations

23.3.4.1. Port 43 Whois:

Port 43 Whois implements the RFC-3912 Whois protocol specification. This is the classic Whois - it provides public exact-match searches for Internet objects held by the registry.

Our Port 43 Whois servers are geographically distributed in several locations. This improves user experience, performance, reliability, and load distribution.

To prevent abusive behavior, our Port 43 Whois servers implement configurable per-IP rate-limiting controls. In addition, queries are logged for abuse detection, statistical analysis, capacity planning, and reporting.

23.3.4.2. Tiered Access Searchable Whois:

Tiered Access Searchable Whois begins where Port 43 Whois leaves off.

Tiered Access Searchable Whois is a RESTful web service: The query is expressed as part of a URI that is sent by the user to the registry via secure HTTP (HTTPS) as part of a GET or HEAD operation. The default format for the response data is XML. Other formats (such as JSON) may be requested in the URI.

In its basic mode a Tiered Access URI contains a simple match criterion on the name, as with Port 43 Whois. In searchable mode the URI contains search criteria such as partial-match and wildcard searches on the name and use of additional registration fields (such as creation date.)

The searchable mode accommodates situations where customers or law enforcement require capabilities not provided by traditional Port 43 Whois.

Both of these modes facilitate access by user-written software tools. The basic mode interface may be made available to the public. The searchable mode is available only to contracted, identified, credentialed users for lawful public benefit purposes and subject to an agreement to use the data only in compliance with applicable privacy laws and regulations. The searchable mode is also available, in accord with registry procedures, to law enforcement.

Whois queries made to the system, whether they come from the Tiered Access Searchable Whois or the Port 43 Whois are logged for analysis, capacity planning, and abuse detection.

23.3.4.3. Whois API

Tiered Access Searchable Whois is a service for registered and authenticated users to perform wildcard searches on object registrations and retrieve them in a user-friendly way.

An Applications Programming Interface (API) also is provided, thereby enabling information systems to integrate with our RESTful whois service.

If the user of the Tiered Access Searchable Whois system is also the current registrant of a particular domain name, an additional feature is available which allows the user to view whois query reporting information based on the data collected from the monitoring service for that domain name.

Among the items made available to the registrant are:

* Number of times the registrantʹs domain name has appeared on port-43 whois results, over time, and by country;
* General and detailed information on who has been searching for them in the RESTful Whois Interface; and
* Registry system statistics associated with their domain names such as number of DNS queries
23.3.5. Internationalized Domain Names

An Internationalized Domain Name (IDN) is a name that contains at least one non-ASCII character, as permitted according to ICANN and its IDN Implementation Guidelines (http:⁄⁄www.icann.org⁄en⁄topics⁄idn⁄idn-guidelines-02sep11-en.htm), and IETF standards such as RFC 3490, RFC 3491, and RFC 3492.

23.3.5.1. IDN Registrations

The top level domain name for which we are applying is an ASCII string. We will allow registration of second level IDN names within the TLD.

Our registry policy is that when a name is registered it must be bound to a specific language tag. We have defined an EPP extension (which we have prepared as an IETF draft and will submit for approval and subsequent standardization) to convey that tag information. Our name registration procedure validates that the characters in the proposed name are consistent with the language tag. (If no tag is given the registration is treated as if the English language tag had been specified.) Our registry accepts registrations in ASCII (default), and in Cyrillic, French, Italian, German, Portuguese, and Spanish character sets.

As described in our response to Question 28, Uniregistry participates in the ISC Security Information Exchange and other mechanisms for real-time monitoring and takedown of domain names involved in malicious activity. We believe that pro-actively addressing instances of abuse is preferable to unintended consequences which may arise from constraining user options in registration of IDN domain names. Uniregistry will implement any ICANN Consensus Policy which may IDN registration policies, and it will proactively monitor abuses of IDN registrations to determine whether additional policies or protections are necessary.

23.3.5.2. IDN Whois

Our whois implementation allows UTF-8 input by default on the query command, but defaults to ASCII responses in order to provide backwards compatibility for ASCII-only clients. Domain name objects that include characters other than ASCII are shown in the A-LABEL form.

The reason for this behavior, is that port-43 Whois (RFC 3912) does not have a mechanism to signal the use of character encodings. The use of ASCII-only responses guarantees backwards client compatibility. If the response contains characters other than US-ASCII, a disclaimer note is shown referencing a URL where the complete UTF-8 encoded information is available.

The RESTful interface (in XML format by default) are pretty-formatted if rendered using a web-browser. The content is UTF-8 encoded to allow for extended character sets other than US-ASCII. The format of that XML file is detailed in our answer to question 26 (Whois Service), and will be reviewed and kept up-to-date with IETF proposed standards and best current practices.

23.3.6. DNS Security Extensions (DNSSEC)

Our registry backend operator, Internet Systems Consortium (ISC) has significant experience with DNSSEC. ISC participated in the development of the DNSSEC protocol itself within IETF, and is author of one of the earliest and most popular current free open source DNSSEC implementations available (BIND). ISC operates and manages one of the largest portfolios of DNSSEC signed zones and DNSSEC capable servers.

Registrars collect Delegation Signer (DS) information from Registrants and submit it to the Registry using the EPP service covered under RFC 5910 (DS Data Interface) (DNSSEC Mapping for EPP) or via the Registrar Web Interface.

The TLD zone with all of its resource records are signed using the best current practices for DNSSEC operations.

Hardware Security Modules (HSMs) are used to securely store both the Key Signing Keys (KSKs) and (Zone Signing Keys) ZSKs.

Except for the HSMs which will be provisioned after approval of this TLD, our DNSSEC system is fully operational and in daily use by several ccTLDs and commercial second-level DNS zones.

DNSSEC key management, protection, and signing formalities are in accord with developing norms such as those being used on the root zone itself. (See answer to question 43 for additional information)

23.3.7. Registry Operations Center (ROC)

We have centralized registry management, control, reporting, measurement, and repair functions into a facility we call the Registry Operations Center (or ROC).

There is a secure physical facility that serves as the primary home of the ROC.

Backup ROC facilities may be established on a temporary basis should the need arise.

The ROC is the primary point of contact for all registry issues. The ROC can receive input via several means - PSTN telephone, VoIP telephone, web input, e-mail, and text messages, etc. Special access methods are available to registrars and law enforcement.

The ROC assures that all incoming reports are logged, assigned identifiers, triaged, assigned to staff for resolution, and tracked. A strict reporting structure assures that all issues are handled and, if necessary, escalated and assigned additional resources.

The ROC is also a collection point for the receipt and analysis of monitoring and logging data.

The ROC is supported by geographically distributed staff members who are able to provide assistance if needed. Should there be a failure that takes the ROC offline, those remote staff members will have the tools and security credentials to take over operations until the ROC comes back online.

ISC has successfully used these methods for several years to support F-Root and other critical Internet services.

23.3.8. Abuse Mitigation and Prevention

We anticipate that our Registry (like all registries) will be the target of various kinds of abuse.

* We anticipate that our registration, whois, and name servers will be the target of frequent attacks ranging from heavy-load Distributed Denial of Service (DDoS) attacks to sophisticated penetration attempts.
* Registered names may be mis-used in ways that violate the rights of others.
To deal with direct attacks, we do this:

* Armor our networks and systems with firewalls and filters.
* Pre-deploy significant overcapacity to absorb excess load.
* Use system architectures that allow us to shed an individual device that is under attack.
* Use reasonably secure hardware and software which we will keep up-to-date as vulnerabilities are discovered.
* Monitor for attacks and penetrations so that we can initiate countermeasures.
* Have replicated data (and off-site backups), audit trails, and journals to allow recovery from data damage and to assist law enforcement.
In addition we use an Adaptive Intelligent Mitigation (AIM) strategy in which we use a real-time global system to evaluate actual DNS and Whois activity for signs of errors, trouble, abuse, or attack.

To reduce the abuse of names, our Registry Operations Center maintains active contact points for the reporting of abusive behavior. This is backed by procedures and systems to research the abuse claim, to track progress of the handling of that claim, and to take remedial actions.

Our Registry Operations Center also serves as the primary point of contact for law enforcement interactions with the registry.

To redress name-registration abuse, we:

* Implement ICANNʹs Uniform Dispute Resolution Policy (ʺUDRPʺ).
* Implement a sunrise protection and registration program that uses ICANNʹs Trademark Clearinghouse (ʺTMCHʺ).
* Implement ICANNʹs Uniform Rapid Suspension Policy (ʺURSʺ).
23.3.8.1. System Security and Stability

Our systems have been engineered using standards and best current practices in information system security.

Our systems are protected by multiple security mechanisms ranging from firewalls to multiple levels of authentication, IP address white-lists, real-time monitoring, and audit logs of transaction and system events.

We maintain several levels of non-incremental data backup. We perform realtime data replication among our master and hot stand-by nodes. The replication is designed to safeguard against hardware or software failures. To handle human errors -- for instance, erroneous deleting of records -- a comprehensive backup policy is in place.

We participate in trusted security committees and forums so that we can quickly learn of new threats and solutions.

However, new threats arise every day. No system can be totally secured against every threat. Therefore we have procedures, resources, and backups ready to detect problems at an early stage so we can prevent further harm and restore our systems back to full operational status.

23.3.8.2. Monitoring of Whois and DNS Query Streams

The registry offers a service through which network operators, law enforcement, security companies, and research organizations are able to monitor actual DNS and Whois query⁄response activity.

This service is available only under strict access controls and only to credentialed, identified users operating for the public interest under contractual constraints or to law enforcement personnel.

This service passively monitors queries sent to both the Whois and the DNS service. The monitored transactions are classified into set of channels. Subscribers to a channel can view that channelʹs DNS and Whois transaction activity.

This is far more than a simple packet monitoring service because the transactions are preserved in a searchable database for historical analysis.

In addition, this information is used to feed our analysis systems. Among other things the analysis tries to recognize malicious domain name activity. Suspicious behavior is logged and reported to the Registry Operations Center and, if warranted, to the appropriate registrar.

Overall, this system gives us a unique real-time view of our performance.

23.3.8.3. Front Desk for Abuse Reporting and Mitigation

Through our Registry Operations Center (ROC), anyone can report suspicious activity. Requests are assigned a number (ticket number) and entered into a tracking system, so that the request can be tracked as it is being handled by our team.

Requests resulting in a determination of misuse of a domain name generate a notification for the registrar so they can deal with the registrant to resolve the problem.

In case there is no response from the registrar within a reasonable period of time, a take-down policy will come into effect, where the domain name is disabled (not deleted) until matters can be settled.

23.4. GENERAL RESOURCING PLANS FOR THE REGISTRY

The management of UniRegistry and ISC is committed to providing world-class registry services, including all necessary assurances for performance and availability of those services to the community at large.

UniRegistry has secured ISCʹs support for this endeavour due to ISCʹs extensive experience operating critical infrastructure such as F-Root and ISC-SNS. These are globally DNS services which have reliably served millions of users without interruption since they were deployed.

Operations staff with this level of experience will be in charge of all aspects of UniRegistryʹs registry operations, including DNS, EPP, and WHOIS services. As additional guarantees, ISC has 50+ employees with dedicated operations, support and software engineering resources that will be available to contribute to both the initial implementation and to the ongoing operation, monitoring, and maintenance of the registry system. ISCʹs engineering and operations staffs specialize in the technologies that are required to build and operate a registry and its associated systems.

Additionally, ISC has a world-renowned cyber-security engineering team that will create and maintain a proactive approach to security. ISC is actively involved in major Internet industry security organizations like SSAC and various trusted groups. This team will assist and support the appointed UniRegistryʹs Chief Information Security Officer (CISO) and the Computer Incident Response Team (CIRT) when needed.

All resources required for the fulfilment of the obligations derived from the operation of this TLD will be fully available when registries operations begin. These resources have been enumerated through all the responses of this application and have been accounted for in the corresponding business, operations and⁄or disaster recovery plans

UniRegistry has secured geographically diverse locations to base its registry operations, complemented with a third location where operations are to be resumed in the event of a disaster. Diverse disk & tape based backup systems insure a copy of the data survives catastrophic events and remain available at surviving facilities. Those provisions will remain in place over the lifetime of the TLDʹs assignment.

Performance of service and compliance with SLAs is insured due to the over-provisioning that is built in by-design. Ongoing investment in the platform, vendor support and parts to replace failed components are further evidence of the effort that goes into supporting all operational and business functions. Vendor support in particular is an important factor: All critical components of the service platform are covered by 7x24 support contracts with response within 4 or 8 hours. This level of support is supplemented by on-hand spares, allowing the on-site staff to recover from most hardware failures on short notice.

A custom monitoring platform complemented with third party monitoring services and systematic service health checks reinforce the ability to maintain responses within the terms of the SLAs.

The highly critical DNS service is provided with a combination of the ISC-SNS service -- a worldwide, anycast-based DNS secondary service -- and dedicated unicast-based DNS servers.

A comprehensive Disaster Recovery Plan that is tested and reviewed frequently, supported through the UniRegistryʹs Security Policy, guarantees the ability to restore services to maintain aggressive availability targets, insuring services are available to the public at all times.

Failover Testing and other aspects of the disaster recovery planning are managed by a designated person dedicated to that task, our Disaster Recovery Specialist or DRS. The DRS has at his or her disposal resources from the whole organization -- including management resources -- to ensure that the testing plans are executed and its results and lessons are incorporated into the operation toward the future.

The DRS is responsible for obtaining and properly storing machine logs as well as the service monitoring reports that accompany each test depicted below. This information is preserved and considered an integral part of the Test Report, that remains available for reassessing findings or post-mortem analysis.

The Registry Operations Center (ROC) that is supported by a 24x7 call center and custom automation will receive, aggregate and respond to normal and abnormal issues arising from the operation of the registry services. This organization serves as the focal point for response coordination, threat mitigation and effective policy controls implementation.
Costs and procurement of the resources described here are detailed in response to Question 47.

23.4.1. Human Resources

Management Staff

Management provides guidance and support for the deployment and operation of the registry.

Key members of the Registry Operations Group can be viewed in EXHIBIT ʺ23-Key-Resource-Profiles.pdfʺ