Network Working Group J. Rosenberg
Internet-Draft IAB
Expires: May 30, 2005 November 29, 2004
What's in a Name: False Assumptions about DNS Names
draft-iab-dns-assumptions-00
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 30, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
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, 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. A danger of
this trend is that the humans and automata which consume and use
Rosenberg Expires May 30, 2005 [Page 1]
Internet-Draft Name Assumptions November 2004
these identifiers will make assumptions about the services that are
or should be provided by the hosts associated with these identifiers.
This document discusses this problem in more detail and makes
recommendations on how it can be avoided.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Modeling Usage of the DNS . . . . . . . . . . . . . . . . . . 4
3. Possible Assumptions . . . . . . . . . . . . . . . . . . . . . 5
3.1 By the User . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 By the Client . . . . . . . . . . . . . . . . . . . . . . 5
3.3 By the Server . . . . . . . . . . . . . . . . . . . . . . 6
4. Consequences of False Assumptions . . . . . . . . . . . . . . 7
5. Reasons why the Assumptions can be False . . . . . . . . . . . 8
5.1 Evolution . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2 Leakage . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3 Sub Delegation . . . . . . . . . . . . . . . . . . . . . . 9
6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IAB Members . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Informative References . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . 14
Rosenberg Expires May 30, 2005 [Page 2]
Internet-Draft Name Assumptions November 2004
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], 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. This problem
first manifested itself in the "DNS land grab" that occurred through
the registration of trademarked names by people who were not owners
of those trademarks. The reason people did that is that they knew
that users who saw the name in an HTTP URL would assume that the URL
referenced a site associated with the trademarked name. Another
example are the various proposals for a TLD that could be associated
with adult content [8]. Yet another example are requests for TLDs
associated with mobile devices and services.
The essence of the problem is that humans will frequently make
assumptions about a name based on their expectations and
understanding of what the name implies. When these assumptions are
wrong, the user might be surprised, but the system works, and the
human can do something different having realized that its assumption
was false. When an automata makes similar assumptions, the system
might fail, and it might fail systematically. For this reason, this
document focuses primarily on assumptions that might be made by
client and server automata about the service that is or should be
provided by a host associated with a DNS name. In this context, an
"assumption" is defined as any behavior that is expected when
accessing a service at a domain name, even though the behavior is not
explicitly indicated in the DNS or otherwise codified in protocol
specifications. Although DNS names can contain data besides host
identifiers (i.e., IP addresses), we consider only this case.
Rosenberg Expires May 30, 2005 [Page 3]
Internet-Draft Name Assumptions November 2004
2. Modeling Usage of the DNS
+--------+
| |
| |
| DNS |
|Service |
| |
+--------+
^ |
| |
| |
| |
/--\ | |
| | | V
| | +--------+ +--------+
\--/ | | | |
| | | | |
---+--- | Client |-------------------->| Server |
| | | | |
| | | | |
/\ +--------+ +--------+
/ \
/ \
User
Figure 1
Figure 1 shows a simple conceptual model of how the DNS is used by
applications. A user of the application obtains an identifier for
particular content or service it wishes to obtain. This identifier
is often a URL or URI that contains a domain name. The user enters
this identifier into their client application (for example, by typing
in the URL in a web browser window). The client is the automata (a
software and/or hardware system) that contacts a server for that
application in order to provide service to the user. To do that, it
contacts a DNS server to resolve the domain name in the identifier to
an IP address. It then contacts the server at that IP address. This
simple model applies to application protocols such as HTTP [5], SIP
[7], RTSP [6], and SMTP [9].
From this model, it is clear that three entities in the system can
potentially make false assumptions about the service provided by the
server. The human user may form expectations relating to the content
of the service based on a parsing of the host name from which the
Rosenberg Expires May 30, 2005 [Page 4]
Internet-Draft Name Assumptions November 2004
content originated. The server might assume that the client
connecting to it supports protocols that it does not, can process
content that it cannot, or has capabilities that it does not.
Similarly, the client might assume that the server supports
protocols, content, or capabilities that it does not.
3. Possible Assumptions
For each of the three elements, there are many types of false
assumptions that can be made.
3.1 By the User
The set of possible assumptions here is nearly boundless. A user
might assume that an HTTP URL that looks like a company name maps to
a server run by that company. They might assume that an email from a
email address in the .gov TLD is actually from a government employee.
They might assume that the web content within a TLD labeled as adult
content (for example, .sex) is actually web content [8]. These
assumptions are unavoidable, and not the focus of this document.
3.2 By the Client
Since the client is an automata, it concerns itself with the
protocols needed to communicate with the server. As a result, the
assumptions it might make are assumptions in the operation of the
protocols for communicating with the server. These assumptions
manifest themselves in an implementation through the replacement of a
standardized protocol negotiation technique for an ill-defined rule
for determining some kind of protocol parameter. The result is often
a loss of interoperability, degradation in reliability and worsening
of user experience.
Authentication Algorithm: Though a protocol might support a
multiplicity of authentication techniques, a client might assume
that a server always supports one that is only optional according
to the protocol. For example, a SIP client contacting a SIP
server in a domain that appeared to be used to identify mobile
devices (for example, www.example.cellular) might assume it
supports the optional AKA digest technique [10]. As another
example, a web client might assume that a server with the name
https.example.com supports HTTP over TLS [16].
Data Formats: Though a protocol might allow a multiplicity of data
formats to be sent from the server to the client, the client might
assume a specific one, rather than using the content labeling and
negotiation capabilities of the underlying protocol. For example,
an RTSP client might assume that all audio content delivered to it
Rosenberg Expires May 30, 2005 [Page 5]
Internet-Draft Name Assumptions November 2004
from media.example.cellular uses a low bandwidth codec. As
another example, a mail client might assume that the contents of
messages it retrieves from a mail server at mail.pop.cellular are
always text, instead of checking the MIME headers [11] in the
message to determine the actual content type.
Protocol Extensions: The client attempts an operation on the server
which requires the server to support an optional protocol
extension. However, the client merely assumes that this extension
is supported, rather than implementing the fallback logic
necessary if it is not. As an example, a SIP client requires
reliable provisional responses to its request (RFC 3262 [17]), and
it assumes that this extension is supported on servers in the
domain sip.example.telecom. Furthermore, the client has not
implemented the fallback behavior defined in RFC 3262, since it
assumes that all servers it will communicate with are in this
domain, and that all support this extension. However, this
assumption proves wrong. The result is that the client is unable
to make any phone calls.
Languages: The client supports facilities for processing text content
differently depending on the language of the text. Rather than
determining the language from markers in the message from the
server, the client assumes a language based on the domain name.
This assumption can easily be wrong. For example, a client might
assume that any text in a web page retrieved from www.example.de
is in German, and attempt a translation to Finnish. This would
fail dramatically if the text was actually in French.
3.3 By the Server
The server, like the client, is an automata. It is servicing a
particular domain - www.company.cellular, for example. It might
assume that all clients connecting to this domain support particular
capabilities, rather than using the underlying protocol to make this
determination. Some examples include:
Authentication Algorithm: The server can assume that a client
supports a particular, optional, authentication technique, and it
therefore does not support the mandatory one.
Data Formats: The server can assume that the client supports a
particular set of MIME types, and is only capable of sending ones
within that set. When it generates content in a protocol
response, it ignores any content negotiation headers that were
present in the request. For example, a web server might ignore
the Accept HTTP header field and send a specific image format.
Rosenberg Expires May 30, 2005 [Page 6]
Internet-Draft Name Assumptions November 2004
Protocol Extensions: The server might assume that the client supports
a particular optional protocol extension, and so it does not
support the fallback behavior necessary in the case where it does
not.
Client Characteristics: The server might assume certain things about
the physical characteristics of its clients, such as memory
footprint, processing power, screen sizes, screen colors, pointing
devices, and so on. Based on these assumptions, it might choose
specific behaviors when processing a request. For example, a web
server might always assume that clients connect through cell
phones, and therefore return content that lacks images and is
tuned for such devices.
4. Consequences of False Assumptions
There are numerous negative outcomes that can arise from the various
false assumptions that users, servers and clients can make. These
include:
Interoperability Failure: In these cases, the client or server
assumed some kind of protocol operation which was wrong. The
result is that the two are unable to communicate, and the user
receives some kind of an error. This represents a total
interoperability failure, manifesting itself as a lack of service
to users of the system. Unfortunately, this kind of failure
persists. Repeated attempts over time by the client to access the
service will fail. Only a change in the server or client software
can fix this problem.
System Failure: In these cases, the client or server mis-interpreted
a protocol operation, and this mis-interpretation was serious
enough to uncover a bug in the implementation. The bug causes a
system crash or some kind of outage, either transient or permanent
(until user reset). If this failure occurs in a server, not only
will the connecting client lose service, but other clients
attempting to connect will not get service. As an example, if a
web server assumes that content passed to it from a client
(created, for example, by a digital camera) is of a particular
content type, and it always passes image content to a codec for
de-compression prior to storage, the codec might crash when it
unexpectedly receives an image compressed in a different format.
Poor User Experience: In these cases, the client and server
communicate, but the user receives a diminished user experience.
For example, if a client on a PC connects to a web site that
provides content for mobile devices, the content may be
Rosenberg Expires May 30, 2005 [Page 7]
Internet-Draft Name Assumptions November 2004
underwhelming when viewed on the PC. Or, a client accessing a
streaming media service may receive content of very low bitrate,
even though the client supported better codecs. Indeed, if a user
wishes to access content from both a cellular device and a PC
using a shared address book (that is, an address book shared
across multiple devices), they would need two entries in that
address book, and would need to use the right one from the right
device. This is a poor user experience.
5. Reasons why the Assumptions can be False
Assumptions made by clients and servers about the operation of
protocols when contacting a particular domain are brittle, and can be
wrong for many reasons. On the server side, many of the assumptions
are based on the notion that a domain name will only be given to, or
used by, a restricted set of clients. If the owner of the domain
assumes something about those clients, and can assume that only those
clients use the domain name, that it can configure or program the
server to operate specifically for those clients. Both parts of this
assumption can be wrong, as discussed in more detail below.
On the client side, the notion is similar, being based on the
assumption that a server within a particular domain will provide a
specific type of service. Sub-delegation and evolution, both
discussed below, can make these assumptions wrong.
5.1 Evolution
The Internet, and the devices which access it, are constantly
evolving, often at a rapid pace. Unfortunately, there is a tendency
to build for the here and now, and then worry about the future at a
later time. Many of the assumptions above are predicated on
characteristics of today's clients and servers. Support for specific
protocols, authentication techniques or content are based on today's
standards and today's devices. Even though they may, for the most
part, be true, they won't always be. An excellent example is mobile
devices. A server servicing a domain accessed by mobile devices
might make assumptions about the protocols, protocol extensions,
security mechanisms, screen sizes or processor power of such devices.
However, all of these characteristics can and will change over time.
When they do change, the change is usually evolutionary. The result
is that the assumptions remain valid in some cases, but not in
others. It is difficult to fix such systems, since it requires the
server to detect what type of client is connecting, and what its
capabilities are. Unless the system is built and deployed with these
capability negotiation techniques built in to begin with, such
Rosenberg Expires May 30, 2005 [Page 8]
Internet-Draft Name Assumptions November 2004
detection can be extremely difficult. In fact, fixing it will often
require the addition of such capability negotiation features which,
if they had been in place and used to begin with, would have avoided
the problem altogether.
5.2 Leakage
Servers also make assumptions because of the belief that they will
only be accessed by specific clients, and in particular, those which
are configured or provisioned to use the domain name. In essence,
there is an assumption of community - that a specific community knows
and uses the domain name, while others outside of the community do
not.
The problem is that this notion of community is a false one. The
Internet is global. The DNS is global. There is no technical
barrier that separates those inside of the community from those
outside. The ease with which information propagates across the
Internet makes it extremely likely that such domain names will
eventually find their way into clients outside of the presumed
community. The ubiquitous presence of domain names in various URI
formats, coupled with the ease of conveyance of URIs, makes such
leakage merely a matter of time. Furthermore, since the DNS is
global, and since it can only have one root [12], it becomes possible
for clients outside of the community to search and find and use such
"special" domain names.
5.3 Sub Delegation
Clients and users make assumptions about domains because of the
notion that there is some kind of centralized control that can
enforce those assumptions. However, the DNS is not centralized, it
is distributed. If a domain doesn't delegate its sub-domains and has
its records within a single zone, it is possible to maintain a
centralized policy about operation of its domain. However, once a
domain gets sufficiently large that it begins to delegate sub-domains
to other authorities, it becomes increasingly difficult to maintain
any kind of central control on the nature of the service provided in
each sub-domain. Adherance to policies could be checked by having a
robot periodically sweep the records in all sub-domains; this will
only validate policies which are explicit within the record
themselves (such as TTLs), and even then, it will be slow. Worse
yet, most policies (such as support for specific protocol extensions)
cannot be learned from the DNS itself, and cannot be verified in an
automated way. The other choice is to hope that any centralized
policies are being followed, and then wait for complaints. That
approach has many problems.
Rosenberg Expires May 30, 2005 [Page 9]
Internet-Draft Name Assumptions November 2004
The invalidation of assumptions due to sub-delegation is discussed in
further detail by Eastlake in Section 4.1.3 of [8] and by Faltstrom
in Section 3.3 of [19].
As a result of the fragility of policy continuity across
sub-delegations, if a client or user assumes some kind of property
associated with a TLD (such as ".wifi"), it becomes exponentially
more likely with the number of sub-domains that this property will
not exist in a server identified by a particular name. For example,
in "store.chain.company.provider.wifi", there may be four levels of
delegation from ".wifi", making it quite likely that the properties
which the owner of ".wifi" wishes to enforce are not present.
6. Recommendations
Based on these problems, the clear conclusion is that clients,
servers and users should not make assumptions on the nature of the
service provided to, or by, a domain. More specifically, however,
the following can be said:
Follow the Specifications: When specifications define mandatory
baseline procedures and formats, those should be implemented and
supported, even if the expectation is that optional procedures
will most often be used. For example, if a specification mandates
a particular baseline authentication technique, but allows others
to be negotiated and used, implementations need to implement the
baseline authentication algorithm even if the other ones are used
most of the time.
Use Capability Negotiation: Many protocols are engineered with
capability negotiation mechanisms. For example, a content
negotiation framework has been defined for protocols using MIME
content [13][14][15]. SIP allows for clients to negotiate the
media types used in the multimedia session, as well as protocol
parameters. HTTP allows for clients to negotiate the media types
returned in requests for content. When such features are
available in a protocol, client and servers should make use of
them rather than making assumptions about supported capabilities.
A corollary is that protocol designers should include such
mechanisms when evolution is expected in the usage of the
protocol.
The DNS Record Type Says it All: The only assumptions one can make
about the service defined by the name are encapsulated in the DNS
resource record type that is retrieved. For example, if an A
record exists for the domain web.example.com, one cannot assume
that web service is available at the domain, since all the A
record says is that the host with that name has a particular IP
Rosenberg Expires May 30, 2005 [Page 10]
Internet-Draft Name Assumptions November 2004
address. The only way to definitively know if a service is
available at a domain is through SRV records [2]. As an example,
a client can do a query for _sip._udp.example.com to learn if SIP
UDP services are available at example.com [18].
To summarize - there is never a need to make assumptions. Rather
than doing so, utilize the specifications and the negotiation
capabilities they provide, and the overall system will be robust and
interoperable.
7. Security Considerations
One of the assumptions that can be made by clients or servers is the
availability and usage (or lack thereof) of certain security
protocols and algorithms. For example, a client accessing a service
in a particular domain might assume a specific authentication
algorithm or hash function in the application protocol. It is
possible that, over time, weaknesses are found in such a technique,
requiring usage of a different mechanism. Similarly, a system might
start with an insecure mechanism, and then decide later on to use a
secure one. In either case, assumptions made on security properties
can result in interoperability failures, or worse yet, providing
service in an insecure way, even though the client asked for, and
thought it would get, secure service. This kinds of assumptions are
fundamentally unsound even if the records themselves are secured with
DNSSEC.
8. IAB Members
Internet Architecture Board members at the time of writing of this
document are:
Bernard Aboba
Harald Alvestrand
Rob Austein
Leslie Daigle
Patrik Faltstrom
Sally Floyd
Mark Handley
Rosenberg Expires May 30, 2005 [Page 11]
Internet-Draft Name Assumptions November 2004
Bob Hinden
Geoff Huston
Jun-ichiro Itojun Hagino
Eric Rescorla
Pete Resnick
Jonathan Rosenberg
9 Informative References
[1] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[2] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Three: The Domain Name System (DNS) Database", RFC 3403,
October 2002.
[4] Davis, C., Vixie, P., Goodwin, T. and I. Dickinson, "A Means
for Expressing Location Information in the Domain Name System",
RFC 1876, January 1996.
[5] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[6] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
[7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[8] Eastlake, D., ".sex Considered Dangerous", RFC 3675, February
2004.
[9] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
2001.
[10] Niemi, A., Arkko, J. and V. Torvinen, "Hypertext Transfer
Rosenberg Expires May 30, 2005 [Page 12]
Internet-Draft Name Assumptions November 2004
Protocol (HTTP) Digest Authentication Using Authentication and
Key Agreement (AKA)", RFC 3310, September 2002.
[11] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[12] Internet Architecture Board, "IAB Technical Comment on the
Unique DNS Root", RFC 2826, May 2000.
[13] Klyne, G., "Indicating Media Features for MIME Content", RFC
2912, September 2000.
[14] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC
2533, March 1999.
[15] Klyne, G., "Protocol-independent Content Negotiation
Framework", RFC 2703, September 1999.
[16] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[17] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in Session Initiation Protocol (SIP)", RFC 3262, June
2002.
[18] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
[19] Faltstrom, P. and R. Austein, "Design Choices When Expanding
DNS", draft-iab-dns-choices-00 (work in progress), October
2004.
Author's Address
Jonathan Rosenberg, Editor
IAB
600 Lanidex Plaza
Parsippany, NJ 07054
US
Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Rosenberg Expires May 30, 2005 [Page 13]
Internet-Draft Name Assumptions November 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Rosenberg Expires May 30, 2005 [Page 14]
