Re: SRV records - when?

[Daniel Senie <dts@senie.com>]

At 03:19 PM 2/14/02, Mats Dufberg wrote:
>On Feb 14, 2002, 14:49 (-0500) Daniel Senie <dts@senie.com> wrote:
>
> > I guess the basic question is whether having SRV records tied to a 1:1
> > mapping of port numbers is desirable, or whether they should be mapped
> > instead to "services."
>
>You are about to redefine SRV. An SRV record connects a service at a
>domain to port and a server. Since http and https cannot share port, they
>cannot share SRV record.

Interesting that RFC 2782 has a note explicitly saying NOT to use port 
numbers. The language is less clear on whether the names must be tied to 
specific ports. I agree I may be arguing for redefining SRV. That may be 
out of scope for an Ops area group. However I have to wonder if it's the 
right thing to do.



> > There are cases, such as the present case of HTTP
> > and HTTPS where the "service" described as the "World Wide Web" uses more
> > than one port. To properly point to a particular host to provide service,
> > it doesn't seem useful to do this based on port number.
> >
> > So, the question is should there be a "web" SRV record that can be queried
> > and which clients use to answer the larger service question, instead of
> > finding out about the HTTP port or the HTTPS port.
>
>I'm sorry, I don't understand your solution. Could you describe how to use
>one SRV record for the web service to cover both plain http and https?

The goal is to get an a mapping to a machine that can handle a service. SRV 
as defined in RFC2782 returns both address and port number, where for what 
I was thinking about, address alone would have been better. It's too bad 
the address and port number were tied together. If we had it to do again, 
I'd argue for one record pointing at the proper host, and separate query to 
ask what port to use on that host for a particular protocol if needed. What 
I was thinking about was doing a lookup for a "service," where "service" is 
defined in terms of application functionality, not in terms of a 1:1 
mapping of "service" to port number.

If it were possible to define a record be defined that answers the question 
for "web service," that could be useful. If one asks the question for HTTP, 
then asks the question for HTTPS, the answers might be different. Website 
operators who really need the two to map together could use existing 
load-balancers and such, and keep the state and so forth, but that 
technology is already present, and is implemented with short DNS timers, 
and so forth.

The solution I was thinking of was to ask for "web," for example, instead 
of "http" or "https" and allow that mapping. This would require 
registration of pseudo-services in the IANA, effectively service names that 
have NO associated port number.

 From RFC 2782: "Service: The symbolic name of the desired service, as 
defined in Assigned Numbers [STD 2] or locally." Further, while this RFC 
references IANA's database, it doesn't specify specifically that the 
service names are from the port number table, though that is what it's been 
taken to mean. I was suggesting is a new table at IANA could be used to 
specify the specific and appropriate values to be used for the Service 
field for SRV requests, and that this would permit what I was suggesting in 
the case of web/http/https.

Unfortunately, the response of the SRV record specifies a single port 
number, which effectively rules out what I was thinking about. If only an 
address were returned by SRV, and another question were asked to get the 
port(s), it would be more workable.

Given the present definition of SRV, the mechanism will not be able to 
support services which employ multiple ports, or applications (e.g. web 
browsers) will have to make assumptions (i.e. look up SRV for http, and 
assume port 443 for the same host for https) or else sites will not 
function correctly.

I guess the question I'm left with is whether SRV records, as defined, are 
useful and sufficient. For some types of services, they are useful. For the 
broader spectrum of applications, SRV records, as defined, appear not to be 
sufficient.

Dan
-----------------------------------------------------------------
Daniel Senie                                        dts@senie.com
Amaranth Networks Inc.                    http://www.amaranth.com