I don't see why a browser would "just trust" that because it is a private IP - the TLD is what matters. When you hit an internet TLD you should play by internet rules, when you hit a LAN TLD (or IP range) you could play by LAN rules. The judgement being decided by where the domain in the http request, not the final destination of any DNS lookups
If you directly went to 10.254.127.1, or some-domain.lan, that should validate differently to going to accounts.google.com
The exact issue I explained - for you it would be a local IP, even if the actual destination is anywhere else => no checks.
> TLD is what matters
bankofamerica.com.lan
It can't be used in the wild, compared to bankofamerica.com.security.itdept.xyz in the email, but it opens a way for a directed attacks to be way easier. Especially considering the awful security record of most 'SOHO' routers out there.
Sure, you can respond with evil bit set to zero for IoT devices...
Just to be clear I mean if the browser bar says accounts.google.com, you get the internet "level" validation. Regardless if the IP resolved by malicious dns is 10.0.1.1
This would be an extension of the recent HSTS preload list trend of associating a particular TLD (e.g. .dev) with a particular mechanism, and would not affect other tlds than (say) .lan or ip ranges
If you directly went to 10.254.127.1, or some-domain.lan, that should validate differently to going to accounts.google.com