Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.
OCR for page 152
Signposts in Cyberspace: The Domain Name System and Internet Navigation 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: Improving the security of the DNS, Linking the telephone and Internet naming systems, Internationalizing domain names, and 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-
OCR for page 153
Signposts in Cyberspace: The Domain Name System and Internet Navigation 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>.
OCR for page 154
Signposts in Cyberspace: The Domain Name System and Internet Navigation 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.
OCR for page 155
Signposts in Cyberspace: The Domain Name System and Internet Navigation 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.
OCR for page 156
Signposts in Cyberspace: The Domain Name System and Internet Navigation 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>.
OCR for page 157
Signposts in Cyberspace: The Domain Name System and Internet Navigation 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.
OCR for page 158
Signposts in Cyberspace: The Domain Name System and Internet Navigation 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>.
OCR for page 159
Signposts in Cyberspace: The Domain Name System and Internet Navigation 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.
OCR for page 160
Signposts in Cyberspace: The Domain Name System and Internet Navigation 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, 188.8.131.52.184.108.40.206.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 220.127.116.11.18.104.22.168.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>.
OCR for page 161
Signposts in Cyberspace: The Domain Name System and Internet Navigation 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/>.
OCR for page 162
Signposts in Cyberspace: The Domain Name System and Internet Navigation 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.
OCR for page 176
Signposts in Cyberspace: The Domain Name System and Internet Navigation 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.
OCR for page 177
Signposts in Cyberspace: The Domain Name System and Internet Navigation 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.
OCR for page 178
Signposts in Cyberspace: The Domain Name System and Internet Navigation 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>.
OCR for page 179
Signposts in Cyberspace: The Domain Name System and Internet Navigation 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>.
OCR for page 180
Signposts in Cyberspace: The Domain Name System and Internet Navigation 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.
OCR for page 181
Signposts in Cyberspace: The Domain Name System and Internet Navigation 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.
OCR for page 182
Signposts in Cyberspace: The Domain Name System and Internet Navigation 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>.
OCR for page 183
Signposts in Cyberspace: The Domain Name System and Internet Navigation 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>.
OCR for page 184
Signposts in Cyberspace: The Domain Name System and Internet Navigation 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>.
OCR for page 185
Signposts in Cyberspace: The Domain Name System and Internet Navigation 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.
OCR for page 186
Signposts in Cyberspace: The Domain Name System and Internet Navigation 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.
Representative terms from entire chapter: