UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36

Example URL:
N/A

Steps to reproduce the problem:
1. Force a HTTPS enabled site to have trouble with the SSL handshake.
2. Load that page in chrome.
3. Make a DNS change to point that domain to a new server (where the SSL handshake succeeds)
4. Try to refresh the page multiple times and still get the wrong server.

What is the expected behavior?
In my opinion, it'd be great if chrome could detect connection problems and flush the DNS cache as long as connection issues remain. That way, if DNS changes to fix the issue, it will be resolved ASAP for the user.

What went wrong?
This afternoon Amazon Cloudfront had a failure that resulted in our cookieless asset domain to start refusing SSL connections. The Amazon team promptly removed these nodes from DNS, but our users had a prolonged delay since chrome was holding on to the old IP address.

If the feature suggested above were to be implemented, this downtime would have been reduced.

Did this work before? N/A 

Chrome version: 58.0.3029.110  Channel: stable
OS Version: OS X 10.12.5
Flash Version: 

This is more of a feature request than a bug.