GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4367

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 an
 automaton, such as an application client or server, as a result of
 implementor choice, management directive, or domain owner policy, the
 overall system can fail in various ways.  This document describes a
 number of typical ways in which these assumptions can be codified,
 how they can be wrong, the consequences of those mistakes, and the
 recommended ways in which they can be avoided.
 Section 4 describes some of the possible assumptions that clients,
 servers, and people can make about a domain 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 codified in protocol specifications.  Frequently, these
 assumptions involve ignoring parts of a specification based on an
 assumption that the client or server is deployed in an environment
 that is more rigid than the specification allows.  Section 5
 overviews some of the consequences of these false assumptions.
 Generally speaking, these consequences can include a variety of
 different interoperability failures, user experience failures, and
 system failures.  Section 6 discusses why these assumptions can be
 false from the very beginning or become false at some point in the
 future.  Most commonly, they become false because the environment
 changes in unexpected ways over time, and what was a valid assumption
 before, no longer is.  Other times, the assumptions prove wrong
 because they were based on the belief that a specific community of
 clients and servers was participating, and an element outside of that
 community began participating.
 Section 7 then provides some recommendations.  These recommendations
 encapsulate some of the engineering mantras that have been at the
 root of Internet protocol design for decades.  These include:
    Follow the specifications.
    Use the capability negotiation techniques provided in the
    protocols.
    Be liberal in what you accept, and conservative in what you send.
    [18]
 Overall, automata should not change their behavior within a protocol
 based on the domain name, or some component of the domain name, of
 the host they are communicating with.

Rosenberg Informational [Page 3] RFC 4367 Name Assumptions February 2006

2. Target Audience

 This document has several audiences.  Firstly, it is aimed at
 implementors who ultimately develop the software that make the false
 assumptions that are the subject of this document.  The
 recommendations described here are meant to reinforce the engineering
 guidelines that are often understood by implementors, but frequently
 forgotten as deadlines near and pressures mount.
 The document is also aimed at technology managers, who often develop
 the requirements that lead to these false assumptions.  For them,
 this document serves as a vehicle for emphasizing the importance of
 not taking shortcuts in the scope of applicability of a project.
 Finally, this document is aimed at domain name policy makers and
 administrators.  For them, it points out the perils in establishing
 domain policies that get codified into the operation of applications
 running within that domain.

3. Modeling Usage of the DNS

                     +--------+
                     |        |
                     |        |
                     |  DNS   |
                     |Service |
                     |        |
                     +--------+
                       ^   |
                       |   |
                       |   |
                       |   |
        /--\           |   |
       |    |          |   V
       |    |        +--------+                     +--------+
        \--/         |        |                     |        |
          |          |        |                     |        |
       ---+---       | Client |-------------------->| Server |
          |          |        |                     |        |
          |          |        |                     |        |
         /\          +--------+                     +--------+
        /  \
       /    \
       User
                               Figure 1

