Where does CA API Gateway store its DNS Cache.
It is the java that is storing the DNS entry. You can set how long they are kept :
API Gateway DNS TTL - CA Knowledge
Is there a way to adjust the DNS Time To Live (TTL) on the CA API Management gateway?
To control the DNS TTL, you can add the following line:
To this file:
The value entered for the TTL is in seconds.
There is also a bunch of other java settings as well :
/opt/SecureSpan/JDK/jre/lib/security/java.security## The Java-level namelookup cache policy for successful lookups:## any negative value: caching forever# any positive value: the number of seconds to cache an address for# zero: do not cache## default value is forever (FOREVER). For security reasons, this# caching is made forever when a security manager is set. When a security# manager is not set, the default behavior in this implementation# is to cache for 30 seconds.## NOTE: setting this to anything other than the default value can have# serious security implications. Do not set it unless# you are sure you are not exposed to DNS spoofing attack.##networkaddress.cache.ttl=-1
Hope that helps
thanks for the answer. So the 30 seconds seems to be a default? At least this value is currently mentioned in our file.
But a more interesting question is, how is DNS-Caching and keep-alive impacting global loadbalancing?
We have a policy, where the hostname in the Routing-Assertion is terminating on a GLB, which responds with two different IPs on a Round-Robin basis. We currently have the situation, that the load is NOT equally spread across the two IPs. Therefor the question, is there any special configuration required on the API Gateway to work best in such scenarios?
1) You wrote:
So the 30 seconds seems to be a default? At least this value is currently mentioned in our file.
Interesting if you have different value, maybe someone already changed it. The default I have for (fresh) appliance for APi Gateway 9.3 is this - which is a bit ambiguous in how it describes it :
# any negative value: caching forever# any positive value: the number of seconds to cache an address for# zero: do not cache## default value is forever (FOREVER). For security reasons, this# caching is made forever when a security manager is set. When a security# manager is not set, the default behavior in this implementation# is to cache for 30 seconds.
# NOTE: setting this to anything other than the default value can have# serious security implications. Do not set it unless# you are sure you are not exposed to DNS spoofing attack.##networkaddress.cache.ttl=-1
The above kdoc mentions using the -D otpion to override it on the command line, and I have seen othr cases where -Dsun.net.inetaddr.ttl=0 was recomended, disabling the caching.
Disabling the java dns cache (via -Dsun.net.inetaddr.ttl=0) should then give proper round ribbon results. I expect this is probably what you want to do for quick result.
That should work unless somethig odd is happening like the DNS is returning one IP address more frequently than the other.
Other Options :
Certainly setting ttl=0 would be useful as part of testing why your load is un-evenly distributed.
My expectation wold be with a ttl time= 30sec , that it would spend 30sec sending requests to one backend, then do the DNS resolve again getting a random value and then spend the next 30sec sending to that IP address. Which should prefer one server for short periods of time - but again would not really be what you want.
I know load balancing can be tricky, for example if one server is slower or there is longer network latency, then even if load is equally balanced, then since requests to one server take longer it will seem to be carrying more load as it has more open requests.
If it gets serious, you could consider some load balancer to distribute the load, that way the DNS resolution goes to the IP address of the load balancer and then it distributes the load.
Alternatively you can setup the "Route Assertion" for specifically adding multiple IP addresses and use round-robin approach. Bypassing the DNS lookup.
But hopeful setting ttl=0 works and gives you a simple solution.
Cheers - Mark
first of all, we are currently running on 9.1.01
I assume the DNS-cache setting is a global value? Or can this also be set just for a specific policy?When disabling globally, this will have impact in processing requests for all other policies as well, means that a DNS-lookup needs to be performed for each and every request. This is something, where I'm a Little bit afraid of and therefor don't prefer to do.
Also the "loadbalancing" option in the Route-assertion isn't something we'd like to configure as we don't want to have any business logic within the policy (all changes with IPs or DNS-names need to be adjusted in the policy as well and is not transparent for us anymore).Other question, when I'm doing a ping on the CLI on the affected DNS-name, I'm getting different results, even within these 30s. Is this using the DNS-cache as well? And why is it responding with different IPs then?
I also tried a tcpdump and filtered on both IPs and I see both IPs in the output within ms.
Hm, I repeated this now several times and sometimes I really see only one IP and later the other IP, but inbetween also regularly both IPs.
So is this really a DNS-cache issue? Doesn't really look like this for me.
Any other idea?