Re: SRV resource records and web browsers

> BM> The only advantage that the suggestion of "fixing CNAMEs" has
> BM> over this is that there are far fewer servers than browsers,
> BM> so it could be easier to phase in that sort of change.
>
> It's not quite as clear cut as that. At least one popular web browsing
> software has the capability of being automatically upgraded with updates that
>
> are published by its manufacturer, which a significant number of its users
> take advantage of (and have even been pressured, by events, to take
> advantage of in recent years). It would not be _that_ hard to roll out to
> a reasonably large number of users an updated version of that browser that
> used "SRV" resource records. No DNS server software manufacturer has an
> equivalent mechanism for rolling out updated versions of its DNS server
> software.
>
> BM> _www._tcp.www.mycompany.com. IN SRV 0 1 80 server.hostingcompany.com.
>
> _www-http._tcp.example.com. 86400 IN SRV 0 0 80 hosting.example.net.
>
> by strict reading of STD 2 and RFC 2782.

IANA has the following in port assignments which forms part of the
current version of STD 2:

http 80/tcp World Wide Web HTTP
http 80/udp World Wide Web HTTP
www 80/tcp World Wide Web HTTP
www 80/udp World Wide Web HTTP
www-http 80/tcp World Wide Web HTTP
www-http 80/udp World Wide Web HTTP

Going backwards in time you have.

RFC 1700:
www-http 80/tcp World Wide Web HTTP
www-http 80/udp World Wide Web HTTP

RFC 1340:
www 80/tcp World Wide Web HTTP [TXL]
www 80/udp World Wide Web HTTP [TXL]

From that there is no clear "winner". Which is one reason why RFC
2782 says that you have to issue a RFC to move a protocol over to
using SRV.

The protocol that runs on port 80 is called "Hypertext Transfer Protocol".
Version 1.0 is described in RFC 1945, "Hypertext Transfer Protocol --
HTTP/1.0". RFC 2616 describes HTTP/1.1. I don't know where version 0.9 is
described (not that I have looked hard for it).

The World Wide Web is a combination of HTTP, FTP, gopher and a number
of other protocols using documents originally written in HTML to inter-
link them.

It would be easy to argue that _http._tcp is what should be used.
Note all the other RFC's refer to it as HTTP.

Below is a long expired draft attempting to get SRV support for HTTP.

If you wish to discuss this further it really should be done over in
the IETF. As there is currently no working group that is appropriate
ietf@ietf.org is where discussion should be moved to. Please cc me
if you decide you need to followup as I'm not subscribed to ietf@ietf.org.

Mark






INTERNET-DRAFT M. Andrews (ISC)
<draft-andrews-http-srv-02.txt> T. Kottelin
Updates: RFC 2616, 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



Expires August 2002 [Page 1]

INTERNET-DRAFT SRV-URI February 2002


looks at the issues involved and recommends solutions.


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



Expires August 2002 [Page 2]

INTERNET-DRAFT SRV-URI February 2002


back to looking for IP address records.

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.

The use of a SRV record does not affect the contents of the "Host:"
field of the HTTP transaction. Its only effect is to potentially
change the address and port the client connects to. All other parts
of the HTTP transaction are not affected by the presence of a SRV
record.

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.






Expires August 2002 [Page 3]

INTERNET-DRAFT SRV-URI February 2002


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
values on address records.

Note [RFC2616], Section 3.2.3 URI Comparison, states that URIs with a
port value equal to the default port (80) are identical to those with
no port or a empty port. URIs with port are no longer treated as
identical to those without a port or with a empty port.

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



Expires August 2002 [Page 4]

INTERNET-DRAFT SRV-URI February 2002


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.

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.

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.





Expires August 2002 [Page 5]

INTERNET-DRAFT SRV-URI February 2002


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


[RFC2616]
Hypertext Transfer Protocol -- HTTP/1.1. R. Fielding, J. Gettys, J.
Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee. June 1999.
RFC 2616.


[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
Internet Software Consortium
1 Seymour St.
Dundas Valley, NSW 2117, Australia
+61 2 9871 4742
Mark.Andrews@isc.org


Thor Kottelin
Laivalahden puistotie 10 C 37
FIN-00810 Helsinki, Finland
+358 400878169
thor@anta.net

















Expires August 2002 [Page 6]

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org