HughesNet used to run a caching DNS resolver on their customer equipment circa 2016 (not sure if they still do) which overwrote TTLs to 12 hours. Java/JVM hist

HughesNet used to run a caching DNS resolver on their customer equipment circa 2016 (not sure if they still do) which overwrote TTLs to 12 hours. Java/JVM historically ignored TTL and just did a single DNS lookup and cached the result unless configured otherwise. PGBouncer ignores DNS TTL and has its own configuration. I've seen lots of software that will create a "connection" object and re-use that with TCP reconnect handling. In practice, that means the DNS resolution happens when the connection is recreated but not necessarily when the TCP connection reconnects due to timeout/failure. I've also seen some issues with long lived connections (where the connection greatly outlives the TTL). Long lived connections aren't necessarily a DNS TTL problem but they mean DNS load balancing/redirection don't always work how you expect. That said, the solution is usually to just fix the issue in the software and not ignore DNS TTLs. As counter examples, AWS ALBs and Kubernetes service discovery both rely on short TTLs with fairly good success.