[dns-operations] Massive DNS poisoning attacks in Brazil

David Conrad drc at virtualized.org
Wed Oct 3 18:16:39 UTC 2012


Vernon,

On Oct 3, 2012, at 8:57 AM, Vernon Schryver <vjs at rhyolite.com> wrote:
>> You're assuming the MITM attacks are intentional. 
> No, I assume only either that the men in the middle will back off if
> they irritate enough users or that they can be detected.

They can only back off if they're aware they are doing it.

> (Never mind corrupt DNS registrars or registries attacking DNSSEC.)

Not corrupt, just inept. Which is, of course, a much more significant threat today than anything DNSSEC can protect against, but that's a rant for a different thread.

> Breaking DNS is not accidental, not even with NAT.

Sure it is. CPE/firewall vendors have a long history of implementing the absolute minimum they can get away with that still sort of works (which, from a business perspective). In the past, DNS UDP<512 (for CPE) and limited types (for firewalls) sort of worked.  Then those evil greedy DNSEXT bastards went and modified the protocol, thereby breaking simplistic implementation assumptions. However, there is a lot of CPE/firewalls out there that needs to be upgraded.  Hence suggestions like Paul's of egregious hacks like DNS/TLS/HTTP.

> On the other hand, if many user computers have validating stubs that
> compute SERVFAIL for broken DNSSEC and so make gethostbyname() in
> applications fail, then many users will yell at hotel concierges for
> $15/day WiFi that doesn't work and use LTE instead of paying $15/day.
> Many hotels would change and allow EDNS0 after the sign-on.  Employers
> would either do the same or point to conditions of employement.  State
> actors would either do the same or send whiners to gulags.

I want to live in your world.  In my world, the vast majority of users would simply turn off the features that caused their laptops/phones/etc. to not work and would rarely (if ever) complain to their service provider (even if they knew what to complain about).

Regards,
-drc




More information about the dns-operations mailing list