[dns-operations] Hijacking DNS traffic (Was: Re: new public DNS service: 188.8.131.52)
mlm at pixelgate.net
Tue Nov 21 03:13:01 UTC 2017
Noel Butler wrote:
>So yes, there are non commercial reasons for doing that stuff.
Rather you had effectively the same reason, and a commercial one: a good
experience for your users. Google needed people to get answers fast and
without much faking (they take it further, yay!) so that other people
can't replace their ads and services. You needed people to get faster
answers so they wouldn't call support (for "slowness"), and I bet you
weren't against eliminating faked answers, at least those that would
take your users to their old provider's search/help (and probably
Google uses their name and some FUD, some of which is certainly true, to
convince people to use their service. You used your power of position
as the funnel though which the requests would flow. Neither is very
wonderful but each certainly seems defensible, yours not alone for "my
network, my rules".
DNSSEC exists to prove the answers we get, who gives a flying fart where
they came from so long as they validate. Alas DNSSEC is far from
universal, and some people do care or do at times.
But even DNSSEC presumes we run our own resolvers or have stub-resolver
Running a local resolver used to be de rigueur but it is no longer done
and mostly speed is the issue there, keeping folks using a larger
entity's service -- memory and cpu are now usually non-issues.
There's not much security between the stub and a non-local resolver (or
even a local one!), providing proof that the answers were/weren't
spoofed (by your ISP or enterprise, much less malware) or where it is
expected and condoned.
More information about the dns-operations