One document matched: draft-jennings-http-srv-00.txt

Network Working Group                                        C. Jennings
Internet-Draft                                             Cisco Systems
Intended status:  Standards Track                           July 5, 2008
Expires:  January 6, 2009


                        DNS SRV Records for HTTP
                       draft-jennings-http-srv-00

Status of this Memo

   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 becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 January 6, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   This document specifies a mechanism for an HTTP client to perform a
   DNS SRV lookup to find an HTTP server.

   The draft is being discussed on the apps-discuss@ietf.org list.







Jennings                 Expires January 6, 2009                [Page 1]

Internet-Draft                  HTTP SRV                       July 2008


1.  Introduction

   The scarcity of IPv4 addresses makes it desirable to run HTTP servers
   on ports other than 80; but URLs like http://www.example.com:3142 are
   not particular good for humans to remember or use.  DNS SRV records
   allow a DNS lookup of a name like www.example.com to provide both a
   port and the IP addresses of the HTTP server.

   This technique is also useful where users wish to run a web server
   behind a NAT but cannot control which port the NAT will allocate for
   this server.  Analogous situations that arise include residential
   users who try to run HTTP servers on personal machines.

   A third use case for HTTP SRV is a situation in which all requests
   should be sent to a primary server, but if that server is down, then
   requests fall back to some alternative server.

   This specification does not update HTTP, and it is not expected that
   most browsers would support it for generic web use.  It would be
   necessary, and supported, for particular applications using HTTP.
   For example, a portal such as Facebook often acts a web client and
   calls specific HTTP-based APIs on other web servers.  These APIs may
   require the use of this specification.  In this situation, the end
   user's web browser might not do the SRV lookup when it browsed to the
   portal web pages, but the HTTP calls that the portal made out to
   other sites to generate the content would use this mechanism.  As
   such architectures become more common, DNS SRV would allow many
   servers that are just providing an API to run on ports other than 80,
   even though main portal sites may still be running on the well known
   ports.  Eventually, web browsers may end up supporting these SRV
   lookups, as the implementation is trivial and has very little
   downside.


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].


3.  Recommendations

   HTTP[RFC2616] Clients compliant with this specification MUST perform
   an SRV lookup as specified in [RFC2782] when resolving the host
   portion of HTTP URI.  As defined in the IANA port numbers registry,
   the service names used are _http and _https.  As described in RFC
   2782, if no SRV record is present, the resolution will fall back on



Jennings                 Expires January 6, 2009                [Page 2]

Internet-Draft                  HTTP SRV                       July 2008


   using other DNS records.


4.  Example

   In the following example, the client will do a lookup on the URI,
   which finds the SRV record that then points at the A record that
   points at the IP address.

   URI: http://example.com
   DNS SRV RR: _http._tcp.example.com. SRV   1 0 8080 host1.example.com.
   DNS A RR:   host1.example.com.      A     192.0.2.88

                                 Figure 1

   In this case the client would form a TCP connection to 192.0.2.88:
   8080.


5.  IANA Considerations

   This document makes no request of IANA.


6.  Security Considerations

   This introduces no new security considerations beyond the common
   usage of HTTP.  It is analogous to DNS CNAME records that redirect to
   other A records.


7.  Acknowledgements

   This idea has been proposed by many people, including Mark Andrews
   and Thor Kottelin in an internet draft in 2000.


8.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2616]  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.

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,



Jennings                 Expires January 6, 2009                [Page 3]

Internet-Draft                  HTTP SRV                       July 2008


              February 2000.


Author's Address

   Cullen Jennings
   Cisco Systems
   170 West Tasman Drive
   Mailstop SJC-21/2
   San Jose, CA  95134
   USA

   Phone:  +1 408 902-3341
   Email:  fluffy@cisco.com





































Jennings                 Expires January 6, 2009                [Page 4]

Internet-Draft                  HTTP SRV                       July 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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, THE IETF TRUST 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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Jennings                 Expires January 6, 2009                [Page 5]