Signposts in Cyberspace The Domain Name System and Internet Navigation (2005) / Chapter Skim
Currently Skimming:
4 The Domain Name System: Technology Prospects
4 The Domain Name System: Technology Prospects
Pages 152-186
The Chapter Skim interface presents what we've algorithmically identified as the most significant single chunk of text within every page in the chapter.
Select key terms on the right to highlight them within pages of the chapter.
From page 152... ...
Internationalizing domain names, and 4. Responding to domain name errors.
|
From page 153... ...
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.
|
From page 154... ...
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 4Defined in Roy Arends, Rob Austein, Matt Larson, Dan Massey, and Scott Rose, "DNS Security Introduction and Requirement," RFC 4033, March 2005, available at |
From page 155... ...
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.
|
From page 156... ...
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 |
From page 157... ...
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.
|
From page 158... ...
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)
|
From page 159... ...
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)
|
From page 160... ...
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.
|
From page 161... ...
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)
|
From page 162... ...
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.
|
From page 163... ...
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.
|
From page 164... ...
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)
|
From page 165... ...
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)
|
From page 166... ...
60. 41See 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)
|
From page 167... ...
46See Thomas Mendel, "Internationalized Domain Names: Good Idea; Shame About the Execution," Forrester Research, March 10, 2004, available at |
From page 168... ...
, and efforts to replace email 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.
|
From page 169... ...
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.
|
From page 170... ...
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)
|
From page 171... ...
Also see James Seng, "JET Guidelines for Internationalized Domain Names," CircleID, May 8, 2004. 54The JET guideline document uses the term "activate." 55The 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.
|
From page 172... ...
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 |
From page 173... ...
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.
|
From page 174... ...
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.
|
From page 175... ...
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 midSeptember 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.
|
From page 176... ...
67See Paul Mockapetris, "Domain Names -- Concepts and Facilities," RFC 1034, November 1987, available at |
From page 177... ...
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)
|
From page 178... ...
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.
|
From page 179... ...
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.
|
From page 180... ...
"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.
|
From page 181... ...
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 81VeriSign, "Architectural Concerns on the Use of DNS Wildcards" (response to IAB "Commentary" of September 19, 2003) , September 23, 2003, available at |
From page 182... ...
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.
|
From page 183... ...
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.
|
From page 184... ...
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 |
From page 185... ...
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.
|
From page 186... ...
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.
|
Key Terms
This material may be derived from roughly machine-read images, and so is provided only to facilitate research.
More
information on Chapter Skim is available.