National Academies Press: OpenBook

Signposts in Cyberspace: The Domain Name System and Internet Navigation (2005)

Chapter: 4 The Domain Name System: Technology Prospects

« Previous: 3 The Domain Name System: Current State
Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×

4
The Domain Name System: Technology Prospects

The Domain Name System, as described in Chapter 3, has metmost of the infrastructural naming needs of the Internet and the applications that rely on it, even as their uses and usage have expanded rapidly. However, the broadening and deepening penetration of the Internet and its applications into global communications, commerce, and culture poses new challenges to the basic technology of the DNS. In anticipation of and in response to those challenges, the technology community has been developing modifications of and extensions to the current technology.

This chapter is a review of the challenges and the prospective or actual technology responses to them. Each challenge and responsive technology is described and evaluated and the implications for the Internet and its applications are explained. Where the committee is in agreement, its conclusions and recommendations are presented. In all cases, the goal is to provide a clear description of the challenges, the technologies, and their prospects in order to inform forthcoming policy deliberations affecting or affected them.

The following challenges and responsive technologies are addressed in this chapter:

  1. Improving the security of the DNS,

  2. Linking the telephone and Internet naming systems,

  3. Internationalizing domain names, and

  4. Responding to domain name errors.

Some of these technologies are in or ready for the first stages of implementation, whereas others may never enter into wide-scale usage. Never-

Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×

theless, a basic understanding of each of them will enable wiser decisions about them and other innovations in the future.

4.1 IMPROVING THE SECURITY OF THE DOMAIN NAME SYSTEM

Because of its central role in the operation of the Internet, the DNS is a natural target for mischievous and malicious attacks. These can take a wide variety of forms depending on the ingenuity of the attacker and on which of the potential vulnerabilities is attacked.1 The most severe recent attack was the denial-of-service attack launched in October 2002. It swamped 8 of the 13 root name servers for up to an hour and a half. However, the remaining 5 servers handled the regular requests to the root without difficulty. Since that attack, the root name server operators have taken a number of steps, including the widespread distribution of “anycast” satellites and diversification of network connectivity (see Box 3.1), to reduce their vulnerability to such attacks and to mitigate their effects.

Furthermore, although some steps have been taken,2 more could be done to continuously monitor the performance and traffic flows of the DNS infrastructure so as to enable rapid detection and response to attacks or outages.

However, another serious vulnerability remains. As described in Section 2.4, “the original DNS design did not include a mechanism to ensure that a name lookup was an accurate representation of the information provided by the entity responsible for the information. DNS information was assumed to be accurate as the result of general notions of network cooperation and interoperation (i.e., based on the presumption that nobody would deliberately attempt to tamper with DNS information).” In more technical terms, the initial design of the DNS did not incorporate data origin authentication and data integrity protection. However, because of increased fear of additional attacks on the DNS, these kinds of security features have now become a major concern.

Data origin authentication is needed to help ensure that the results of DNS lookups come from authoritative sources. A widely publicized case that involved the diversion of Internet users to an undesired Web site drew attention to the lack of such authentication in the DNS.3

1  

See Derek Atkins and Rob Austein, “Threat Analysis of the Domain Name System,” RFC 3833, August 2004, available at <http://www.rfc-editor.org>.

2  

