Hi, thanks for the report.  If possible could you provide a netlog?  

Instructions are here:  https://dev.chromium.org/for-testers/providing-network-details

Sounds like we may have keep-alive connections to the old domain.  We keep sockets open after network requests and reuse them, without a DNS lookup.  If unused, we close them after 5 minutes (Though the timer resets of the connections are reused, so we can keep them around indefinitely).  If the server can no longer service requests when there's a DNS change, it should close those sockets.

If you're changing DNS mappings for local testing purposes, I believe flushing the cache will close those sockets (As they do implicitly have DNS addresses cached).  You can also do testing with incognito windows (When the last one is closed, all incognito network connections should be closed, and the DNS cache (Which is shared with non-incognito) will be cleared.

mmenke, 
This is likely a large problem for us (I work with Alex), especially since we use our frontend SPA app to access a backend API for data retrieval. Since data retrieval would happen more often than every 5 min, that could mean that we would indefinetely point to our old infrastructure after a DR switch.  Do you know if this is something that was recently introduced? Firefox seems to handle it better, but IE also has a similar issue. 

This isn't a new behavior.  We've had this behavior for at least 6 years, probably longer.  DNS lookup is part of establishing a connection.  If we already have a connection, we don't do a DNS lookup.

You've only started experiencing the problem recently?  I'm not aware of any change on our side that would have affected behavior here.

Due to the performance implications (And the fact we haven't had a whole lot of problems here, and the fact a lot of home routers are easily DoSed with DNS requests), I don't think we want to change behavior here, unless there's some sort of specific recent regression in our behavior.

Also note that there is necessary some time where the old DNS address will be used when you change DNS addresses (Window caches all addresses for 30 minutes, regardless of TTL, I think?), which makes it difficult to rely on the timing of DNS changes.

I think that very old issue too, I found related issues with creation date more then 5 years ago.

Can we somehow tell to Chrome not to keep that connections? Could we use "Connection: close" HTTP Header for this?

Thank you for providing more feedback. Adding requester "ckrasic@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The Connection: close header may not completely fix this - we may have some left over unused connections in the socket pool, though those will only stick around for 10 seconds.

Another option would be to modify the hosts file instead of modifying the behavior of the DNS server.  We flush socket pools when we detect a change in network configuration, which (should) include hosts file changes.

Going to go ahead and mark this bug as WontFix, but happy to talk more on this bug about workarounds.

Thank you for advices.
We will try mentioned workarounds and will share results.

Our related scenario - For additional resiliency, if an IP becomes unavailable, DNS server automatically changes the A record to point to a secondary IP. (user typed domain is a CNAME with 15min TTL pointing to A record with 30 second TTL)

Firefox (Win/OSX), Safari (OSX), and Chrome (OSX) pick up the new IP within 30 seconds and experience next to no downtime.

IE11 stubbornly sticks to a 25 minute browser DNS cache, showing a Page not available error - however - opening a new tab and entering the domain gets new IP and loads the page.

Chrome in windows refuses to do anything but continue to load the site from local cache even with hard reload, new tab, waiting 35 minutes, etc (even with all expiry and no-cache headers on the page)

Incognito does use new IP but that has no effect on original tab nor can we expect customers to close the browser or use Incognito when the site fails over.

It seems Chrome for Windows should be consistent with Chrome for OSX behavior.

evanhood:  The underlying cause of that sounds unrelated to this issue.  This one is due to keeping idle sockets around, and not doing DNS lookups before reusing them.

We don't keep idle sockets around for 35 minutes (And if you use an idle socket and cancel it, we close the socket, with the possible exception of QUIC/H2).

Please file a new bug, with a net-export log attached, thanks!  (Instructions: https://dev.chromium.org/for-testers/providing-network-details)