What's in a Name: False Assumptions about DNS Names
RFC 4367
|
| Document |
Type |
|
RFC - Informational
(February 2006; Errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IAB
|
|
Formats |
|
plain text
pdf
html
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
Show full document text