5 ms·

Could you solve this by just routing 8.8.8.8 to your own DNS inside your network?

by Legogris 8y ago

alias_neo 8y ago
This is how I solved it. Someone above says an update prevented this somehow, though.
- jrockway 8y ago
  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.
  - alias_neo 8y ago
    I also don't see a way they could do it, but then I only know just enough to be dangerous, as they say.
  - mthoms 8y ago
    >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.
    - cwkoss 8y ago
      Clever, kind of reminds me of how map makers insert fake 'trap streets' to prove copyright theft.
  - pixl97 8y ago
    >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.
apostacy 8y ago
How is that simple? I know a lot of developers that couldn't easily do that.
- Spivak 8y ago
  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.

Could you solve this by just routing 8.8.8.8 to your own DNS inside your network?

alias_neo 8y ago

This is how I solved it. Someone above says an update prevented this somehow, though.

jrockway 8y ago
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.
- alias_neo 8y ago
  I also don't see a way they could do it, but then I only know just enough to be dangerous, as they say.
- mthoms 8y ago
  >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.
  - cwkoss 8y ago
    Clever, kind of reminds me of how map makers insert fake 'trap streets' to prove copyright theft.
- pixl97 8y ago
  >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.

apostacy 8y ago

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

Spivak 8y ago
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.