Notably the establishment of the Operations Analysis and Research Center by the Internet Systems Consortium (see https://oarc.isc.org/) and the online performance monitoring by the k-root (see <http://k.root-servers.org/#stats>).

3  

In 1997, Eugene Kashpureff diverted Internet users who were seeking the Network Solutions Web site to his own site, although this was intended as a publicity stunt rather than as a malicious attack. See Rik Farrow, “Locking Up DNS Troubles,” Network Magazine, August 5, 2000, available at <http://www.networkmagazine.com/showArticle.jhtml?articleID=8702868>.

Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×

Data integrity protection is needed because DNS data flows could be compromised at any point between the various name servers, resolvers, or other intermediaries, and the corrupted data can remain in caches for extended periods of time.

To respond to these potential vulnerabilities, the technical community has over a number of years developed DNS Security Extensions (DNSSEC).4 DNSSEC adds data origin authentication and data integrity protection to the DNS. It aims to ensure that the recipient can validate that the data was sent from an authoritative source and that it arrived at its destination unchanged.

4.1.1 Mechanics of DNSSEC

DNSSEC provides end-to-end protection through the use of cryptographic digital signatures that are created by responding zone administrators and verified by a recipient’s resolver software. In particular, DNSSEC avoids the need to trust intermediate name servers and resolvers that cache or route the DNS records originating from the responding zone administrator before they reach the source of the query. DNSSEC also preserves the capacity for localized variations and independence within the DNS hierarchy.5

In DNSSEC, resource record sets (RRSets) 6 within a zone are signed based on the model of public-key cryptography.7 To support each signing operation, two keys are generated: a private key (to sign data) and the corresponding public key that is used to verify that the data were signed by the private key. The process of signing takes data to be signed and a private key as inputs to produce digitally signed data as the output.8 However, DNSSEC involves signing the hash value of an RRSet, rather

4  

Defined in Roy Arends, Rob Austein, Matt Larson, Dan Massey, and Scott Rose, “DNS Security Introduction and Requirement,” RFC 4033, March 2005, available at <http://www.rfc-editor.org>.

5  

For example, the control of the private and public keys remains within each respective zone.

6  

Resource records that have the same label, class, and type are categorized as belonging to the same RRSet. See Box 3.2 for a detailed explanation of resource records.

7  

For a review of public key cryptography and digital signatures, see Paul Albitz and Cricket Liu, DNS and BIND, 4th edition, Chapter 11, O’Reilly Media, Sebastopol, Calif., 2001; and Fred B. Schneider, editor, Computer Science and Telecommunications Board, National Research Council, Trust in Cyberspace, Chapter 4, National Academy Press, Washington, D.C., 1999.

8  

The crucial property of the digital signature is that it could have been produced only by someone with access to the private key.

Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×

FIGURE 4.1 Use of DNSSEC to authenticate a resource record set (RRSet).

than signing the full RRSet itself.9 (See Figure 4.1 for an illustration of the DNSSEC signing and verification process.)

Two copies of the RRSet are sent over the Internet to the recipient. One copy is not signed; the other is hashed and then signed as described above. To verify the origin and integrity of the unsigned RRSet, it is hashed using the same algorithm used by the sender. It is then compared with the verified, but still hashed, copy of the RRSet created by the zone

9  

A hash algorithm is a mathematical process that converts a message to a probabilistically-unique fixed-length string of digits that represents the original message. A hash algorithm is essentially unidirectional: given a hash value, it is nearly impossible to reverse the process to derive the original message in order to construct a second message whose hash value matches that of the original message. Since a hash value is typically much less data than contained in an RRSet, it is generally more efficient to sign hash values rather than RRSets.

Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×

administrator. Matching hash values provide a high level of assurance that the non-signed RRSet is authoritative and that it has not been altered in transit.

DNSSEC can, when everything works correctly, give the data consumer (validating resolver) some confidence that the received data is what the data producer (signing zone administrator) has sent. It provides a basis for trusting that the data has been received without tampering. It does not, however, assure that the data that the data producer sent is error-free or appropriate for the data consumer’s application.

The DNSSEC extensions are based on four new resource record types: the public key (DNSKEY), the resource record digital signature (RRSIG), the delegation signer (DS), and the authenticated denial of existence (NSEC).10 The public key used to verify the digital signature of an RRSet is stored in the DNSKEY resource record.11 The digital signature is stored in the RRSIG resource record, and several RRSIG resource records may be associated with an RRSet, if more than one cryptographic algorithm is used for signing the RRSet.

DNSSEC depends on establishing the authenticity of the DNS hierarchy leading to the domain name in question, and thus its operation depends on beginning the use of cryptographic digital signatures in the root zone. The DS resource record facilitates key signing and authentication between DNS zones to create an authentication chain, or trusted sequence of signed data, from the root of the DNS tree down to a specific domain name. To secure all DNS lookups, including those for non-existent domain names and record types, DNSSEC uses the NSEC resource record to authenticate negative responses to queries. NSEC is used to identify the range of DNS names or resource record types that do not exist among the sequence of domain names in a zone.12

4.1.2 Deployment of DNSSEC

DNSSEC implementation on a global level faces a number of technical and non-technical challenges. The process of cryptographically sign-

10  

For detailed information about these resource records, see Roy Arends, Rob Austein, Matt Larson, Dan Massey, and Scott Rose, “Resource Records for the DNS Security Extensions,” RFC 4034, March 2005, available at <http://www.rfc-editor.org>.

11  

The private key must be closely protected from public access, of course, and so it is not stored in a resource record.

12  

The implementation of DNSSEC also necessitates other changes that are too detailed to discuss here. For the specifics on the two “new message header bits” (CD and AD) in DNSSEC, see Roy Arends, Rob Austein, Matt Larson, Dan Massey, and Scott Rose, “Protocol Requirements for the DNS Security Extensions,” RFC 4035, March 2005, available at <http://www.rfc-editor.org>.

Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×

ing hash values derived from resource records, along with the increase in the DNS packet size to accommodate large key sizes, adds significant operational costs for organizations that manage DNS servers because of the increase in DNS data and the associated increases in server computations and communications traffic.13 The implementation of DNSSEC also increases the volume of Internet traffic and that, in turn, could increase the vulnerability of the Internet to denial-of-service (DoS) attacks—a threat DNSSEC does not protect against, although DNSSEC may offer more confidence in the responses of anycast satellites, which do provide a measure of defense against DoS attacks. DNSSEC could also cause more timeouts that would degrade the quality of service for end users.14 DNSSEC also introduces more complexity to the DNS and adds to the administrative requirements for managing the security mechanism.15 For instance, the administrator of a large zone would probably experience great difficulty in re-signing his or her entire zone daily. This would require dividing the task among many smaller parallel operations that could be managed with software—a solution that is feasible given the DNSSEC design (that makes signatures within a zone remain largely independent), but would not be without additional costs.

Because public keys for the root zone will need to be replaced with new ones on a regular basis, key management for the digital signatures presents another problem for DNSSEC. In particular, the interaction of key revocation with global caching and the distribution of copies of a new public root key remain unresolved,16 and this adds even more importance to the management of root zone keys. The consequence of a corrupted root zone key is that it would break the chain of trust for source authentication and data integrity that serves as the basis of DNSSEC. A related and more fundamental and thorny problem that technical solutions could only partially resolve is reaching agreement over which organization should have control of the root zone key. Obvious candidates for

13  

Estimates for the increased computations and communications traffic associated with the introduction of DNSSEC vary, but range from a 5- to 10-fold increase. See Albitz and Liu, DNS and Bind, 2001; Beth Cohen, “DNSSEC: Security for Essential Network Services,” May 12, 2003, available at <http://www.rfc-editor.org>; and Diane Davidowicz and Paul Vixie, “Securing the Domain Name System,” Network Magazine, January 1, 2000.

14  

See David Berlind, “DNS Inventor Says Cure to Net Identity Problems is Right Under Our Nose,” August 7, 2003, available at <http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2914447,00.html>.

15  

See Cohen, “DNSSEC: Security for Essential Network Services,” 2003.

16  

Distributing new public root keys is difficult as they must be preconfigured in DNS root name servers, but they cannot be delivered via DNSSEC, since they cannot vouch for themselves, and thus they may require an offline distribution mechanism. One proposed solution involves the publication of a public root key in national and international newspapers, which illustrates the magnitude of the problem.

Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×

the controlling organization include VeriSign, ICANN, and the Department of Commerce; other entities could also be considered. However, until a controlling organization is identified, the deployment of DNSSEC is likely to be delayed.17

While the introduction of DNSSEC imposes significant costs and does not eliminate all Internet security concerns nor address all Internet threats,18 its implementation would represent considerable progress in improving the security of the DNS. For example, it would raise the level of protection against the falsification of DNS data to help in deterring identity-related theft and SPAM problems.19 Furthermore, DNSEC provides a basis to build trust on the Internet to support higher-level protocols facilitating Internet Protocol (IP) telephony and other Web services.20

Conclusion: The security of the DNS would be significantly improved if DNSSEC were widely deployed among name servers for the root zone and top-level domains (TLDs) in particular, and throughout the DNS in general.

Conclusion: Urgent attention is needed to identify the organization that would maintain control of the root zone key. The deployment of DNSSEC is likely to be delayed until this organization is identified.

Recommendation: DNSSEC should be deployed throughout the DNS as practical, with highest priority given to deployment in the root zone and the TLDs.

4.2 LINKING THE TELEPHONE AND INTERNET NAMING SYSTEMS

The Internet and the traditional telephone network operate differently. When a traditional telephone call is made, switches create a circuit between the caller and the person who is called. That circuit remains in place for the duration of the call. The process is called circuit switching.

17  

Several facilities in the Netherlands and Sweden are examining how DNSSEC could operate when it is generally deployed by examining procedures, such as key rollover, determining parameters for DNSSEC mechanisms, such as key length and signature lifetimes, and other issues beyond the scope of this discussion. For more information about current efforts of DNSSEC testing, see <http://www.dnssec.net>.

18  

See Atkins and Austein, “Threat Analysis of the Domain Name System,” RFC 3833, 2004.

19  

See Berlind, “DNS Inventor Says Cure to Net Identity Problems Is Right Under Our Nose,” 2003.

20  

See John Leyden, “DNS Inventor Calls for Security Overhaul,” The Register, April 11, 2003, available at <http://www.theregister.co.uk/content/7/30224.html>.

Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×

However, when a message is sent from one computer connected to the Internet to another computer, no such circuit is established. Rather, the message is broken into packets and each is routed through the network independently, possibly even following different paths, and reassembled at their destination in the proper order. That process is called packet-switching. For the most part, the circuit-switched world of telephony and the packet-switched world of the Internet have remained distinct. However, in recent years, a convergence between the two has begun to occur, with increasing use of the Internet to transmit telephone calls through a process called Voice over Internet Protocol, or VoIP.21

The recognition of the potential convergence of telephony and the Internet was one of the motivations for consideration by the technical community of ways to bring telephone numbers into the Domain Name System. Doing so, it was thought, would facilitate communications between the Internet and the world’s telephone networks. The method that was developed is called the Telephone Number Mapping protocol, more commonly known as the ENUM protocol.22 Under the ENUM scheme, telephone numbers, called E.164 numbers,23 are mapped (via the ENUM protocol) to domain names. These are then mapped (in the DNS) to various resources by DNS lookups that lead to Uniform Resource Identifiers (URIs).24 The main premise underlying development of the ENUM protocol is that standard telephone numbers—familiar, globally unique identifiers easily usable on numeric keyboards—are likely to persist. Consequently, making it easy to link the Internet and telephone naming systems may support the development of new and improved services that use a telephony-like model.

Applications that can build on the ENUM protocol include voice communications, fax, e-mail, and messaging. For example, a telephone call

21  

See, for example, the explanation of VoIP on the Federal Communications Commission Web site, <http://www.fcc.gov/voip/>.

22  

See Patrik Fältström and Michael Mealling, “The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM),” RFC 3761, April 2004, available at <http://www.rfc-editor.org>. The mechanism used by ENUM for mapping telephone numbers into the DNS was first specified in late 1992 as part of an Internet “remote printing” model that could substitute for fax and other telephone-enabled transmission mechanisms. That application and the mapping mechanism are described in Carl Malamud and Marshall Rose, “Principles of Operation for the TPC.INT Subdomain: Remote Printing–Technical Procedures,” RFC 1528, October 1993, available at <http://www.rfc-editor.org>.

23  

E.164 is the designation for the International Telecommunication Union recommendation that established the global numbering plan. RFC 3761 stipulates that the domain names generated through the ENUM protocol must adhere to the existing E.164 country (or region) delegations.

24  

See Box 6.2 for a definition of URIs.

Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×

might originate from a standard desktop telephone set and terminate at a telephone connected to the Internet (after passing through a gateway). The implementation of the ENUM protocol may facilitate the completion of such VoIP telephone calls, although such calls do not require the use of ENUM as an addressing mechanism. The ENUM protocol enables the use of a single E.164 number to access applications based on the telephone network, the Internet network, or both networks. Thus, it may enable increased functionality and/or lower costs for communications in such interconnected networks.25

4.2.1 Mechanics and Operations of ENUM

The ENUM protocol specifies how telephone numbers are converted into domain names. The conversion is best explained through an example. Begin with a telephone number such as +46-8-1234567. Then remove all characters except the digits, put dots between the digits, and reverse the order, which yields, in the example above, 7.6.5.4.3.2.1.8.6.4. Then a second-level domain name is appended, which for the implementation of the ENUM protocol is e164.arpa.26 The resulting ENUM domain name is then 7.6.5.4.3.2.1.8.6.4.e164.arpa.

The deployment of ENUM is typically envisioned in tiers. The highest level within the ENUM hierarchy—tier 0—corresponds with the selected second-level domain e164.arpa.27 The name server resource records in this second-level domain would point to “national” tier 1 registries, such as 2.6.e164.arpa (for Indonesia—telephone country code 62) or 2.3.e164.arpa (for Belgium—telephone country code 32).28 The delega-

25  

The resources used to develop this subsection include presentations and discussions at the public forum of the meetings of the Internet Corporation for Assigned Names and Numbers, Rio De Janeiro, Brazil, March 25, 2003, available at <http://www.icann.org/riodejaneiro/captioning-board-meeting-27mar03.htm>; materials from the International Telecommunication Workshop on ENUM, Geneva, Switzerland, February 8, 2002, available at <http://www.itu.int>; the ENUM Web site of the International Telecommunication Union, at <http://www.itu.int/osg/spu/enum/>; “Frequently Asked Questions,” available at <http://www.enum.org>; John C. Klensin, editor, “The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational Documents Contributed to ITU-T Study Group 2 (SG2),” RFC 3245, March 2002, available at <http://www.rfc-editor.org>; and “Online Registries: The DNS and Beyond…,” Release 1.0, September 16, 2003, EDventure Holdings, Inc., New York.

26  

e164.arpa is the second-level domain name specified by the Internet Architecture Board for ENUM use in RFC 3761. The .arpa TLD is intended to support Internet infrastructure initiatives such as the implementation of the ENUM protocol.

27  

The Réseaux IP Européens (RIPE) Network Coordination Centre (NCC) is the administrator of the e164.arpa domain as determined by the Internet Architecture Board.

28  

Twenty-six codes have been delegated (28 have been approved) as of March 4, 2005, as reported by RIPE NCC at <http://www.ripe.net/enum/request-archives>.

Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×

