- 最新
- 最多得票
- 最多評論
Hello,
Good Day!
Since you have mentioned that if there are two AWS regions in active mode (say Region-1 and Region-2), have health checks registered with Route53 which is setup for 'latency based routing' with Route53 TTL as 30 seconds.
The AWS regions (us-west-2 and us-east-2) refer to Region-1 and Region-2 respectively.
Let's say, you have a public URL "abc.xyz.com" of a service and it is getting service from Region-1. The same service is available in Region-2 as well.
Now as you have mentioned above, if Region 1 will went down, Route 53 will marks it as unhealthy in couple of minutes and will start resolving the queries from Region 2 based on the TTL (Time to live) value you will set for this.
Please note: If an alias record points to an AWS resource, you can't set the time to live (TTL); Route 53 uses the default TTL for the resource. If an alias record points to another record in the same hosted zone, Route 53 uses the TTL of the record that the alias record points to.
During the region 1 failure the traffic will start flowing from the other region. Now If your browser keeps on failing for 15 minutes after which it starts hitting the right active region which is Region-2 then this is not be an issue with the Route 53. I am sorry to say that this is completely related to the browser caches DNS and socket records which is from client browser and nothing can be done from the Route 53 end. The proposed solution we would recommend to fix this by deleting DNS and Socket cache which you won't like your web app users perform.
Remember that DNS caching can occur anywhere from your network layer, through the operating system, to the application container. For example, Java virtual machines (JVMs) are notorious for caching DNS indefinitely unless configured otherwise. You should implement the following best practices.
-
Set a low Time-to-Live (TTL) − The TTL is a field in the DNS response that specifies how long the response can be cached. By setting a low TTL, you can reduce the amount of time that cached results are stored, limiting the window of opportunity for attackers to manipulate the cache.
-
Implement split-horizon DNS − Split-horizon DNS is a technique that uses different DNS servers and cache settings for internal and external networks. By implementing split-horizon DNS, you can prevent internal DNS queries from being cached on external servers, reducing the risk of cache poisoning attacks.
-
Regularly clear DNS caches − Regularly clearing DNS caches can help ensure that cached results are up-to-date and reduce the risk of cache poisoning attacks. You can manually clear DNS caches on client and server-side, or configure automatic cache flushing using DNS server software.
相關內容
- 已提問 1 年前
- AWS 官方已更新 1 年前
- AWS 官方已更新 1 年前