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.
Indeed, this leakage is a strength of the Internet architecture, not
a weakness. It enables global access to services from any client
with a connection to the Internet. That, in turn, allows for rapid
growth in the number of customers for any particular service.
6.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 the domain administrators begin
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.
Similarly, the usage of domain names with human semantic connotation
tends to lead to a registration of multiple domains in which a
particular service is to run. As an example, a service provider with
the name "example" might register and set up its services in
"example.com", "example.net", and generally example.foo for each foo
that is a valid TLD. This, like sub-delegation, results in a growth
in the number of domains over which it is difficult to maintain
centralized control.
Not that it is not possible, since there are many examples of
successful administration of policies across sub-domains many levels
deep. However, it takes an increasing amount of effort to ensure
this result, as it requires human intervention and the creation of
process and procedure. Automated validation of adherence to policies
is very difficult to do, as there is no way to automatically verify
many policies that might be put into place.
A less costly process for providing centralized management of
policies is to just hope that any centralized policies are being
followed, and then wait for complaints or perform random audits.
Those approaches have many problems.
The invalidation of assumptions due to sub-delegation is discussed in
further detail in Section 4.1.3 of [8] and in Section 3.3 of [20].
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 increasingly 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, unless the
holder of ".wifi" is working diligently, the properties that the
holder of ".wifi" wishes to enforce are not present. These
properties may not be present due to human error or due to a willful
decision not to adhere to them.
6.4. Mobility
One of the primary value propositions of a hostname as an identifier
is its persistence. A client can change IP addresses, yet still
retain a persistent identifier used by other hosts to reach it.
Because their value derives from their persistence, hostnames tend to
move with a host not just as it changes IP addresses, but as it
changes access network providers and technologies. For this reason,
assumptions made about a host based on the presumed access network
corresponding to that hostname tend to be wrong over time. As an
example, a PC might normally be connected to its broadband provider,
and through dynamic DNS have a hostname within the domain of that
provider. However, one cannot assume that any host within that
network has access over a broadband link; the user could connect
their PC over a low-bandwidth wireless access network and still
retain its domain name.
6.5. Human Error
Of course, human error can be the source of errors in any system, and
the same is true here. There are many examples relevant to the
problem under discussion.
A client implementation may make the assumption that, just because a
DNS SRV record exists for a particular protocol in a particular
domain, indicating that the service is available on some port, that
the service is, in fact, running there. This assumption could be
wrong because the SRV records haven’t been updated by the system
administrators to reflect the services currently running. As another
example, a client might assume that a particular domain policy
applies to all sub-domains. However, a system administrator might
have omitted to apply the policy to servers running in one of those
sub-domains.
7. 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. Put more simply, the behavior of the protocol
machinery should never change based on the domain name of the
host.
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.
"Be liberal in what you accept, and conservative in what you send"
[18]: This axiom of Internet protocol design is applicable here
as well. Implementations should be prepared for the full breadth
of what a protocol allows another entity to send, rather than be
limiting in what it is willing to receive.
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.
8. A Note on RFC 2219 and RFC 2782
Based on the definition of an assumption given here, the behavior
hinted at by records in the DNS also represents an assumption. RFC
2219 [19] defines well-known aliases that can be used to construct
domain names for reaching various well-known services in a domain.
This approach was later followed by the definition of a new resource
record, the SRV record [2], which specifies that a particular service
is running on a server in a domain. Although both of these
mechanisms are useful as a hint that a particular service is running
in a domain, both of them represent assumptions that may be false.
However, they differ in the set of reasons why those assumptions
might be false.
A client that assumes that "ftp.example.com" is an FTP server may be
wrong because the presumed naming convention in RFC 2219 was not
known by, or not followed by, the owner of domain.com. With RFC
2782, an SRV record for a particular service would be present only by
explicit choice of the domain administrator, and thus a client that
assumes that the corresponding host provides this service would be
wrong only because of human error in configuration. In this case,
the assumption is less likely to be wrong, but it certainly can be.
The only way to determine with certainty that a service is running on
a host is to initiate a connection to the port for that service, and
check. Implementations need to be careful not to codify any
behaviors that cause failures should the information provided in the
record actually be false. This borders on common sense for robust
implementations, but it is valuable to raise this point explicitly.
9. 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. These kinds of assumptions are
fundamentally unsound even if the records themselves are secured with
DNSSEC.
10. Acknowledgements
The IAB would like to thank John Klensin, Keith Moore and Peter Koch
for their comments.
11. IAB Members
Internet Architecture Board members at the time of writing of this
document are:
Bernard Aboba
Loa Andersson
Brian Carpenter
Leslie Daigle
Patrik Faltstrom
Bob Hinden
Kurtis Lindqvist
David Meyer
Pekka Nikander
Eric Rescorla
Pete Resnick
Jonathan Rosenberg
12. 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
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] Braden, R., "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC 1122, October 1989.
[19] Hamilton, M. and R. Wright, "Use of DNS Aliases for Network
Services", BCP 17, RFC 2219, October 1997.
[20] Faltstrom, P., "Design Choices When Expanding DNS", Work in
Progress, June 2005.
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
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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.
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.
Intellectual Property
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.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).