tion beyond tier 1 registries (and the definition of a “tier” itself) may differ among countries. Various trials are underway in a number of countries to identify the most effective models for those countries.29

A tier 1 registry could delegate directly to name servers that contain ENUM information. However, in some models for the implementation of the ENUM protocol, a tier 1 registry would delegate to multiple tier 2 operators (e.g., divided in a way that is based on how telephone numbers are partitioned within a country). Tier 2 operators would then operate name servers that contain ENUM information that takes the form of Naming Authority Pointer (NAPTR) resource records.30 These records include NAPTR records for service-specific addresses (e.g., an e-mail address, cell phone number, fax number, and so on31), which would all be returned in the response to any DNS query about a particular ENUM domain name. An important feature of NAPTR records is that they can convey priority ordering (e.g., try this address first—if there is no response, then try this one). The situation described above is referred to by some as the calling-party control model because the DNS query for the NAPTR records retrieves all possible contact modes—that is, access to this information is determined by the requestor.

Tier 3 services could also be offered. Services at this level could support operations after the completion of a lookup of ENUM information (i.e., some of these operations might not depend on the DNS in any way). For example, a lookup from a tier 2 name server could point to a proxy server that contains tailored user information, rather than to service-specific addresses directly. This tailored user information could, in turn, provide office addresses to all queries and, in addition, home addresses only to those requests with particular characteristics. Alternatively, all queries to the NAPTR records could be directed to this tailored user information, thereby providing the called party with control over what contact information is made available (i.e., the called-party control model).32

29  

For example, see <http://www.itu.int/ITU-T/inr/enum/trials.html>.

30  

NAPTR records are described in Michael Mealling, “Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database,” RFC 3403, October 2002, available at <http://www.rfc-editor.org>.

31  

These addresses may be specified using a variety of protocols that include the Session Initiation Protocol (SIP), which supports the negotiation of the parameters between end-points for a real-time session. See Mark Handley, Henning Schulzrinne, Eve Schooler, and Jonathan Rosenberg, “SIP: Session Initiation Protocol,” RFC 2543, March 1999, available at <http://www.rfc-editor.org>.

32  

This discussion was derived, in part, from “Enum: Mapping Telephone Numbers on to the Internet: Potential Benefits with Public Policy Risks,” April 2003, Center for Democracy and Technology, Washington, D.C., available at <http://www.cdt.org/standards/enum/>.

Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×

4.2.2 Technical and Public Policy Issues

The deployment of the ENUM protocol raises anew most of the challenges associated with the DNS as well as a few new ones. Thus, the technical and policy context for ENUM implementation includes a wide variety of issues that should be resolved prior to the widespread deployment of the ENUM protocol and serves as an illustrative case study for other applications that might be developed on top of the DNS. (It also illustrates another one of the core Internet navigation issues: While ENUM provides mechanisms for mapping from telephone numbers to the DNS and from a domain name to relevant resources, it does not address the problem of determining a telephone number given some (possibly inexact) form of the name of a person or organization (and perhaps some additional qualifying attributes). On a global basis, that navigation problem is far more difficult than the challenges associated with ENUM.)

  • Registrars and consumers. An important implementation issue is who has control over the information in the name servers. Conflicts over the inclusion or content of NAPTR records need to be resolved in some way. The design of the mechanisms for managing these conflicts can draw from past experience with the DNS and telephone networks, which has included dealing with slamming (the unauthorized change in service providers), number portability, and recourse in the event of fraud.

  • Privacy. Since the records in the DNS are publicly accessible, there is some concern about the privacy of the personal information stored there. Of specific concern are URIs in the NAPTR records that refer to personal information that an individual would not wish to have linked to a telephone number in a freely accessible way.33 Alternatives such as the called party control model described above accord individuals the ability to specify what kind of information will be publicly available, and an opt-in strategy provides individuals with the ability to decide whether his or her telephone number will be included in the DNS as an ENUM domain name.

  • Authentication and security. Under a system in which an individual must make a deliberate opt-in decision, authentication of his or her identity is critical in substantiating that the person who wants a number is really that person and that he or she has the rights to use that number (and to make subsequent modifications to ENUM information). In addition, ensuring that the results from lookups to ENUM information are authentic suggests that the implementation of DNSSEC is as critical for ENUM deployment as it is for other DNS applications, as discussed in Section 4.2.

33  

However, note that the storage of E.164 numbers themselves in name servers is not a privacy issue. The issue arises when E.164 numbers are linked to personal information.

Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
  • Institutions. Because ENUM is also dependent on telephone numbers and the various policies that pertain to telephone numbers, the institutional framework includes the International Telecommunication Union (ITU). Also, as ENUM is based on telephone number country codes, national policies must be considered. A clash of institutional approaches may result, given the strong regulatory tradition associated with telephone numbering that contrasts with the traditionally less regulated management of Internet naming and addressing.

    An important design characteristic of the DNS is the existence of a root zone that provides the operational basis for global uniqueness and coherence. By contrast, telephone service providers determine the country codes that they use for routing telephone calls. Each provider might not use the same set of codes. For example, the country code +866 is used from many, but not all, locations in the world to complete telephone calls to Taiwan. The +866 country code is not officially allocated to Taiwan, but it is being reserved by the ITU, which manages the country codes in the world. Because the ENUM model as currently implemented requires ITU and national approval for each ENUM delegation, the use of standard ENUM for communication in and with Taiwan has been prevented by the People’s Republic of China.

  • Other. The deployment of the ENUM protocol raises other issues that are too detailed to be discussed here, such as the disposition of an ENUM domain name when an individual terminates the service for the corresponding telephone number. The references provided in this section provide pointers to documents that explore these issues.

4.2.3 Alternate Models

In principle, ENUM-like domain names could be based on a unique identifier other than a telephone number. For example, consider the use of any random identifier that is globally unique, such as a product bar code. Or one might tie ENUM more closely to the existing country-code TLD model, using ISO 3166 numeric codes rather than E.164 country codes to identify the country-specific part of the number. Another alternative could call for the use (at least in part) of a domain other than e164.arpa. Also, the hierarchy of names need not be based on countries at all. However, it is unclear whether the adoption of an alternate model instead of the ENUM protocol would provide the basis for a superior deployment.

The deployment of the ENUM protocol could support important new applications. However, it is also the case that its deployment would rein-force the utility of telephone numbers. Assuming that it is increasingly desirable to identify an individual or activity rather than a telephone number, the deployment of the ENUM protocol might not be optimal in the

Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×

long run because its use could forestall efforts to develop systems with greater capabilities.

Conclusion: Overall, the plan to deploy the ENUM protocol could lead to applications that use the DNS without necessitating any changes to DNS protocols or software. However, a number of important technical and public policy issues would need to be resolved in each country that has an interest in deploying ENUM. These issues include establishing the rights and requirements of registrars and consumers, developing practices for the protection of personal privacy, implementing procedures for authentication and security, and developing an effective and efficient institutional framework for operation of ENUM.

4.3 INTERNATIONALIZING DOMAIN NAMES

One of the issues of particular interest in many countries is access to the Internet and the DNS using home-country languages and scripts. As the number of users in countries with first languages that are not based on the Roman characters used in the DNS increased dramatically through the 1990s, interest developed in domain names based on non-Roman scripts (e.g., Chinese, Hebrew, Arabic, and so on). Several major efforts were undertaken in the effort to accommodate internationalized domain names (IDNs) within the Internet infrastructure.

Unfortunately, the design of the DNS presents formidable technical challenges for the accommodation of languages that use non-Roman characters. As a lookup system, the DNS must be able to determine unambiguously whether there is a match with a query or not. Comparing strings is much more difficult than most people realize, because the definition of what is “equal” is often not deterministic. For example, consider the case of the French language in Canada and France, for which there are different rules as to whether an accent stays over the character when it is converted from lower to upper case.34 And some languages (e.g., Chinese) cannot even be reduced to a relatively small number of standardized characters (e.g., the character set for English). As these challenges were articulated and analyzed by the interested communities, it became clear that the widespread deployment of IDNs would necessitate a number of compro-

34  

Another example is the “a” with diaeresis “¨” (“ä”) which in German should be sorted and looked at exactly as an “a” with diacritical character, but in Swedish has nothing to do with the character “a” except the look. In the same way, Å as the abbreviation for the physical unit of length “angstrom” is one character, but the initial character of the word Ångström is another (which in turn is different from an “A”). The other problem with the German “a” with diaresis (umlaut) is that it may be considered to match the string “ae”, while not all names containing “ae” match “ä”.

Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×

mises. Some of these compromises stemmed from intense arguments over the preservation of cultural identities, the use of names that are semantically correct, and other linguistic issues.

Other compromises have their roots in technical issues. Some of those who were very concerned about the integrity of the DNS argued that internationalized domain names should be implemented in applications (e.g., by reworking URL and similar formats to accommodate IDNs directly). Some other technical experts argued that the deployment of IDNs should be executed through a major overhaul of the Internet’s infrastructure, rather than as an add-on. However, considerable pressure developed within the interested communities to implement IDNs in the near term and, therefore, solutions that would require extensive changes in architectures or standards did not attract very much support. This pressure provided the impetus for an effort led by the Internet Engineering Task Force (IETF) that culminated in a standard solution, the Internationalizing Domain Names in Applications (IDNA) mechanism.35

4.3.1 Internationalizing Domain Names in Applications

