high availability replicated servers, tomcat session lost. Firefox and chrome use 60 segs as TTL and don't respect DNS defined TTL - google-chrome

Question

I have 4 servers for an http service defined on my DNS servers:
app.speednetwork.in. IN A 63.142.255.107
app.speednetwork.in. IN A 37.247.116.68
app.speednetwork.in. IN A 104.251.215.162
app.speednetwork.in. IN A 192.121.166.40
for all of them the DNS server specify a TTL (time to live) of more than 10 hours:
$ttl 38400
speednetwork.in. IN SOA plugandplay.click. info.plugandplay.click. (
1454402805
3600
3600
1209600
38400 )
Firefox ignore TTL and make a new DNS query after each 60 secs, as seen on
about:config -> network.dnsCacheExpiration 60 and on about:networking -> DNS.
Chrome shows here chrome://net-internals/#dns a correct cached dns entry, with more that 10 hours until Expired:
apis.google.com IPV4 216.58.210.174 2016-04-12 11:07:07.618 [Expired]
app.speednetwork.in IPV4 192.121.166.40 2016-04-12 21:45:36.592
but ignore this entry and every minute requery the dns as discussed https://groups.google.com/a/chromium.org/forum/#!topic/chromium-discuss/655ZTdxTftA and seen on chrome://net-internals/#events
The conclusion and the problem: every minute both browsers query dns again, receive a new IP from the 4 configured on DNS, go for a new IP/server and LOST THE TOMCAT SESSION.
As config every user browser is not an option, my question is:
1) There is some other DNS config I can use for high availability?
2) There is some http header I can use to instruct the browsers to continue using the same IP/server for the day?

Answer 1

The DNS TTL value is the maximum time the information may be cached. There is no minimum time, nor any requirement to cache at all. The browser behavior you describe is entirely within the DNS specs, and the browsers are doing nothing wrong. If your server solution depends on the clients remembering a DNS lookup for a certain time, then you need to redesign it. As you have already discovered, it does not work.
Building a load-balancing cluster of Tomcat servers is hardly rocket science these days, and you can easily google a solution yourself.

Answer 2

Keep-Alive header can make the trick. Using a large value as 65 secs, browsers reuse http connection along all session and don't try a new dns query. This is true in my app, where there is a piggyback XMLHttpRequest connection to server every minute, maybe you'll need a bigger value. Apache default is 5 secs.
On using tomcat directly:
response.setHeader("Keep-Alive", " timeout=65");
On using apache (and mod_ajp) in front of tomcat:
nano /etc/apache2/apache2.conf:
MaxKeepAliveRequests 0
KeepAliveTimeout 65
But this was not a total solution. After disconnects http connection is closed, or under several concurrent server petitions, each one is open over several servers, so results are not under the same server session.
Finally I solve this implementing CORS (cross domain), fixing a server to work with (app1, app2, etc.) and go for it until this server fails.
CORS headers on both server and client let me exchange data no matter that initial files download was from app. (IE another domain).