Re: SRV records - when?

[Daniel Senie <dts@senie.com>]

At 05:20 PM 2/14/02, Ted Hardie wrote:
> > 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).

I've reread your message a few times, and don't see that you've addressed 
the issue I was concerned about.

If a web site uses multiple protocols (HTTP and HTTPS), and needs any given 
web browser/client to map to exactly ONE host, then SRV is a useless 
mechanism to achieve this. Note that MANY web sites that include shopping 
functionality rely on this today. If there's no solution to this with SRV, 
then I see little incentive for anyone in web services to bother adopting 
SRV into web clients. The web sites would still have to run stateful 
balancers to ensure a given client ALWAYS maps to the same server, or else 
the user's shopping cart could easily be on a server in chicago and when 
they try to check out, the secure server they get routed to in Miami has no 
idea of the cart contents.

Since SRV can't provide this, I guess the next step is to either:

1. Not bother solving the problem.

2. Define something else in DNS to solve this problem.

3. Redefine SRV to be sufficiently flexible for today's application space.

I expect #3 is out of the question, so it's going to be 1 or 2.
-----------------------------------------------------------------
Daniel Senie                                        dts@senie.com
Amaranth Networks Inc.                    http://www.amaranth.com