INTERNET-DRAFT                                          M. Andrews (ISC)
   <draft-andrews-http-srv-01.txt>                              T. Kottelin
   Updates: RFC 2782                                          February 2002


             Use of SRV records in conjuction with HTTP and URIs.


   Status of this Memo

      This document is an Internet-Draft and is in full conformance with
      all provisions of Section 10 of RFC2026.

      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.

      Comments should be sent to the authors.

      This draft expires on August 2002


   Copyright Notice

      Copyright (C) The Internet Society (2002).  All rights reserved.



   Abstract

      The combined use of SRV records for HTTP along with URIs is not as
      straight forward as it would appear at first glance.  This document
      looks at the issues involved and recommends solutions.



   Expires August 2002                                             [Page 1]

   INTERNET-DRAFT                   SRV-URI                   February 2002


   Introduction

      Many of todays HTTP sites are virtual, that is they are hosted on a
      machine that is not known by the name the HTTP site is known by.
      This leads to the problem of how to rationally give these HTTP sites
      IP addresses.  This has traditionally been done by using CNAMES
      [RFC1034][RFC1035] or by using explicit IP address records where
      CNAMES are illegal due to restrictions in the DNS.

      Both of these solutions have undesired side effects.  CNAMES are not
      protocol specific.  Using IP address records is a logistic nightmare
      for large servers with many virtual sites.  This is becoming a bigger
      problem as companies move away from identifying their HTTP site with
      a ``www'' prefix and just use their delegated domain name, e.g.
      ``http://example.com/''.

      Using SRV [RFC2782] records would seem to be a natural solution to
      this problem in that they are protocol specific and will work where
      CNAMES are illegal in the DNS.

      There are problems with doing this without thought however in that
      URIs [RFC1738] can specify a port and SRV records do specify a port.
      When this occurs which one do you honour?

      In addition to this SRV records provide for load balancing.  For most
      protocols this is straight forward as there will only be a single
      connection made.  For HTTP however there are often many connections
      made in a session.  Should each of these individual connections be
      load balanced or should the load balancing be on a per session basis?

      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.


   1. URIs without an explicit port specification

      If the URI does not explicitly specify a port to connect to, i.e. the
      URI does not contain a ``:<port>'' part, there is no port conflict.
      In this case a client MUST follow the logic specified in [RFC2782],
      including the server selection mechanism provided by the priority and
      weight fields.  If SRV records do not exist then the client MUST fall
      back to looking for IP address records.





   Expires August 2002                                             [Page 2]

   INTERNET-DRAFT                   SRV-URI                   February 2002


      Once a server is selected it SHOULD be continued to be used for the
      rest of the session if possible after an initial connection is made.
      If a server has multiple addresses the client SHOULD continue to use
      the same address while possible taking into consideration ttl values
      on address records.  If connections to this address fail it SHOULD
      try the other addresses for the server first before attempting other
      servers.

      Examples:

      Single SRV record:

         URI:     http://example.com/
         SRV RR:  _http._tcp.example.com. SRV   10 0 8080 host1.example.com.
         A RRs:   example.com.            A     10.0.0.2
                  host1.example.com.      A     10.0.1.1

      Connect to:  10.0.1.1 port 8080

      Multiple SRV records:

         URI:      http://example.com/
         SRV RRs:  _http._tcp.example.com. SRV   10 1 8080 host1.example.com.
                   _http._tcp.example.com. SRV   10 3 8080 host2.example.com.
                   _http._tcp.example.com. SRV   20 0 8080 host3.example.com.
         A RRs:    example.com.            A     10.0.0.4
                   host1.example.com.      A     10.0.1.2
                   host2.example.com.      A     10.0.2.2
                   host3.example.com.      AAAA  1080::8:800:200C:417A

      Connect to: 10.0.1.2 port 8080 or 10.0.2.2 port 8080 if either is
      available (the probability of being selected should be 25% for
      10.0.1.2 port 8080, and 75% for 10.0.2.2 port 8080); otherwise, try
      1080::8:800:200C:417A port 8080.

   2. URIs with a explicit port specification

      If the URI does explicitly specify a port to connect to then there is
      a potential conflict in the port specification between the URI and
      the SRV records, and the SRV record is ignored.  In this case the
      user agent MUST query for address records for the host name in the
      URI (instead of SRV records).

      If the server has multiple addresses the client SHOULD continue to
      use the same address while possible taking into consideration ttl



   Expires August 2002                                             [Page 3]

   INTERNET-DRAFT                   SRV-URI                   February 2002


      values on address records.

      Examples:

      Default port specified:

         URI:      http://example.com:80/
         SRV RR:   _http._tcp.example.com. SRV   10 1 8080 host2.example.com.
         A RRs:    example.com.            A     10.0.0.1
                   host2.example.com.      A     10.0.2.2

      Connect to: 10.0.0.1 port 80

      Non-default port specified:

         URI:      http://example.com:8080/
         SRV RR:   _http._tcp.example.com. SRV   10 1 80 host2.example.com.
         CNAME RR: example.com.            CNAME host1.example.com.
         A RRs:    host1.example.com.      A     10.0.0.1
                   host2.example.com.      AAAA  1080::8:800:200C:417A

      Connect to: 10.0.0.1 port 8080


   3. Transitioning Considerations

      When transitioning from using a non-SRV solution to using a SRV based
      solution old, non-SRV aware, clients will continue to look for
      address records.  It may be necessary to use redirection at the HTTP
      layer to direct these clients to the new servers if the SRV records
      point to a different <address, port> tuple.

      It will also be necessary to continue to provide the existing address
      / CNAME records until there is a significant percentage of SRV aware
      clients.  Experience has shown that this should be within one to two
      years of the introduction of the first SRV aware client, for HTTP.

      In cases where you are just trying to replace the A or CNAME record
      referring to a service providers machine with a SRV record the
      following should suffice.

      The service provider is hosting the service on machine.example.net
      and you are example.com.





   Expires August 2002                                             [Page 4]

   INTERNET-DRAFT                   SRV-URI                   February 2002


         example.com.        A   <IP address of machine.example.net>
         _http._tcp.example.com. SRV 0 0 80 machine.example.net.



   Security Considerations

      The authors believe the algorithm described in this document to not
      cause any new security problems.  However care should be taken as SRV
      and non-SRV aware clients may be directed to different locations.


   IANA Considerations

      A well known label has to be allocated for the first label of the
      http SRV record.  This document has used ``_http''.


   References


   [RFC1034]
      Domain names - concepts and facilities. P.V. Mockapetris.
      Nov-01-1987. STD 0013, RFC 1034.


   [RFC1035]
      Domain names - implementation and specification. P.V. Mockapetris.
      Nov-01-1987. STD 0013, RFC 1035.


   [RFC1738]
      Uniform Resource Locators (URL). T. Berners-Lee, L. Masinter, M. McC¡
      ahill. December 1994. RFC 1738.


   [RFC2782]
      A DNS RR for specifying the location of services (DNS SRV). A. Gul¡
      brandsen, P. Vixie, L. Esibov. February 2000. RFC 2782.


   Authors' Addresses






   Expires August 2002                                             [Page 5]

   INTERNET-DRAFT                   SRV-URI                   February 2002


         Mark Andrews
            Internet Software Consortium
            1 Seymour St.
            Dundas Valley, NSW 2117, Australia
            +61 2 9871 4742
            Mark.Andrews@isc.org


         Thor Kottelin
            (contact information updated)
            Turvasana Tmi
            P.O. Box 355
            00811 Helsinki, Finland 
            0600 306 010 (within Finland; 0.99 €/call + 1.95 €/min + lnc)
            thor@anta.net



































   Expires August 2002                                             [Page 6]

Google’s use of the DART cookie enables Google to serve ads to you based on your visits to this and other websites. If you do not wish to use the DART cookie, please opt out on the privacy policy page for Google’s ad-and-content network. Additionally, you can usually specify your cookie preferences in your browser settings.

All content © 2000–2014 Thor Kottelin t/a Turvasana Tmi, unless otherwise indicated. Any trademarks or registered trademarks mentioned on this site belong to their respective owners. Content and techniques used on this site may be available for licensing; for details, please contact the webmaster. — Conventional hyperlinking to this site is welcome. However, none of the content on this site may be shown, even partly, in a context inferring or claiming it to be part of or sponsored by any other organisation or site. Such prohibited techniques include (but are not limited to) framesets, interstitial pages, kiosk mode pop-ups and reverse proxies. — For information on advertising, please click on the ‘Ads by Google’ or ‘AdChoices’ link next to any advertisement.

54.226.120.183 ec2-54-226-120-183.compute-1.amazonaws.com
(none) CCBot/2.0 (http://commoncrawl.org/faq/)
/nic/draft-andrews-http-srv-01.shtml /nic/draft-andrews-http-srv-01.shtml Saturday, 19-Apr-2014 09:38:02 GMT