The central goal of the IDNA scheme is to enable end-user viewing of IDNs (e.g., .cn) without altering the DNS protocols themselves. Hence, even though an end user may see an IDN, the DNS itself sees only the usual LDH-style domain names.36 IDNA is entirely a client-side set of procedures.

There are a number of encoding systems for representing various language scripts. In the discussions leading to the adoption of IDNA as a standard, it became clear that a constraint would be needed on the number of encoding systems so that the introduction of IDNs would be tractable. Unicode was agreed to be the client-side encoding system for language scripts.37 Thus, any user application based on other encoding systems would first have to translate its internationalized domain names

35  

IDNA is described in Patrik Fältström, Paul Hoffman, and Adam M. Costello, “Internationalizing Domain Names in Applications (IDNA),” RFC 3490, March 2003, available at <http://www.rfc-editor.org>.

36  

These are domain names comprising letters, digits, and the hyphen—a subset of ASCII—as described in Chapter 2.

37  

“Unicode is a coded character set containing tens of thousands of characters. A single Unicode code point is denoted by “U+” followed by four to six hexadecimal digits, while a range of Unicode code points is denoted by two hexadecimal numbers separated by “..” with no prefixes,” as described in RFC 3490. Additional information about Unicode may be found at <http://www.unicode.org>.

Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×

to a Unicode representation prior to processing by IDNA-compliant procedures.38

The algorithms that make up IDNA work on the individual parts of a domain name separated by dots, which are called labels.39 Translation can occur in two directions: from Unicode to LDH format (ASCII) or the reverse.

The input to the “ToASCII” algorithm is a single label comprising Unicode code points. However, before labels are processed, they must be normalized because different Unicode strings can represent the same domain name.40 Thus, a profile (“nameprep”) is applied—a string preparation and normalization procedure for Unicode that is partially derived from Unicode Technical Consortium (UTC)-specified normalization procedures.41 An encoding system (“punycode”) is then used for mapping “nameprepped” labels into conventional LDH-style labels.42 These labels are then concatenated (with dots in between the labels) to generate the resulting domain name. In the process of assembling the resulting domain name, “xn—” is added as a prefix to denote that the domain name is an IDN;43 an example of such a domain name is xn–fiq43lrrlfy5a.tw. At this point, the DNS is used as described in Chapter 3.

The process for going from ASCII to Unicode involves the use of the decoding algorithm in punycode. The details of this process are described in “Internationalizing Domain Names in Applications (IDNA),” RFC 3490.

38  

The mappings to and from Unicode may not be obvious (and may become controversial), as the local encodings sometimes make distinctions that Unicode does not, or vice versa.

39  

For instance, in www.example.com, there are three labels: www, example, and com.

40  

For example, upper case characters would be converted to lower case characters. However, this case mapping may be problematic, as in the case for handling diacritical marks where characters are mapped to upper case in modern French as compared to older forms (still used in Québéc and elsewhere). Also, consider the Unicode string www.Exa$(not$)mple.com that would be normalized to www.example.com. Adapted from Eric A. Hall, “The IDNA-to-ASCII Conversion Process,” Network Magazine, June 1, 2004, p. 60.

41  

See Paul Hoffman and Marc Blanchet, “Nameprep: A Stringprep Profile for Internationalized Domain Names,” RFC 3491, March 2003; and Paul Hoffman and Marc Blanchet, “Preparation of Internationalized Strings (Stingprep),” RFC 3454, December 2002, available at <http://www.rfc-editor.org/>. For Unicode normalization, see Mark Davis and Martin Dürst, “Unicode Normalization Forms,” Unicode Technical Report #15, available at <http://www.unicode.org/reports/tr15/tr15-23.html>.

42  

See Adam M. Costello, “Punycode: A Bootstring Encoding of Unicode for Internationalized Domain Names in Applications (IDNA),” RFC 3492, March 2003, available at <http://www.rfc-editor.org>.

43  

The description given here is a simplified one. The many details concerning the various algorithms may be found in the RFCs referenced above.

Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
Client-Side Support

There is a gap between “deploying IDNA” (i.e., adding IDNA-format (punycode) domain names in DNS zones) and the actual ability of users to see, or provide as input, domain names expressed in characters that are “native” to their preferred languages. The actual appearance of a domain name in native characters on a screen or printout, or the ability to transcribe such characters from a sign on the side of a bus into a URL to locate a Web page, requires that the relevant applications be upgraded to recognize the IDNA format and to translate to and from local scripts.

Supporting Web Access

Some Web browsers have been upgraded to support IDNA names directly, whereas others, including the most common browser, Internet Explorer, support IDNA through browser plug-ins.44 These extensions to browser operations and syntax are not standardized and not consistent, leading to different users getting different results depending on which tools they choose to use (or, more commonly, have chosen for them).45 In the worst case, the consequence is a breakdown of the principle of referential integrity—a putative domain name or URI, when passed from one user to another, acquires a different meaning (or target) depending on the environments of the two users. Even when support for Web browsers is achieved on a consistent and widespread basis, it will take a considerable period of time to replace the millions of copies of Web browsers. Forrester Research predicts that it will take at least 2 to 3 years before IDNs can really be used for Web browsing and up to 5 years until 90 percent of applications are IDN compatible.46

Supporting E-mail and Other Access

For applications other than the Web, the situation is yet more problematic. There is, in general, no “patch” option equivalent to the browser plug-ins. While there are only a few heavily used browsers, there are very

44  

For an example of a plug-in, see <http://www.idnnow.com>. Internet Explorer does not provide direct support for IDNA as of July 2004.

45  

Improper resolution and browser plug-ins that were not stable enough, complicated, and slow to download were among the reasons why Network Solutions, Inc., pulled out of the IDN business in early 2004. See “NSI Pulls Out of IDN Registration, Citing Technical Problems,” Washington Internet Daily, January 15, 2004.

46  

See Thomas Mendel, “Internationalized Domain Names: Good Idea; Shame About the Execution,” Forrester Research, March 10, 2004, available at <http://www.forrester.com/Research/Document/Excerpt/0,7211,34018,00.html>.

Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×

large numbers of client / user interface programs for e-mail, the File Transfer Protocol (FTP), and other protocols. Some of these programs are embedded in firmware on portable devices, which generally cannot be upgraded in a practical way.

Electronic mail poses additional problems. For most users, the Web is largely passive: People find and view Web pages, but relatively few users create their own Web content or need to establish addressing or location information for it. E-mail, by contrast, is not passive. Most e-mail users are actively engaged in the creation and receipt of e-mail. Addresses read over the phone or copied from business cards or notes may well be more common for e-mail than for the Web. Moreover, Internet e-mail operates in a store-and-forward mode: Unlike, for example, the Web, there is normally no reliable mechanism for a sender to determine, or negotiate, the capabilities of the receiver such as whether a receiver can handle internationalized addresses. And, finally, users typically expect the left side or local part (before the “@”) of an e-mail address to reflect their names and related conventions (or other personal identifiers such as nicknames) and to do so accurately.47 People are often extremely sensitive about the spelling of their names (or other personal identifiers), and efforts to replace e-mail addresses based on names with ones that involve semi-random strings have rarely been met with enthusiasm. Even if the domain name part of the address internationalization problem were solved with appropriate user agent software, it may well lead to more demand for properly spelled and formatted local parts in local scripts. Non-English-speaking users who have been using addresses containing Romanized transliterations of their names are not likely to consider a transition to encoded ASCII strings that have no mnemonic value and that generally cannot be pronounced to be a step forward, especially with their expectations for native-script presentation.

Design and standardization efforts for e-mail local parts are in their infancy in 2005. There are two major proposals. One tries to minimize the number of infrastructure changes that are required (just as IDNA avoided requiring, or even permitting, any DNS protocol changes). The other proposal assumes that true internationalization is going to require rethinking e-mail in an internationalized context (and hence requiring those who wish to take advantage of internationalized addresses to implement some upgrades).

47  

Although the “local part” of an e-mail address is not within the scope of IDNA standards, it is an important issue concerning the internationalization of the Internet more broadly.

Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×

4.3.2 Registries and Registrars

When it approved the initial versions of the IDNA standards, the Internet Engineering Steering Group (IESG) issued a statement that discussed the scope of those documents and areas in which other work was needed by other organizations.48 Specifically, it pointed out that IDNA addresses characters only and that any relevant language or script issues, including near-equivalencies, must be dealt with on a per-registry basis. It also identified the special problems faced by generic top-level domains (gTLDs), the importance of conservatism in characters that are permitted, and concerns about display issues with converted IDNA strings.

After some discussion, and essentially as part of the process of getting several new country-code TLDs to sign up to a formal ICANN relationship, ICANN issued a set of guidelines for the deployment of IDNs in TLDs.49 These guidelines build on the IESG statement and the work of the Joint Engineering Team (JET; discussed below) and provide that top-level domain registries must use the IDNA standards and must adopt conservative, language-specific approaches to IDN registration.

To protect their populations from confusion and fraud, and, in at least some cases, to comply with ICANN guidelines, registries have begun to establish language-based policies for registrations. The key to these involves specifying which particular characters can be registered out of the Unicode set or, when language rules are interpreted strictly, which characters are permitted in combination. Of course, there is no standard list of characters for any given language, and the Unicode Technical Consortium has declined to make lists of characters that belong to named (by language or otherwise) scripts, so a “language” for DNS purposes is ultimately a list of characters chosen by registries, with each registry free to make a different choice. For the convenience of registries that are disinclined to reinvent the wheel, the Internet Assigned Numbers Authority (IANA) set up a registry/catalog of these language/script/registry tables.50 The criterion for registration is that a TLD registry thinks the table is worthwhile; ICANN is not going into the “what is really a language” business.

