At 06:29 PM 2/14/02, Mats Dufberg wrote: >On Feb 14, 2002, 17:02 (-0500) Daniel Senie <[EMAIL PROTECTED]> wrote: > > > 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. > >I don't see the point of having to ask twice. I don't see the problem of >having the port in the data. On the contrary, by having port number, it is >more flexible.
The point is to ensure the client talks over the multiple ports to the same server, in the event a given application requires that. Web-based shopping sites which use HTTP for speed and HTTPS for checkout security are a prime example. > > 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. > >You can handle it by having more than one SRV record. So you have SRV records pointing at 3 different web farms for http, and records for https pointing to the same web farms. How do you ensure that a given resolver gets the SAME server IP address (though different port) for the http and https requests? >Mats > >---------------------------------------------------------------------- >Mats Dufberg <[EMAIL PROTECTED]> >---------------------------------------------------------------------- ----------------------------------------------------------------- Daniel Senie [EMAIL PROTECTED] Amaranth Networks Inc. http://www.amaranth.com
