Re: Browser DNS balancing effects



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.
.



Relevant Pages

  • Cookies: Multiple Domain Names/Same server
    ... What do you do when your external DNS lists varying DNS names for the same ... I know you can specify a domain for the cookie but how can you ... the same server. ...
    (microsoft.public.dotnet.general)
  • Re: DNS or IIS problem with Win2003 server
    ... In your DNS zone create an A record named "www" wihtout the quotes and use the LAN ip address from the web server. ... the only website running on our server and it is the default website. ... It's a different story with browsers. ...
    (microsoft.public.windows.server.dns)
  • Re: where has tigdepot gone?
    ... my browsers - is my address wrong or are they ... down for maintenance? ... Looks like their server is down. ... The DNS comes up correct so the site is still active. ...
    (sci.engr.joining.welding)
  • Re: error code 0x80072EFD
    ... [CallerId = AutomaticUpdates] ... cookie, reporting URL = ... the server with hr = 80072efd. ...
    (microsoft.public.windowsupdate)
  • Re: Login for access to certain pages or parts?
    ... I know roughly what an .htaccess file is and I have access to more than this on my own server, but not more on commercial servers that host various sites I have made or maintain. ... The successful login routine sets the cookie by testing to see if the password the user has entered matches the one in your database for that user. ... For pages that can be accessed by multiple groups, your authorize function could be passed a comma-delimited list of allowable groups for that page. ... // Authorizes user based on group, redirects if necessary. ...
    (alt.php)