C17.5. Zone file distribution and publication. Locations of nameservers, procedures for and means of distributing zone files to them. If you propose to employ the VeriSign global resolution and distribution facilities described in subsection 5.1.5 of the current .org registry agreement, please provide details of this aspect of your proposal.

During the period defined in the nameserver transition plan outlined in Section 18 of this document, name resolution service will be provided by VeriSign to begin with, then jointly by VeriSign and Nominum (our preferred DNS operator) and then solely by Nominum at the completion of the Name Server transition.

During this time the process for updating the .org zone file remains unchanged, Unity Registry will still update the .org zone on our “Stealth” master which will push out the changes to either the VeriSign’s master secondary or the Nominum master secondary, or both, using standard DNS protocol IXFR from our BIND 9 Name Server.

From here on the distribution of the zone file to the “live” secondaries will be via the custom Name Server software operated by our DNS contractor, initially VeriSign and later Nominum. It is our understanding that this software is completely conformant to the DNS RFCs (RFC 1035 and others).

GNS - NOMINUM

Introduction

The global name service described in this overview is currently deployed by a number of TLDs and has processed over a billion DNS packets since going into production in 1999.  It is developed and supplied under contract to Unity Registry by Nominum (see Section C13).

Based in Silicon Valley, Nominum is the world leader in the development and support of Internet naming and address management software and services. The authoritative name server that is the engine for our Global Name Service (GNS) was written from scratch by the same team that wrote the latest version of BIND, version 9, under contract to the Defense Information Systems Agency of the U.S. Department of Defense and for distribution by the Internet Software Consortium, www.isc.org. The GNS name server code does not share any code with BIND and offers many improvements in performance specific to large scale registry hosting. In addition to BIND version 9, Nominum has provided reference implementations of other naming and address management software, notably ISC DHCP version 3, to the Internet Software Consortium. While Nominum continues to develop and support Open Source implementations of naming and address management software, the company has recently adopted a new commercial focus on more efficient and higher performing standards-based proprietary solutions.

Nominum’s executives and engineers are some of the most knowledgeable people in the world about Internet naming and address management. Paul Mockapetris, the inventor of DNS and author of the original DNS RFCs 1034 and 1035, is Nominum’s Chairman of the Board and Chief Scientist. Dr. Ted Hardie, a Nominum executive, is a member of the Internet Advisory Board (IAB). David Conrad, Nominum’s Chief Technical Officer, is a member of ARIN, of ICANN’s recently formed Security Committee, and was the founder of APNIC. Many of Nominum’s executives and engineers are regular contributors to the IETF.

Nominum's experience includes operational support for two of the root name servers, E and F; critical primary or secondary DNS support for gTLDs, including 3 of the 7 new ICANN-approved top level domains (.info, .coop, and .aero), and ccTLDs including the country codes for Ireland (.ie), Norway (.no), and Luxembourg (.lu); and a broad range of DNS support to various enterprises around the world.  Consequently, Nominum staff has a unique combination of skills: deep technical knowledge of the details of the DNS system and an appreciation for operational requirements.

DNS Challenges

Comprehensive DNS management is complex. Although the DNS process may seem basic, it takes a lot of administration to keep it running properly.

Managing a TLD and its authoritative name servers requires time, money and an administrator with substantial training and experience.  The syntax of DNS database and name server configuration files is subtle and unforgiving.  To ensure robustness, name servers should be connected to the Internet via different subnetworks. As an example of the risk from not diversifying the name server subnet, last year, in a highly publicized failure, a very well-known software maker was inaccessible to its customers for 48 hours because all of their DNS servers were behind a single subnet.

To provide optimal performance, name servers should be widely distributed both geographically and architecturally. The cost of placing and operating servers in multiple strategic locations, however, is prohibitive to most organizations. The result is that administrators often limit the number and distribution of their name servers, which makes them vulnerable to catastrophic failures when DNS or network problems arise.

The GNS Solution

GNS is based on a multi-site, multi-server, multi-network infrastructure that is designed to offer the Internet the most fault-tolerant, responsive and user-friendly DNS possible.  Managed by experienced operators who are actively involved with DNS protocol developments and are aligned with the registry operator’s goals through a service level agreement, GNS provides a professional approach to meeting TLD secondary requirements. The key benefits of GNS include performance, control, and security.

q         Performance– The authoritative name server in GNS can process over 30,000 queries per second and is faster than BIND9. Name service is guaranteed to be 100% available on a monthly basis.

q         Control– The TLD administrator retains the ability to directly update their DNS data.  No complicated handoffs, uncomfortable compromises or middlemen are required to take advantage of the GNS architecture.

