To:
Daniel Senie <dts@senie.com>
cc:
Ted Hardie <hardie@oakthorn.com>, <Mark.Andrews@isc.org>, <dnsop@cafax.se>
From:
Mats Dufberg <dufberg@nic-se.se>
Date:
Fri, 15 Feb 2002 00:35:04 +0100 (CET)
In-Reply-To:
<5.1.0.14.2.20020214180939.00a24230@mail.amaranth.net>
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> ----------------------------------------------------------------------