Re: Browser DNS balancing effects
- From: "C." <colin.mckinnon@xxxxxxxxx>
- Date: Mon, 23 Jun 2008 05:55:09 -0700 (PDT)
On Jun 23, 12:29 pm, Theo Markettos <theom
+n...@xxxxxxxxxxxxxxxxxxxxxx> wrote:
I'm trying to work the login process to a website automatically, using
curl's cookie support. So I fire off multiple curl commands which make use
of the same cookie jar, one to the login page, one with my username and
password, and then some more to the site after I've logged in.
What I've noticed is that occasionally the site returns back 'Session lost'
errors at random, claiming that my session has expired when I've only just
logged in. I'm definitely sending the cookie that it gave me.
This doesn't ever happen with a web browser. I notice the DNS entry for the
site is similar to:
login.example.com. 588 IN A 1.2.3.4
login.example.com. 588 IN A 5.6.7.8
It could be that my curl requests are hitting a different server each time,
and there isn't any login-coherency between the two servers (so the cookie
sent by 1.2.3.4 isn't recognised if I send it to 5.6.7.8). It's not the
best written of sites, so this wouldn't surprise me.
So what I wondered is how do browsers handle the case of multiple A records?
Do they pick one and use it for all transactions to that site? Is that
defined behaviour? I know some browsers have their own DNS caching, but
does this cache one or both of the A records? Does they (I'm testing with
mostly Mozilla-based browsers) pick one address but expire it after the TTL?
I read that some browsers ignore the TTL and have their own timeout (to
avoid DNS poisoning), but how does this interact with multiple A records?
Thanks
Theo
It shouldn't matter - if the architect at the remote end makes
sessions local to the ip address of the remote end, then they should
NOT be publishing a round-robin address. It would just break so much
stuff - and it does not fulfill the requirements for Round-Robin DNS.
There are some server systems which make it very hard to replicate the
session but in such a case, the solution is to use content aware load
balancers in from the application servers and route the traffic based
on a cookie (NOT client address).
SSL requires a bit more smarts - each SSL session will be tied to a
specific end-point, but should comfortably handle re-negotiation in
the event of failover.
So optimally, the client should start with a RANDOM entry from the
round robin list, and continue using that until it fails, then switch
to the next entry in the list. This is indeed exactly how every
browser (although really its the resolver in the OS making these
decisions) I've seen works.
However that doesn't change the fact that sometimes people just don't
understand how it should work.
This is all conjecture though - try setting ONE address for the server
in your hosts file (assuming hosts has precedence over DNS) and see if
the eror frequency changes.
C.
.
- Follow-Ups:
- Re: Browser DNS balancing effects
- From: Theo Markettos
- Re: Browser DNS balancing effects
- References:
- Browser DNS balancing effects
- From: Theo Markettos
- Browser DNS balancing effects
- Prev by Date: Re: Browser DNS balancing effects
- Next by Date: Re: Disk failure imminent? But which disk?
- Previous by thread: Re: Browser DNS balancing effects
- Next by thread: Re: Browser DNS balancing effects
- Index(es):
Relevant Pages
|