This leaves the more complex question of what scripts and languages a particular registry should permit. The smaller the number of scripts permitted, the lower the odds of fraud or other undesirable behavior. Prohibition of mixing of scripts (or languages) within a given label is almost implicit in a language-based system and will prevent at least some prob-

Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×

lems,51 but it may restrict some registrations that might be considered reasonable.

All of these issues are much more complex for gTLDs, or other TLDs, that are seen as serving the entire world. Within a country, a decision as to which languages or scripts are more important than others is at least tractable. While it may be very difficult, especially in countries that have more than one official language, and where there are constitutional provisions prohibiting treating some of those as more important than others, these are the types of decisions that governments are typically constituted to make. For generic top-level domains, on the other hand, there is an, at least, implied requirement to treat all registration applicants equally, which implies that policies such as “this script is preferred over that one” or “this language is assumed when the choice of language cannot be determined” are much more difficult, if not impossible, to implement.

4.3.3 Chinese, Japanese, and Korean Scripts

The scripts of Chinese, Japanese, and Korean (CJK) present special challenges. These languages are based on Han ideographs, which are derived from pictographs and are constantly evolving. The “simplification” of Chinese writing in the People’s Republic of China (PRC) in the early 1950s created a sharp divide in methods of writing Chinese, with the simplified characters being used in the PRC, but not in Taiwan, Hong Kong, Macao, and other Chinese-speaking communities elsewhere in the world. However, the mapping between Simplified and Traditional Chinese forms is not always one-to-one, but sometimes requires knowledge of meaning or context.52 In addition, Chinese-based characters are used in written Japanese (as Kanji) and in Korean (as Hanji). An algorithm for handling mappings between Traditional and Simplified Chinese characters that was not sensitive to the particular language in use would map, for example,

51  

At the time IDNA was adopted, the UTC representatives who were participating in the working group were convinced that a “one label, one script” rule would prevent many, perhaps most, potentially fraudulent cases resulting from confusing one character with another. More examples have been turned up since then, and few, if any, people actively engaged in IDN issues now believe that such a restriction would eliminate even a large fraction of the potential problems.

52  

Increasing communications and commerce among Chinese-speaking groups make it important that simplified and traditional characters be treated as equivalent. The committee that did the writing simplification work, however, followed the historical pattern of language reforms over the centuries: they did more than simply replace one written character or one spelling with another and, instead, made some changes to disambiguate homographs and consolidated other words.

Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×

Kanji into Simplified Chinese, resulting in the characters becoming not only incorrect, but also unreadable to a significant fraction of the Japanese population.

To address the CJK script issues, a joint committee known as the Joint Engineering Team (JET) was created among the network information centers and registries for Japan, China, and Korea. That committee created a collection of guidelines for registration of the CJK languages and characters.53 Those guidelines, in turn, introduced two new concepts into DNS management: “variant characters” and “reserved labels” that could be registered into the DNS only by the registrant of some other, primary, label.

In the JET model, the script associated with a particular language is defined by the entries of a table, with the primary (valid) characters being listed, one per row, in that table. If a label were proposed to be registered that contained any characters that did not appear among these entries, the registration attempt would be rejected as not conforming to the script. Each one of these characters may be associated with zero or more preferred variants—characters that, if they appear, are considered to be fully equivalent to the “valid” character; and character variants—characters that might be confused or substituted for the valid one (see Figure 4.2). That is, many Han ideographs look exactly the same or have a similar appearance but are assigned different code points in Unicode. The variants for the individual characters are then used to generate alternate (variant) versions of the labels. For example, if a label proposed for registration were ABC, and “B” had variants “X” and “Y,” a label set (IDN package) would be formed consisting of “ABC,” “AXC,” and “AYC.” All of these labels would be reserved; that is, it would not be possible for anyone but the registrant of “ABC” to actually register them in the DNS.54 The labels generated from the preferred variants (as well as, of course, the original “ABC”) would be automatically registered; those from the character variants would be reserved and could be registered at the option of the package registrant. Of course, if more than one of the characters in a label had a non-zero number of variants, the number of variant labels generated by the combinations, and hence the size of the IDN package, could become quite large—examples have been shown of some Chinese labels that could generate hundreds of variants.55

53  

See Kazunori Konishi, Kenny Huang, Hualin Qian, and Yanwoo Ko, “Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean,” RFC 3743, April 2004, available at <http://www.rfc-editor.org>. Also see James Seng, “JET Guidelines for Internationalized Domain Names,” CircleID, May 8, 2004.

54  

The JET guideline document uses the term “activate.”

55  

The JET guidelines view IDN packages as atomic—there should not be a mechanism for moving names in or out of a package once it is created.

Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×

FIGURE 4.2 Example of multiple forms of an Internationalized Domain Name.

aOf course, it is the case that a domain name of the form xn–k0tp21.com, for instance, could have been registered directly, irrespective of any IDN issues (under IDNA processing, it would represent .com). However, as discussed in Chapter 2, there are strong reasons against the registration of domain names that do not have some kind of semantic or mnemonic significance to someone, and these specially coded labels do not have that property. Indeed, an extensive search was done, and none of these xn–strings actually appeared, at least in the accessible top few levels of the DNS.

SOURCE: Vincent W.S. Chen, “IDN Whois Challenges—TWNIC’s Case Study,” presentation at the ICANN meeting, October 29, 2003, Carthage, Tunisia, available at <http://www.icann.org/presentations/chen-whois-carthage29oct03.ppt>.

Introduction of the “package” concept raises varying economic questions that do not arise with LDH-style domain names. How should the pricing of IDNs reflect the reality that each registration may cause other (sometimes many other) domain names to be reserved? Also, given that there is only one possible authorized registrant for a reserved domain name, what options exist for pricing? Many new possibilities arise in the realm of domain name pricing structures for IDNs.

The challenges posed by CJK scripts also exist, though perhaps less severely, in alphabetic languages. Thus, work to generalize the JET guidelines to alphabetic languages is underway. Two attempts have been made so far to make that generalization work, or at least to construct recommendations for considerations as to how to do it for particular alphabetic scripts and languages.56

56  

See John C. Klensin, “Suggested Practices for Registration of Internationalized Domain Names,” draft, May 17, 2005, available at <http://www.ietf.org/internet-drafts/draftklensin-reg-guidelines-08.txt>.

Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×

4.3.4 Conclusions

It was recognized on its adoption—and it has become much more obvious since—that IDNA solved only part of the internationalization problem. Remaining to be addressed are the questions of consumer confusion—especially those questions that did not involve intellectual property issues; conflict avoidance or resolution for similar-appearing names; differences in interpretations for different languages; restrictions on registrations on a per-domain basis; implications for the Uniform Domain Name Dispute Resolution Process (UDRP) and the Whois database; security issues raised by IDN;57 the implications of (and alternatives to) “multilingual” top level domains.58

Recommendation: Continuing and increased attention to internationalized domain names is necessary. Efforts to coordinate work across different countries, regions, and language groups should be undertaken to prevent the balkanization of the Internet.

Conclusion: The relative merit of an approach for implementing internationalized domain names based on incremental fixes as compared with one that involves an infrastructure overhaul remains uncertain.

Conclusion: Although the ongoing work on internationalized domain names is important, it addresses only a small fraction of the issues associated with internationalization of the Internet in general.

4.4 RESPONDING TO DOMAIN NAME ERRORS

A challenge that has faced the DNS since its inception is that users sometimes make errors when entering domain names as part of Web URIs, e-mail addresses, or other applications on the Internet. The errors may simply be misspellings or they may be the entry of non-existent or inactive domains; often they are the result of a user guessing an address or remembering one incorrectly. When an erroneous domain name arrives at some level in the DNS, the standard response is for a “no such domain” message to be returned to the user. If the application is e-mail, then the

57  

The Unicode Consortium has published a draft technical report that addresses Unicode security issues, including IDN issues. See Mark Davis, “Security Considerations for the Implementation of Unicode and Related Technologies,” Proposed Draft Unicode Technical Report #36, Unicode Consortium, February 2005, available at <http://www.unicode.org/reports/tr36/>.

58  

The implications of IDN introduction for dispute resolution are discussed in Section 5.6.3 and for Whois data and the Whois protocol in Sections 5.7.2 and 5.7.3.

Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×

response may be from a MAILER DAEMON reporting that the mail could not be delivered to the non-existent address. If the application is the Web, then either the Internet service provider (e.g., AOL or Yahoo!) or the browser (e.g., Internet Explorer) may send the erroneous address to a search engine59 to initiate a search. In any event, the user receives information that the address entered is erroneous.

However, in addition to the return of error information to the originator as specified by the DNS technical standards and conventions, two controversial kinds of response to user errors have appeared recently. Both derive from the fundamental law of Internet commerce: traffic = > income. That is, traffic to an Internet location (generally a Web site) can produce income for the owner of the site (through advertising sales); the greater the traffic, the greater the income potential. Consequently, the commercial imperative is to acquire as much traffic as possible. Controversy arises when that imperative leads to actions that confound user expectations or, more fundamentally, challenge the underlying technology standards and conventions on which smooth operation of the Internet has been based.

