What's in a Name: False Assumptions about DNS Names
RFC 4367
Document | Type |
RFC - Informational
(February 2006; Errata)
Was draft-iab-dns-assumptions (iab)
|
|
---|---|---|---|
Author | Jonathan Rosenberg | ||
Last updated | 2020-01-21 | ||
Stream | IAB | ||
Formats | plain text html pdf htmlized with errata bibtex | ||
Stream | IAB state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) |
Network Working Group J. Rosenberg, Ed. Request for Comments: 4367 IAB Category: Informational February 2006 What's in a Name: False Assumptions about DNS Names Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The Domain Name System (DNS) provides an essential service on the Internet, mapping structured names to a variety of data, usually IP addresses. These names appear in email addresses, Uniform Resource Identifiers (URIs), and other application-layer identifiers that are often rendered to human users. Because of this, there has been a strong demand to acquire names that have significance to people, through equivalence to registered trademarks, company names, types of services, and so on. There is a danger in this trend; the humans and automata that consume and use such names will associate specific semantics with some names and thereby make assumptions about the services that are, or should be, provided by the hosts associated with the names. Those assumptions can often be false, resulting in a variety of failure conditions. This document discusses this problem in more detail and makes recommendations on how it can be avoided. Rosenberg Informational [Page 1] RFC 4367 Name Assumptions February 2006 Table of Contents 1. Introduction ....................................................2 2. Target Audience .................................................4 3. Modeling Usage of the DNS .......................................4 4. Possible Assumptions ............................................5 4.1. By the User ................................................5 4.2. By the Client ..............................................6 4.3. By the Server ..............................................7 5. Consequences of False Assumptions ...............................8 6. Reasons Why the Assumptions Can Be False ........................9 6.1. Evolution ..................................................9 6.2. Leakage ...................................................10 6.3. Sub-Delegation ............................................10 6.4. Mobility ..................................................12 6.5. Human Error ...............................................12 7. Recommendations ................................................12 8. A Note on RFC 2219 and RFC 2782 ................................13 9. Security Considerations ........................................14 10. Acknowledgements ..............................................14 11. IAB Members ...................................................14 12. Informative References ........................................15 1. Introduction The Domain Name System (DNS) [1] provides an essential service on the Internet, mapping structured names to a variety of different types of data. Most often it is used to obtain the IP address of a host associated with that name [2] [1] [3]. However, it can be used to obtain other information, and proposals have been made for nearly everything, including geographic information [4]. Domain names are most often used in identifiers used by application protocols. The most well known include email addresses and URIs, such as the HTTP URL [5], Real Time Streaming Protocol (RTSP) URL [6], and SIP URI [7]. These identifiers are ubiquitous, appearing on business cards, web pages, street signs, and so on. Because of this, there has been a strong demand to acquire domain names that have significance to people through equivalence to registered trademarks, company names, types of services, and so on. Such identifiers serve many business purposes, including extension of brand, advertising, and so on. People often make assumptions about the type of service that is or should be provided by a host associated with that name, based on their expectations and understanding of what the name implies. This, in turn, triggers attempts by organizations to register domain names based on that presumed user expectation. Examples of this are the Rosenberg Informational [Page 2] RFC 4367 Name Assumptions February 2006 various proposals for a Top-Level Domain (TLD) that could be associated with adult content [8], the requests for creation of TLDs associated with mobile devices and services, and even phishing attacks. When these assumptions are codified into the behavior of anShow full document text