[geofft]

I could believe that caching "is it localhost / RFC 1918 space or not" for a tab would have a sufficiently low false-positive and false-negative rate to be worth doing. It would still break the average business user who has an email half-written in OWA via an RFC-1918 address, puts their laptop to sleep, and goes home and expects OWA to still work over the public internet, but maybe OWA can figure out a solution there like local storage + document.reload(). It won't solve all the problems but it'll solve many of them.

I think caching all DNS resolutions is going to make a lot of cloud-native websites very sad (e.g., I'd imagine something like Slack would break quickly), and also cause poor performance because you don't get the benefit of a CDN's DNS server telling you that other servers are closer now. A lot of people have long-running tabs.

[kodablah]

I don't mind breaking legitimate uses rebinding here. I'm not familiar w/ how OWA changes IPs from private-network to public-network, but I'd say using DNS is the wrong approach. And Chrome can probably detect DNS server change and then evict its known cache anyways. Yeah, a first step is probably just localhost/private-IP specific.

[geofft]

It's just that OWA is a web app that is often configured to be accessible on the internal network via an internal IP, and on the external network via an external IP (so you can get webmail even if you're not in the office), but it's the same app.

I certainly don't think it's worth supporting this from first principles - i.e., had the web been designed the way you suggest from day one, that would have been great - but it's got a very large deployment, and "Chrome silently loses your Outlook emails because of a security issue in video games and a BitTorrent client" is a good way to get Chrome removed from enterprises, and other browsers to decide not to ship the same fix....