4.4.1 Traffic Aggregation

The first controversial response is called traffic aggregation. 60 The aggregator sets up a Web site on which multiple advertisers place advertising text that includes links to their marketing sites. The site may or may not have a specific theme, such as travel or electronic products. The advertisers contract to pay for “click-throughs” to their sites, that is, for visits that originate from the links on the aggregator’s site. To attract traffic, the aggregator invests in domain names that would result from likely user errors, for example, misspellings or wrong guesses of the domain names of highly trafficked Web sites. It may also buy names that have not been renewed by the original registrant and solicit people who invest in domain names for future re-sale (often called cybersquatters) to link their warehoused domain names to the aggregator’s Web site in exchange for a share of the resultant proceeds. The aggregator then awaits the traffic resulting from users who misspell or incorrectly guess a domain name or attempt to visit a domain name that is no longer operative or that has not yet been made operative and collects fees from the advertisers, if any, to which they “click through.”

59  

For an extended discussion of search engines and various forms of paid advertising on search engines, see Chapter 7.

60  

Two traffic aggregators, for example, are TrafficZ.com and Namerenters.com. Their Web sites are, respectively, <http://www.TrafficZ.com> and <http://www.Namerenters.com>.

Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×

Although users finding themselves at entirely different sites from those intended may be annoyed, the operation of a traffic aggregation site is in itself neither illegal nor in contravention of the explicit DNS technical standards. However, by responding to an erroneous query with a Web page that the user was not specifically seeking, it does arguably contravene DNS conventions and reasonable user expectations of the DNS service. Depending on the domain name used to attract the traffic, and the content on the page, it might also result in trademark infringement, unfair competition, or cybersquatting prosecution under the Anticybersquatting Consumer Protection Act or violate a host of consumer and child protection laws. Nevertheless, apparently a sufficient number of users find the advertised sites of enough interest to follow their links and, thereby, provide income to the aggregators. Moreover, there does not seem to be a practical technical or regulatory way to control this practice outside the listed legal realms. Therefore, it not further considered here.

4.4.2 Site Finder by VeriSign

Far more controversial and subject to control was the offering of the Site Finder service by VeriSign, which was launched without notice in mid-September 2003.61 That service, which was aimed at users of the World Wide Web, re-routed any request concerning an unregistered domain name within the .com and .net zones to a VeriSign-operated Web site featuring paid advertising links and a search engine, rather than returning the usual “no such domain” error message. VeriSign described it as a value-added service for users that could, at the same time, generate significant revenue for VeriSign from the frequent errors in second-level domain names in the .com and .net TLDs.62 However, the elimination of the “no such domain” error across the .com and .net domains, which numerous applications depend on for their current operation, had a direct and an indirect impact on the performance of applications other than the Web, on the DNS, and on the Internet in general. Many in the Internet technical and operator communities believed that, even though Site Finder was implemented in strict conformance with DNS standards, it was in conflict with their spirit. As a result of their strong complaints and ICANN’s written demand that it desist,63

61  

See VeriSign’s Site Finder FAQ at <http://www.verisign.com/products-services/naming-and-directory-services/naming-services/site-finder-services/page_002698.html>.

62  

VeriSign estimated the number of misspellings to be 20 million per day; see CircleID, “Facts and Figures,” available at <http://www.circleid.com/sitefinder>.

63  

See “Letter from Paul Twomey to Russell Lewis 3 October 2003,” available at <http://www.icann.org/correspondence/Twomey-to-lewis-03oct03.htm>.

Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×

VeriSign suspended the service (under protest) in early October 2003 and pursued the matter in the courts, as is described below.

The intense reactions from the Internet technical and operator communities64 that prompted ICANN to demand the suspension of the service65 until further review raised issues of two types: technical and institutional. The technical issues were, themselves, of two types: first, whether Site Finder would have negative effects on the stability and security of the Domain Name System,66 and second, whether VeriSign had followed an appropriate process for introducing operational changes that have potential effects on other Internet processes and applications. The unilateral introduction of the Site Finder service by VeriSign also raised fundamental institutional issues about the relationship between ICANN and VeriSign and, by extension, the other gTLD registries.

Technical Issues

The Site Finder service introduced changes to the operation of the .com and .net top-level domains, through the use of the wildcard address (A) record. Wildcards, which can be set up by an authoritative name server to stand in for name and class records (see Box 3.2), are used to synthesize records if no exact match exists in the zone. In the Site Finder case, the wild card entries in .com and .net synthesized a response that sent requests for non-existent second-level domains to the VeriSign service Web site. The use of wildcards is specified within Internet Engineering Task Force (IETF) standards for the DNS protocol,67 but their use generally has been localized or confined to an organization.68 In contrast, the

64  

Comments expressing concern about the Site Finder service are available at <http://www.icann.org/general/wildcard-history.htm>.

65  

ICANN, “Advisory Concerning Demand to Remove VeriSign’s Wildcard,” October 3, 2003, available at <http://www.icann.org/announcements/advisory-03oct03.htm>. For a description of ICANN’s ability to force VeriSign to suspend the Site Finder service, see Jonathan Weinberg, “Site Finder and Internet Governance,” December 28, 2003, available at <http://www.law.wayne.edu/weinberg/sitefinder.new.PDF>.

66  

For a discussion of the broader social, political, and privacy issues raised, see <http://www.circleid.com/article/312_0_1_0_C/>. See also<http://cyber.law.harvard.edu/tlds/sitefinder/concerns.html>.

67  

See Paul Mockapetris, “Domain Names—Concepts and Facilities,” RFC 1034, November 1987, available at <http://www.rfc-editor.org> and Paul Mockapetris, “Domain Names—Implementation and Specification,” RFC 1035, November 1987, available at <http://www.rfc-editor.org>.

68  

An example of a common use of wildcards is for mail resource records, or MX records, as they allow e-mail server operators to synthesize all records locally that enable immediate notification that a domain name is valid before a message is sent.

Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×

introduction of wildcards in the A records of the .com and .net TLDs had an impact across a major portion of the DNS. They produced affirmative responses, instead of the expected “no such domain” response, to every attempt by the numerous applications that use the DNS to find a non-existent domain name within the two TLDs, as noted in the next section.

Security and Stability Issues

Technical Community Views. According to an assessment made by the Internet Architecture Board (IAB) shortly after the introduction of the Site Finder service, VeriSign’s unilateral change had direct effects on the many applications that use the Internet.69 For example, SiteFinder altered the normal operation of e-mail servers, which would be to return to the sender any e-mail addressed to non-existent domains. The result of the consistent affirmative responses for the VeriSign-operated top-level domains was to send e-mail addressed to the non-existent domains to the registry-operated server instead. This change affected users, as the immediate notification of a non-existent domain could be delayed by several days or more. It also affected network administrators that incurred costs to reconfigure servers, if they chose to bypass VeriSign’s server.70

According to the IAB, these changes also affected the utility of spam filters that rely on identification of invalid domain names to block messages, and limited the operation of sequential lookups that require notice of unsuccessful DNS queries to seek information from other sources.

Other direct effects of these changes, according to the IAB, included the inconvenience to users who were rerouted to an English-language Web site, rather than receiving an error message in their native language; the potential loss of privacy as a result of e-mail and other Internet traffic being rerouted to an unintended destination; and the danger to Internet security and reliability caused by routing all the erroneous traffic to one location, creating a single point of failure and a target for deliberate attacks.71

An indirect effect of this change was the development of various technical countermeasures to circumvent the VeriSign Site Finder service. The Internet Systems Consortium (ISC) issued a patch for BIND,72 the soft-

69  

See Internet Architecture Board (IAB), “Commentary: Architectural Concerns on the Use of DNS Wildcards,” September 19, 2003, available at <http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html>.

70  

IAB, “Commentary,” September 19, 2003.

71  

As noted in IAB, “Commentary,” September 19, 2003. For an additional list of technical problems, see <http://www.packet-pushers.net/tld-wildcards/>.

72  

For more information on BIND, see Section 3.2.3.

Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×

ware used on many domain name servers, that disabled the re-direct to the VeriSign Web site and responded with an error message instead.73 While patches released by ISC and others74 provided an immediate solution to the re-direct, the ad hoc decision by network administrators or Internet service providers (ISPs) to use a patch or to create another workaround introduced inconsistent changes throughout the Internet,75 that had the second-order consequence of limiting options for other services that operated within the boundaries of either the protocols or reasonable user expectations.

VeriSign’s View. VeriSign responded to the IAB criticism with a point-by-point rebuttal,76 which asserted that (1) Site Finder did not violate the DNS standards; (2) VeriSign was working to provide other-language responses in the near future; (3) Site Finder, by adding a wildcard RRSet to the .com and .net zones and updating its server, can relieve the majority of e-mail problems; (4) applications that rely on error messages can achieve the same effect by querying the DNS for the presence of a wildcard A record in the zone; (5) the detection of erroneous domains is not a widely implemented mechanism for spam identification and discovery and, in any event, is easily circumvented; (6) VeriSign has published mitigation strategies for dealing with other protocols; (7) VeriSign’s experience in securely and stably operating redundant .com and .net servers enables it to protect the Site Finder service; (8) VeriSign does not collect or retain personal information through Site Finder; and (9) VeriSign is willing to work with ICANN and the technical community to deal with Internationalized Domain Names and domains not in the .com or .net domains. It also said that it shared the IAB’s concerns with workarounds to bypass Site Finder and has written a guide for application developers to help them write software consistent with the DNS standards for wildcards.

