To:
jerry scharf <scharf@vix.com>
Cc:
dnsop@cafax.se
From:
Daniel Senie <dts@senie.com>
Date:
Thu, 14 Feb 2002 20:11:35 -0500
In-Reply-To:
<60660000.1013734500@localhost>
Sender:
owner-dnsop@cafax.se
Subject:
Re: SRV records - when?
At 07:55 PM 2/14/02, jerry scharf wrote: >Daniel, > >If you want to guarantee that the secure and non-secure servers are the >same, you don't want SRV as I see it. Since the whole idea of SRVs is to >present a controlled choice setup, you shouldn't use it for things that >you don't want choice. More or less right. The thought was SRV would work well for choosing the web server to talk to, though. When the client switches to secure mode, that's when going through this choice process again sounds like a really bad idea. >When you switch from the shopping cart to the checkout, and you've >designed your system so that the information is local, send them to a A >record https host that is the one with the shopping cart info. The concern was you might have several possible addresses for the https, maching the several possibles for the http. Best bet may well be to tell web browser vendors they can use SRV for http, but use the A record they get back from that request to find the https server. Messes up someone else's desire to use SRV to spread out SSL for virtual servers, though (something I hadn't thought about). > You don't want SRV here, because if the host with the shopping cart > doesn't catch the https connection in a transient way, the user will get > sent to the next host, get to a host with an empty shopping cart and be > confused. > >If you don't use SRV when you don't want choice, you won't have a problem >with SRV records. > >If someone designs a systems like this, and it's (IMO) not robust against >host failures, they get what they designed. no way for any DNS trick to >fix this. If you don't use same value round robin with this, then again >the SRV linkage problem goes away. Right. Ultimately we come back to people running DNS-based multisite load balancers with very short timeouts to handle outages. >I don't think this rationale is compelling to make any changes to SRV. I ultimately see little rationale for getting the web client vendors to adopt SRV, or for web server farm providers to use it, unfortunately. ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com