How is that simple? I know a lot of developers that couldn't easily do that.

I wouldn't necessarily expect a developer to know how to manipulate network traffic. The OSI model extends a bit to humans as well. But any network engineer can add a DNAT rule.

This is how I solved it.

Someone above says an update prevented this somehow, though.

It seems unlikely to me that the DNS client has the sophistication to know that it's not Google's 8.8.8.8 that it's talking to. That would be a nightmare to maintain; the 8.8.8.8 team changes some implementation detail, and then all Google clients stop working (and are now unable to update because they refuse to resolve DNS names)? I doubt they implemented that because it's crazy.

>It seems unlikely to me that the DNS client has the sophistication to know that it's not Google's 8.8.8.8 that it's talking to

I don't know much about DNS but based on what I do know I would think this to be trivial(?). All you'd need to do is make a request for a domain that doesn't exist. Something like "is-this-google-dns-im-connecting-with.google" or <salted hash of current timestamp>.com. Google DNS could be coded to respond accordingly.

So no DNS response, or not the response you were expecting = not Google DNS.

Clever, kind of reminds me of how map makers insert fake 'trap streets' to prove copyright theft.

>It seems unlikely to me that the DNS client has the sophistication to know that it's not Google's 8.8.8.8 that it's talking to.

DNS over TLS and DNS over HTTPS will change that. Google has pushed encryption in all their other products, and is pushing these implementations so do not be surprised when their end user devices use it by default.

I also don't see a way they could do it, but then I only know just enough to be dangerous, as they say.