73  

For a description of the patch, BIND 9.2.3rc2, see <http://www.isc.org/index.pl?/sw/bind/delegation-only.php>.

74  

Such as Imperial Violet; see “VeriSign Countermeasures” at <http://www.imperialviolet.org/dnsfix.html>.

75  

IAB, “Commentary,” September 19, 2003. See also Benjamin Edelman, “The Aftermath: How ISPs Responded to Site Finder Around the World,” CircleID, October 6, 2003, available at <http://www.circleid.com/article/303_0_1_0_C/>.

76  

See VeriSign, “VeriSign’s Response to IAB on Site Finder Service,” October 3, 2003, available at <http://www.verisign.com/products-services/naming-and-directory-services/naming-services/site-finder-services/page_002695.html>.

Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
Process Issues

Technical Community Views. While the technical communities recognize that the use of the wildcard record does not violate DNS protocol specifications,77 its implementation in the two largest TLDs did not follow principles that have guided the process for making Internet architecture decisions from the initial development of the Internet to the present, which have sought to minimize the impact of changes on the network.78 The traditional process of working out proposed changes with the technical communities aims to maintain flexibility for all applications that use the DNS and balance the impact of changes on network operators, users, and the overall stability of the DNS and the Internet in general. Furthermore, as a matter of principle, the technical communities insist that innovation should take place not within the DNS, a core infrastructure of the Internet, but rather on top of the DNS, at the edges—the applications that use the Internet and the DNS.

Examples of innovation at the edges consist of services similar to Site Finder, but which re-route misspelled or non-existent domain names at the Web browser, such as Internet Explorer, or the ISP, such as America Online. Because the service is limited to the Web browser or ISP, other protocols, such as e-mail and FTP, are not affected by the redirect and will still receive a “no such domain” response.

Changes at the core tend to make service offerings at the edges more difficult, as the redirect offered at the DNS level overrides the changes made at the Web browser or ISP level, requiring these services to work around the high-level implementation. While services offered at the edges cause the least harm to the network overall, they are also the most beneficial to users, as they tend to offer more options to elect the service the user wants to receive, to disable it, or to switch to another Web browser or ISP.

Shortly after Site Finder was introduced, ICANN requested that its Security and Stability Advisory Committee (SSAC) undertake a study of Site Finder’s implications for the security and stability of the Internet. After public hearings and comments, the SSAC issued its report in July 2004.79 Its primary focus was not on Site Finder, per se, but rather on the

77  

IAB, “Commentary,” September 19, 2003.

78  

The two principles include the Robustness Principle, “Be conservative in what you do, be liberal in what you accept from others” (Jon Postel, “Transmission Control Protocol,” RFC 793, September 1, 1981), and the Principle of Least Astonishment, “A program should always respond in the way that is least likely to astonish the user” (source unknown; IAB, “Commentary,” September 19, 2003).

79  

Security and Stability Advisory Committee (SSAC), “Redirection in the Com and Net Domains,” report submitted to the ICANN board, July 9, 2004, available at <http://www.icann.org/committees/security/ssac-report-09jul04.pdf>.

Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×

facts that “core registry operations were modified, thereby changing existing services, and the change was introduced abruptly without broad notice, testing, refinement or community agreement.”80 It found that Site Finder (1) “disturbed a set of existing services that had been functioning satisfactorily”; (2) “violated fundamental Internet architectural principles by blurring the well-defined boundary between architectural layers” and moving more control toward the center and away from the periphery; and (3) proposed mechanisms “to ameliorate the undesirable effects of their diversion” that “put VeriSign in the implementation path of every existing and future protocol that uses DNS.”

In addition, the SSAC found that “the abruptness of the change violated accepted codes of conduct that called for public review, comment and testing of changes to core systems.” That process is intended “to ensure that changes are introduced with minimal disruption to existing services and hence with minimal disruption to the security and stability of the Internet.” Moreover, it “precluded the possibility that administrators, IT departments, ISPs and other intermediaries on whom end users rely might be adequately prepared to deal with the consequences.” The SSAC also found that “in response, workarounds and patches were introduced quickly, cumulatively reducing the overall coherence of the system and again violating the established practices of public evaluation, testing, discussion and review before core services are implemented and deployed. These workarounds further blurred the functional layers intrinsic to the Internet’s robust architecture and in some instances created additional—and unintended—harmful effects.”

The SSAC made recommendations to eliminate “synthesized responses” from TLDs that serve the public and that satisfy several technical conditions and to eliminate shortcomings from the specification of DNS wildcards and their use. Most significantly, it recommended that “changes in registry services should take place only after a substantial period of notice, comment and consensus involving both the technical community and the larger user community.” It asserted that the process must “(i) consider issues of security and stability, (ii) afford ample time for testing and refinement and (iii) allow for adequate notice and coordination with affected and potentially affected systems managers and end users.”

VeriSign’s View. As its use of a wildcard A record in the TLDs did not deviate from the IETF standards that describe the DNS protocol specifica-

80  

All quoted material in this paragraph and the next two is from the Executive Summary of the SSAC report “Redirection in the Com and Net Domains,” 2004.

Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×

tions,81 VeriSign maintains that this implementation is a legitimate use of the wildcard and a valid service innovation that adds value for user searches that are not well served by the “page not found” error message.82 Additionally, VeriSign selected its own technical advisory group to test the Site Finder service before it was deployed, arguing that a comparable process within the broader technical community would have taken much longer to complete and was incompatible with the pace and time horizon of business decisions.83

In August 2004, VeriSign published a response to the SSAC’s report.84 In VeriSign’s view, SSAC’s “purported ‘findings’ and ‘recommendations’ are inappropriate, unsubstantiated, and themselves contrary to longstanding written standards and specifications for the operation of the DNS and the Internet.”85 According to VeriSign, since the SSAC did not find that “Site Finder, or wildcards generally, pose a threat to the security and stability of the Internet’s naming and address allocation system,” its “findings” and “recommendations” exceeded the scope of SSAC’s charter. VeriSign argued that the SSAC started its analysis with a predeter-mined conclusion and its report was written by persons who are opponents of Site Finder or competitors of VeriSign. Of greater general significance was its assertion that the report’s findings and recommendations “would in effect restrain technical innovation and commercial practices on the Internet on the basis of vague and unwritten ‘codes of conduct’ and self-styled ‘established practices’ that, contrary to the Report, do not represent consistent Internet practices and conduct.”

VeriSign asserted that the “well-defined boundary between architectural layers” claimed by the SSAC is violated by “multiple technologies widely used on the Internet, such as network translators and firewalls.” Furthermore, VeriSign stated that Site Finder did not change the positioning of the DNS in the layering of network services, while the SSAC-en-

81  

VeriSign, “Architectural Concerns on the Use of DNS Wildcards” (response to IAB “Commentary” of September 19, 2003), September 23, 2003, available at <http://www.verisign.com/nds/naming/sitefinder/iab_response.html>.

82  

VeriSign’s Site Finder Implementation; see <http://www.verisign.com/resources/gd/sitefinder/implementation.pdf>.

83  

See Charles Cooper, “The Cultural Divide and the Internet’s Future,” CNET News.com, October 16, 2003, available at <http://news.com.com/2008-7347_3-5092590.html>.

84  

VeriSign, “VeriSign, Inc.’s Response to Report from the ICANN Security and Stability Committee re ‘Redirection in the Com and Net Domains’,” August 5, 2004, available at <http://www.verisign.com/static/012393.pdf>.

85  

All quoted material in this paragraph and the next two is from VeriSign, “VeriSign, Inc.’s Response,” August 5, 2004.

Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×

dorsed processing of IDNs at the DNS level would, by its own analysis, “blur” the boundaries between architectural layers.

In sum, VeriSign charged SSAC with using “a façade of technical orthodoxy to mask rigid adherence to the status quo of the DNS, which is antithetical to the very nature of the Internet and inconsistent with the RFCs, which themselves recognize the importance of innovation to the Internet.” VeriSign went on to argue that “contrary to ICANN’s clear directive, SSAC has failed to quantify or independently verify any of the purported problems described in the Report, raising serious doubts that they were real, serious, or widespread.”

Institutional Issues

While the Site Finder service raised contentious issues of adherence to technical standards and processes, it also brought to the fore a critical and equally contentious issue of authority over and responsibility for the service offerings of TLD registries, especially gTLD registries that have signed agreements with ICANN. (In Section 3.4.3 it is noted that, as of June 2005, ICANN had such agreements with 10 of the 15 established gTLDs.) The issue is of particular significance to the relationship between ICANN and VeriSign, the registry for the two largest TLD domains, which contain over 38 million second-level registrations between them.

Specifically, the issue is this: To what extent and by what processes can ICANN control the offering of new services or the modification of existing services by TLD registries with which it has contracts? (It has no clear authority over most other TLD registries, although it could—in theory—use the threat of exclusion from the root to control the behavior of other registries. In practice, that threat is unlikely to be used or to be effective under current circumstances.)

In his letter to VeriSign86 demanding the suspension of Site Finder services on .com and .net, the president of ICANN asserted that “our review of the .com and .net registry agreements between ICANN and VeriSign leads us to the conclusion that VeriSign’s unilateral and unannounced changes to the .com and .net top level domains are not consistent with material provisions of both agreements.” He went on to list six specific provisions of the agreements that VeriSign was, in ICANN’s view, violating.

