To:
Mats Dufberg <dufberg@nic-se.se>
Cc:
Daniel Senie <dts@senie.com>, Ted Hardie <hardie@oakthorn.com>, Mark.Andrews@isc.org, dnsop@cafax.se
From:
Mark.Andrews@isc.org
Date:
Fri, 15 Feb 2002 11:55:11 +1100
In-reply-to:
Your message of "Fri, 15 Feb 2002 00:35:04 BST." <Pine.BSF.4.30.0202150029290.8992-100000@spider.nic-se.se>
Sender:
owner-dnsop@cafax.se
Subject:
Re: SRV records - when?
> On Feb 14, 2002, 18:16 (-0500) Daniel Senie <dts@senie.com> wrote: > > > 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. > > I don't see how SRV will cause the problem your are describing. If you > have several servers under the same name for the same service, then you > run the risk that the "visitors" end up at different servers different > times. > > > 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. > > What about NAPTR records (RFC 2915)? They are more flexible. > > > Personally I think that SRV will be sufficient in most cases. And they add > flexibility missing today. SRV could be seen as a general for om MX. We > need those. > > > > Mats > > ---------------------------------------------------------------------- > Mats Dufberg <dufberg@nic-se.se> > ---------------------------------------------------------------------- This is simple to solve. Just extend the definition of a session to include both http and https then as long as the host name is the same in the URI you pick the same server (and same IP address) if it is in the set of SRV records for the other service. _http._tcp.example.com SRV 10 50 80 server1.isp.com _http._tcp.example.com SRV 10 50 80 server2.isp.com _http._tcp.example2.com SRV 10 50 80 server1.isp.com _http._tcp.example2.com SRV 10 50 80 server2.isp.com _https._tcp.example.com SRV 10 50 443 server1.isp.com _https._tcp.example.com SRV 10 50 443 server2.isp.com _https._tcp.example2.com SRV 10 50 444 server1.isp.com _https._tcp.example2.com SRV 10 50 444 server2.isp.com So if you start out talking to server1.isp.com HTTP you stay talking to server 1 when you switch to HTTPS. Note: The above is using name based differention for http and port based differentiation for HTTPS. You still get load balancing at the session level. I don't intend to add HTTPS to the current document as there is a lot more required for HTTPS than there is for HTTP. I will add a section about following a session from HTTP to HTTPS which basically says what I said here. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org