Re: SRV records - when?

[Ted Hardie <hardie@oakthorn.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.

They cannot share an SRV record, but both might be valid responses to
similar SRV requests applied to different domains.  The response to an
SRV request returns only one port, so you can't give a hostname and
multiple ports.  But you might have a request for "web" return the
http port for queries in the domain nasa.gov and the https port for
schwab.com.  Or to, put a different spin on it, a request for service
"secureweb" might return a host and the https port for one domain but
a host and the http port for another (implying an upgrade to TLS, and
yes, I see the risk in using something implied).

> >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.

I'm fine with a 1:1 mapping of "service" to port number, but I don't
think we should assume that the service will always map to the same
port or transport (imagine using BEEP instead of TCP).  The only
really tricky part of the https vs. http case (against, say having
port 80 and 8080) is that the connection sematics are different
on one.  That may well argue that they be treated as different
services (e.g. web and secureweb).

			regards,
				Ted Hardie