86  

See “Letter from Paul Twomey to Russell Lewis 3 October 2003,” available at <http://www.icann.org/correspondence/Twomey-to-lewis-03oct03.htm>.

Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×

More generally, there is the question of whether the introduction of Site Finder abused the public trust that accompanies the monopoly position granted to VeriSign as the sole operator of the .com and .net TLDs. 87 Did it take advantage of that monopoly position to extract profits from unregistered domain names in unfair competition with ISPs, browsers, and search engines? For example, the second-level domain names directed to the traffic aggregation sites described in Section 4.4.1 must all be specifically registered and a fee must be paid to the registrar, which in turn pays VeriSign for each name. In contrast, Site Finder effectively redirected every unregistered second-level domain in .com and .net to VeriSign’s service, generating traffic-based advertising revenue for VeriSign. Because of VeriSign’s position as the sole registry for those two TLDs, it did not have to specifically register those names in order to control the response to a request for them.

From VeriSign’s perspective, ICANN overstepped its authority as a technical-coordination organization and prevented it from continuing to offer services that benefited Internet users.88 In pursuit of that argument, in February 2004 it filed a federal lawsuit in the U.S. District Court, Central District of California, charging that ICANN “overstepped its contractual authority and improperly attempted to regulate VeriSign’s business in violation of its charter and its agreements with VeriSign.”89 VeriSign asserted that ICANN “stifled the introduction of new services that benefit Internet users and promote the growth of the Internet.” It asked the court to assess damages against ICANN and for ICANN to treat VeriSign in a “fair, reasonable, and equitable” fashion in the future.90

VeriSign’s antitrust claims against ICANN were dismissed in May 2004, but the court initially allowed VeriSign to file an amended com-

87  

For more information, see “The Cooperative Agreement Between the Department of Commerce and VeriSign,” available at <http://www.ntia.doc.gov/ntiahome/domainname/nsi.htm>, which contains the text of the agreement and the amendments to it from 1998 to the present.

88  

VeriSign reported receiving 5 million unique visitors per day while the service was operating; see John Leyden, “Users ‘vote with their mouses’ for Site Finder,” The Register, October 9, 2003, available at <http://www.theregister.co.uk/content/6/32973.html>.

89  

VeriSign, “VeriSign Files Lawsuit Against Site Finder,” press release, February 26, 2004, available at <http://www.verisign.com/verisign-inc/news-and-events/news-archive/usnews-2004/page_005186.html>.

90  

Declan McCullagh, “VeriSign Sues ICANN to Restore Site Finder,” CNET. News.com, February 24, 2004, available at <http://news.com.com/VeriSign+sues+ICANN+to+restore+Site+Finder/2100-1038_3-5165982.html?tag=mainstry>.

Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×

plaint to try to strengthen its legal arguments. However, on August 27, 2004, the court dismissed the claims with prejudice; specifically, the court held that VeriSign’s claims about competitors controlling ICANN’s board could not be supported.

VeriSign’s remaining causes of action based upon contractual matters resulting from the registry agreements had to be refiled in California state courts. In August 2004 it made such a filing in the California superior court in Los Angeles County. VeriSign claims that: “Were VeriSign to defer offering such services to the public during the effective period of the 2001 .com Registry Agreement, or to modify such services due to ICANN’s conduct and threats, VeriSign will suffer irreparable losses of revenue from third parties, profits, market share, competitive position, reputation and good will. Furthermore, millions of Internet users will be deprived of the improved functionality and quality of VeriSign’s services.”91 As of October 2004, the suit remained open.

4.4.3 Conclusions

The Internet and the Domain Name System have operated successfully over two decades, despite manyfold increases in connectivity and connected devices and a great expansion of users and uses. As described in Chapter 3, their successful adaptation to rapid change has been based on a shared commitment among the operators of the Internet and DNS to adhere voluntarily to a set of open standards strictly vetted by the technical community and to a collaborative process of cautious and controlled change. This commitment has held even though the operators are vastly different in nationality and in type—academic, commercial, governmental, not-for-profit—and are not subject to the authority of any overall controlling body. The commitment is threatened, however, by two external forces. One is the desire by some governments and international agencies to introduce stronger international regulation of Internet operations. This force is discussed in Chapter 5. The other is the commercial imperative described earlier.

The commercial organizations that operate key elements of the DNS are appropriately driven by the goal of increasing revenue and profit. As observed earlier, in the Internet that goal is best served by attracting and capturing the attention of user traffic, which can be translated into advertising dollars. Consequently, there is a natural pressure on commercial operators to find ways to do so in competition with other operators. This is what happened in the Site Finder case. VeriSign saw an opportunity to

91  

Paul Festa, “VeriSign Sues ICANN in State Court,” CNET News.com, August 31, 2004, available at <http://news.com.com/2102-1030_3-5331779.html>.

Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×

capture substantial traffic from unregistered domain names and, driven by its commercial imperative, took it. In doing so, it made an unanticipated use of a DNS standard for wildcards. Moreover, it launched its new service as a surprise, without vetting it with the technical community or informing other operators. VeriSign has defended its actions as being within its rights to provide innovative new services that offer benefits to users. However, the technical and operator communities have complained vigorously about VeriSign’s breaking of the shared commitment to standards and process.

Although Site Finder may adhere strictly to published standards and its introduction might even, in some views, be strictly consonant with VeriSign’s rights to innovate, VeriSign’s action poses two high-order challenges to the successful operation of the DNS and the Internet.

First, VeriSign is not like any other TLD registry. It contains roughly half of all second-level domain name registrations and almost all the commercial and network infrastructure domains. It was granted the right to operate the registry as a commercial monopoly by the Department of Commerce and ICANN. Therefore, it is effectively an international public utility whose actions have profound and widespread effects across the entire Internet. When it is seen in that light, it becomes clear that it would be reasonable for it to be required to, at the very least, obtain formal approval from its contractual regulator before introducing any new service with wide-ranging consequences.

Second, and more significant, VeriSign’s action could set in motion a commercial rush among other operators of the DNS. Suppose VeriSign’s actions were copied by other commercial registries. The consequence for the stability and predictability of operations of the DNS could be profound. By ignoring the shared commitment among operators to accept the authority of the technical community on standards and new services and to adhere to a collaborative and cautious process of change, VeriSign tore a hole in the invisible web of implicit understandings that has been critical to the success of the DNS and the Internet. In remains to be seen whether the outcome of its court cases will determine whether that web can be mended.

Recommendation: ICANN should strengthen its contracts with TLD operators (especially the largest ones) to ensure that it has the authority to review proposed changes in their services that could have a detrimental effect on the DNS or on other services that depend on the DNS. It should establish an open, transparent, and speedy process of review for such changes that solicits contributions from the technical community, other DNS operators, other affected Internet operations, and end users.

Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×

Recommendation: TLDs and other DNS operators that do not have agreements with ICANN should voluntarily agree to adhere to published technical standards and to consult the technical community and conduct public review processes before introducing new services that could have a detrimental effect on the DNS or on other services that depend on the DNS.

The issues raised by VeriSign’s introduction of Site Finder are both technical and institutional. As such they serve as an appropriate bridge to the next chapter, which addresses the issues facing the institutional framework of the Domain Name System.

Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
Page 152
Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
Page 153
Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
Page 154
Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
Page 155
Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
Page 156
Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
Page 157
Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
Page 158
Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
Page 159
Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
Page 160
Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
Page 161
Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
Page 162
Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
Page 163
Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
Page 164
Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
Page 165
Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
Page 166
Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
Page 167
Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
Page 168
Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
Page 169
Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
Page 170
Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
Page 171
Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
Page 172
Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
Page 173
Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
Page 174
Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
Page 175
Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
Page 176
Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
Page 177
Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
Page 178
Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
Page 179
Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
Page 180
Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
Page 181
Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
Page 182
Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
Page 183
Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
Page 184
Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
Page 185
Suggested Citation:"4 The Domain Name System: Technology Prospects." National Research Council. 2005. Signposts in Cyberspace: The Domain Name System and Internet Navigation. Washington, DC: The National Academies Press. doi: 10.17226/11258.
×
Page 186
Next: 5 The Domain Name System: Institutional Issues »
  1. ×

    Welcome to OpenBook!

    You're looking at OpenBook, NAP.edu's online reading room since 1999. Based on feedback from you, our users, we've made some improvements that make it easier than ever to read thousands of publications on our website.

    Do you want to take a quick tour of the OpenBook's features?

    No Thanks Take a Tour »
  2. ×

    Show this book's table of contents, where you can jump to any chapter by name.

    « Back Next »
  3. ×

    ...or use these buttons to go back to the previous chapter or skip to the next one.

    « Back Next »
  4. ×

    Jump up to the previous page or down to the next one. Also, you can type in a page number and press Enter to go directly to that page in the book.

    « Back Next »
  5. ×

    Switch between the Original Pages, where you can read the report as it appeared in print, and Text Pages for the web version, where you can highlight and search the text.

    « Back Next »
  6. ×

    To search the entire text of this book, type in your search term here and press Enter.

    « Back Next »
  7. ×

    Share a link to this book page on your preferred social network or via email.

    « Back Next »
  8. ×

    View our suggested citation for this chapter.

    « Back Next »
  9. ×

    Ready to take your reading offline? Click here to buy this book in print or download it as a free PDF, if available.

    « Back Next »
Stay Connected!