q         Security– The GNS system is designed with security as a priority. Multiple methods are used to protect data, ensure servers remain operational, and circumvent malicious access attempts.

Updating the .org Zone

Nominum will rely on the TLD operator to run a primary that conforms to Open Standards. Using incremental zone transfers updates to the GNS secondary network the TLD operator can send batch updates every 120 minutes.

The gTLD Registry Constituency estimates there were 562 million write transactions to the com, net and org name servers in April of 2002, (Table 6 – Total Monthly Domain Name Transaction Trend by Category (In millions), http://www.gtldregistries.org/reports/2002/apr/table6.html). Write transactions are defined as follows:

“Write – This category includes the following transactions: adding a new domain, deleting a domain, modifying a domain name record, deleting a domain, renewing a domain, transferring a domain, adding a server, deleting a server and modifying a server record.”

Assuming that .org accounts for 8% of the com, net and org transaction totals then the .org zone receives approximately 44, 960,000 name server transactions per month (using a 30 day month) or 17 transactions per second. Using a two hour batch update period the GNS name servers will process approximately 125,000 transactions with every update.

System Capacity

Various VeriSign company literature and news reports place the daily query load for com, net and org at around six billion queries.  Spread over 13 VeriSign TLD sites, the VeriSign TLD query load works out to roughly 5,350 queries per second per site.

If org is 8% of com, then the number of org queries per second per site is estimated  at around 430, with an aggregate total for 13 sites of approximately 5,550 queries per second.

Based on our current capacity (which can easily be scaled upward) and operation experience serving several TLDs, Nominum can  easily handle the number of queries .org currently generates and continue to maintain 35% capacity headroom. Benchmark test show Nominum’s proprietary authoritative name server, which is the same name server that powers GNS sites, can handle in excess of 30,000 queries per second.

GNS Architecture

The GNS architecture is designed with the goals of robustness, reliability and efficiency.  The following descriptions show how each component of the GNS system attains these goals.

Global Infrastructure and Connectivity

The majority of the GNS servers are located at network exchange sites within the United States, Europe and Asia, (See table 1, “GNS List of Locations” below). There are several advantages in choosing such sites.  Primarily, exchange sites offer excellent transit and peering opportunities.  They are nearer to the Internet backbone infrastructure, so delays caused by traffic travelling through several hops are minimized.  The superior selection of transit providers and potential peering partners at exchange sites makes the goal of redundant network connections a reality. In addition, Nominum only chooses facilities with a 24x7 operations staff who are able to provide a “remote hands” service for  routine on-site technical support. Sites must also have a service to escort visiting personnel, which makes it simple for vendor maintenance personnel to gain access to equipment if necessary and makes it difficult for unauthorized personnel to gain physical access to the servers at all.  All sites have industry standard power and air conditioning facilities.

Table 1: GNS Site Locations

Redundancy and Efficiency

Nominum has designed each individual GNS site to be redundant and reliable. Each site has at least two servers, each on a different hardware platform and running a different operating system.  This diversity ensures that if a vulnerability in one OS or one platform is discovered and exploited, that problem will not cause the entire GNS site to go down.

In addition, the GNS sites themselves are redundant to each other. If one entire GNS site fails, the other sites around the world would continue to serve TLD data without interruption.  This failover system is made possible by the advanced routing method Nominum is using.

Another key component of the GNS infrastructure are two systems that are used to transfer zone data from the GNS database and from the registry’s primary servers to the public GNS name server hosts.  The GNS servers receive their data from the transfer systems, which push information out as often as necessary without adding unduly to the load of the registry’s’ primary servers.  The system has been optimised so that only updated data is copied. When the GNS customer sends a notify, it takes only 5 to 10 minutes for the GNS system to initialize a transfer from the registry’s primary server.

Name server Software

The GNS name servers run proprietary DNS server software written by the engineers at Nominum. These servers have been optimized for specific functions within the GNS system, and have significantly better performance traits than general purpose DNS software.  Server configurations can be rebuilt quickly if necessary as the information is stored via a source control system to ensure a server outage won’t necessitate starting a reconfiguration from scratch.  In addition, Nominum keeps a store of pre-configured “hot spare” machines ready to be quickly deployed should the need arise.

Nominum’s name servers are in full conformance with RFCs 1035 and 2181, and are fully capable of supporting dynamic updates to primaries as defined in RFC 2136 and Transaction Signatures as defined in RFC 2845. 

Advanced Routing

Nominum takes advantage of a dual-mesh anycast routing design for the GNS.  This means that each of the servers at any one GNS site responds to an IP address in a specific subnetwork, while the other server responds to an address on another subnet.  Each of these networks is announced via the anycast routing architecture, which enables machines at disparate physical locations to appear to the Internet to be on the same network.  Therefore, if one individual machine goes down for some reason, the network automatically provides the options of a machine on the other subnet and another machine on the same subnet as the one that is down.  Thus, DNS queries will always be responded to from one or the other of the routing meshes. Queries will be directed to the server closest topologically and/or to the server with the lowest calculated Round Trip Time (RTT).  This technique allows GNS to provide better response speed than systems with traditional network configurations.  Although not explicitly shown in the GNS architecture diagram above, this routing system obviously means that the routing architecture is also redundant at each GNS site and that each router has a backup. Additional detail on anycast routing can be found in the IETF draft located http://search.ietf.org/Internet-drafts/draft-ietf-dnsop-hardie-shared-root-server-07.txtThe draft author is Dr. Ted Hardie, Nominum’s Emerging Technologies Executive.

Monitoring and Scalability

All components of the GNS system are designed to be upgraded easily when capacity requirements increase.  Additional transit can be ordered when bandwidth needs increase.  Additional servers can be located at the GNS sites when the data in the system requires more resources. 

Nominum has continuous console access to its equipment by means of multiple redundant paths.  Access is available via the Internet and via a private virtual network. Nominum continually monitors all aspects of the system in order to catch and proactively correct any network or system issues.  This monitoring also allows Nominum to best evaluate when to add capacity to some part of the GNS system in order to ensure that DNS service remains efficient.  Portions of the system can be upgraded without the service itself going offline. 

Access to Nominum servers is restricted via multiple levels of firewalls. The routers filter incoming traffic, and the hosts have individual firewalls. The Nominum network equipment has filters applied to restrict access to authorized Nominum personnel, all of whom are required to log in via Secure Shell (SSH). 

Service Level

Nominum is prepared to meet ICANN performance standards for DNS availability and zone updates.

GNS Feature Summary

The following table summarizes the feature set for GNS TLD Secondary service. Some of the features are described in more detail in the following paragraphs.

Table 2: GNS Secondary Features

Easy Graphical Interface

GNS offers a clear graphical interface is to TLD administrators via the world wide web.  The interface provides system status messages and query statistics as well an easy method to view and update zone information.

100% Uptime - Security and Reliability

GNS is designed to serve domain data reliably and securely.  The system is built redundantly, allowing Nominum to provide 100% name service uptime for our customers.  Users may choose to use TSIG (Transaction Signatures) in order to sign their data transaction so that the system can confirm the data is coming from the correct source.  Should customers sign their zone data using DNSSEC, GNS has the capacity to store and serve records in that format as well.

On Demand Domain Reloading

GNS transfers zone data from customer primary servers via a full zone transfer (AXFR) or incremental zone transfers (IXFR). Additionally, GNS recommends and supports the use of transaction signatures (TSIG) as defined in RFC 2845 for the transfer of zone data to its secondary service.

DNS Security (DNSSEC) Support

Cryptographic authentication of DNS information is possible through the DNS Security (DNSSEC) extensions, which are defined in RFC 2535. GNS is fully capable of supporting and serving DNSSEC records.

IPv6 Support

GNS supports all currently defined forms of IPv6 records.

International Domain Name Support

One of the priorities of today’s Internet community is the extension of the DNS to support internationalized access to domain names. The use of non-ASCII characters in the DNS has not yet been standardized. Nominum is actively following the developments in the standards area for extended character set support in DNS, and will update the server software used by GNS to reflect standards as they are established.

To address the immediate need to use these characters within DNS, the GNS system can handle raw data in a variety of character sets, such as SJIS, Big5, EUC-JP, JIS, and so on. Before being passed to the name server, this raw data is converted to UTF-8 and prepared as described in draft-ietf-idn-nameprep-00.txt, Preparation of Internationalized Host Names.  (Please note: Internet Drafts are Internet Engineering Task Force works-in-progress.) This preparation includes the removal of characters that current name server software won’t process, changing characters that have case properties to be lowercase, and canonicalizing (normalizing) the characters. The resulting data is then converted to ASCII-compatible encode output and compiled into the zone data format used by Nominum’s name server software.

This strategy is an essential requirement for accommodating “international” names, but it should be noted that applications and infrastructure must support these names as well as client-side DNS software.  Such “international” names alone will not enable other Internet applications, such as email or web browsers, to use host names in the new format.