Internet DRAFT - draft-andrews-http-srv
draft-andrews-http-srv
INTERNET-DRAFT M. Andrews (Nominum Inc.)
<draft-andrews-http-srv-00.txt> T. Kottelin
Updates: RFC 2782 October 2000
HTTP host and port selection using URIs and SRV RRs
A generic mechanism for resolving port conflicts between URIs and SRV RRs
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 April 2001
Copyright Notice
Copyright (C) The Internet Society (2000). All rights reserved.
Abstract
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
Expires April 2001 [Page 1]
INTERNET-DRAFT SRV-URI October 2000
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 there 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 can specify a port and SRV
records do specify a port and hence a potential conflict.
This document addresses the specific requirements of resolving this
conflict as it relates to the HTTP scheme and provides a general
framework for other URI schemes.
The examples below are constructed using the ``http'' scheme.
However, the logic presented in this document is intended to be used
with any URI scheme that allows the ``:<port>'' part; examples
include the ``ftp'' and ``telnet'' schemes.
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 a 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.
Examples:
Single SRV record:
Expires April 2001 [Page 2]
INTERNET-DRAFT SRV-URI October 2000
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: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. A 10.0.3.2
Connect to: 10.0.1.2:8080 or 10.0.2.2:8080 if either is available
(the probability of being selected should be 25% for 10.0.1.2:8080,
and 75% for 10.0.2.2:8080); otherwise, try 10.0.3.2: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. In this case the user agent MUST query for address
records (instead of SRV 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:80
Non-default port specified:
Expires April 2001 [Page 3]
INTERNET-DRAFT SRV-URI October 2000
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. A 10.0.2.2
Connect to: 10.0.0.1: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 neccessary 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 neccessary to continue 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
refering 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.
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''.
Expires April 2001 [Page 4]
INTERNET-DRAFT SRV-URI October 2000
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
Mark Andrews
Nominum Inc.
1 Seymour St.
Dundas Valley, NSW 2117, Australia
+61 2 9871 4742
Mark.Andrews@nominum.com
Thor Kottelin
Laivalahden puistotie 10 C 37
FIN-00810 Helsinki, Finland
+358 400878169
thor@anta.net
Expires April 2001 [Page 5]
