CSSMTP needs to redrive DNS lookup other than at startup

Current CSSMTP functionality only resolves DNS names to IP addresses on product startup. PMRs and questions have led to responses that indicate the implementation ignores the DNS time to live (TTL) parameters and, quoting from the PMR, "... eliminates the extra overhead of doing DNS
queries that result in the same repetitive answer. The DNS databases are
not modified often and you can use or automate sending the REFRESHIPLIST
command to get changes when you want..."
This extremely outdated design thinking and leads to outages that would be avoided if a DNS lookup was driven so they are exchanging a few cycles for availability.
While it may be true that a particular entry in the DNS database is not modified often, the state of the art in load balancing DNS is to have several IP addresses behind a DNS entry and to distribute those with short TTL values. This allows the distribution of workload to different servers, different data centers, possibly different countries where an network load balancer that provides a single IP address for a pool of servers behind it is limited and can itself become a bottleneck.

The PMR shows messages being logged indicating that an IP level connection is succeeding but the response indicates a service is down and disconnects. The CSSMTP should re drive a DNS lookup and it would get a new address to attempt to connect to. Instead it continues to go after the exact same IP address for 90 minutes or more with the concept that we still have IP connectivity.

I have 3 suggestions:
1) TTL should not just be ignored. If you want to maintain the default design of not re-driving DNS than give the customer a parameter customer to either use TTL or not use TTL, or maybe even configure to redo the DNS on a customer specified interval, say 15 minutes.
2) Even if the design stays as is and you don't get us an option, the product should be intelligent enough to see it has an error and make an intelligent response. You are seeing an error that says a service is not available, why keep trying, why not re-resolve the DNS? The answer that IP is available is not the right answer.
3) The answer that the customer should automate a response to the problem is never the correct response from IBM, however, if you are generating an error in the CSSMTP log there should be a zOS message that we can see and automate on. There is nothing we can do to intelligently automate if we don't get an indication of a problem.