Rosenberg Informational [Page 4] RFC 4367 Name Assumptions February 2006

 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 its client application (for example, by typing
 in the URL in a web browser window).  The client is the automaton (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
 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.  Furthermore,
 applications can potentially contain a multiplicity of humans,
 clients, and servers, all of which can independently make these false
 assumptions.

4. Possible Assumptions

 For each of the three elements, there are many types of false
 assumptions that can be made.

4.1. By the User

 The set of possible assumptions here is nearly boundless.  Users
 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 content obtained from a web server within
 a TLD labeled as containing adult materials (for example, .sex)
 actually contains adult content [8].  These assumptions are
 unavoidable, may all be false, and are not the focus of this
 document.

Rosenberg Informational [Page 5] RFC 4367 Name Assumptions February 2006

4.2. By the Client

 Even though the client is an automaton, it can make some of the same
 assumptions that a human user might make.  For example, many clients
 assume that any host with a hostname that begins with "www" is a web
 server, even though this assumption may be false.
 In addition, the client concerns itself with the protocols needed to
 communicate with the server.  As a result, it might make assumptions
 about the operation of the protocols for communicating with the
 server.  These assumptions manifest themselves in an implementation
 when a standardized protocol negotiation technique defined by the
 protocol is ignored, and instead, some kind of rule is coded into the
 software that comes to its own conclusion about what the negotiation
 would have determined.  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 is apparently used to identify mobile
    devices (for example, www.example.cellular) might assume that the
    server supports the optional Authentication and Key Agreement
    (AKA) digest technique [10], just because of the domain name that
    was used to access the server.  As another example, a web client
    might assume that a server with the name https.example.com
    supports HTTP over Transport Layer Security (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
    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.example.cellular
    are always text, instead of checking the MIME headers [11] in the
    message in order to determine the actual content type.
 Protocol Extensions: A client may attempt an operation on the server
    that requires the server to support an optional protocol
    extension.  However, rather than implementing the necessary
    fallback logic, the client may falsely assume that the extension
    is supported.  As an example, a SIP client that requires reliable
    provisional responses to its request (RFC 3262 [17]) might assume
    that this extension is supported on servers in the domain

Rosenberg Informational [Page 6] RFC 4367 Name Assumptions February 2006

    sip.example.telecom.  Furthermore, the client would not implement
    the fallback behavior defined in RFC 3262, since it would assume
    that all servers it will communicate with are in this domain and
    that all therefore support this extension.  However, if the
    assumptions prove wrong, the client is unable to make any phone
    calls.
 Languages: A client may support 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 might assume 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 a server
    within the .de country code TLD (ccTLD) is in German, and attempt
    a translation to Finnish.  This would fail dramatically if the
    text was actually in French.  Unfortunately, this client behavior
    is sometimes exhibited because the server has not properly labeled
    the language of the content in the first place, often because the
    server assumed such a labeling was not needed.  This is an example
    of how these false assumptions can create vicious cycles.

4.3. By the Server

 The server, like the client, is an automaton.  Let us consider one
 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.
 Language: The server can serve content in a particular language,
    based on an assumption that clients accessing the domain speak a
    particular language, or based on an assumption that clients coming
    from a particular IP address speak a certain language.
 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 Informational [Page 7] RFC 4367 Name Assumptions February 2006

 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 the
    client 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.

5. 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, and this assumption 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 misinterpreted a
    protocol operation, and this misinterpretation 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 decompression prior
    to storage, the codec might crash when it unexpectedly receives an
    image compressed in a different format.  Of course, it might crash
    even if the Content-Type was correct, but the compressed bitstream
    was invalid.  False assumptions merely introduce additional
    failure cases.

Rosenberg Informational [Page 8] RFC 4367 Name Assumptions February 2006

 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
    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), the user 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.
 Degraded Security: In these cases, a weaker security mechanism is
    used than the one that ought to have been used.  As an example, a
    server in a domain might assume that it is only contacted by
    clients with a limited set of authentication algorithms, even
    though the clients have been recently upgraded to support a
    stronger set.

6. 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 holder of the domain
 name assumes something about those clients, and can assume that only
 those clients use the domain name, then 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.

6.1. Evolution

 The Internet and the devices that 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

Rosenberg Informational [Page 9] RFC 4367 Name Assumptions February 2006

 might try to 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
 detection can be extremely difficult.  In fact, fixing it will often
 require the addition of such capability negotiation features that, if
 they had been in place and used to begin with, would have avoided the
 problem altogether.

6.2. Leakage

 Servers also make assumptions because of the belief that they will
 only be accessed by specific clients, and in particular, those that
 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.
 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

Rosenberg Informational [Page 10] RFC 4367 Name Assumptions February 2006

 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.

Rosenberg Informational [Page 11] RFC 4367 Name Assumptions February 2006

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

Rosenberg Informational [Page 12] RFC 4367 Name Assumptions February 2006

    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

Rosenberg Informational [Page 13] RFC 4367 Name Assumptions February 2006

 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

Rosenberg Informational [Page 14] RFC 4367 Name Assumptions February 2006

    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.

Rosenberg Informational [Page 15] RFC 4367 Name Assumptions February 2006

 [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

Rosenberg Informational [Page 16] RFC 4367 Name Assumptions February 2006

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).

Rosenberg Informational [Page 17]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4367.txt · Last modified: 2006/02/03 01:48 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki