[dns-operations] Massive DNS poisoning attacks in Brazil

[Vernon Schryver]

> From: David Conrad <drc at virtualized.org>

> > Any popular scheme that works around DNS, HTTP, ssh, etc.
> > man-in-the-middle attacks that become popular will be blocked,
> > proxied, or hijacked unless most users normally use tools that
> > detect and refuse to work with men in the middle.
>
> 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.
(Never mind corrupt DNS registrars or registries attacking DNSSEC.)

>                                                   My impression
> is that the majority of the issues in getting EDNS0-requiring
> protocols to work are due to ignorance, e.g., valid DNS responses
> are always UDP<512bytes or valid DNS types are {A,MX,SOA,NS,PTR,TXT}.
> If this is true, than egregious hack workarounds like using HTTP/S
> as a transport will solve most of the problem (not that I think
> this is the best solution).

If DNS/TLS/HTTP became popular, then the same actors that filter
DNS/UDP for >512 bytes or less common types would have the same
motives to do the same to DNS/TLS/HTTP.  To filter >512 bytes or
RRSIG or TLSA records, you must be looking at the bits.  Breaking
DNS is not accidental, not even with NAT.  The reasons that require
or allow you to do whatever you're doing to DNS/UDP/IP would apply
to DNS/TLS/HTTP if DNS/TLS/HTTP were popular.

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.


 ....

} From: Andrew Sullivan <ajs at anvilwalrusden.com>

} I see.  So your model is that the application asks for a TLSA record,
} and if it gets one then it can infer that the record also passed
} validation?  

}             How can the application be sure the resolver is
} DNSSEC-aware?

The important answer is the same way the application can be sure
the resolver is not some other kind of malware.

The trivial answer is in the API used by the application to get TLSA
records.  For gethostbyname(), HOST_NOT_FOUND in h_herrno is plenty
good enough for the SERVFAIL that comes from failure to validate A or
AAAA records.  For other record types, you need either the record set,
the empty record set, or a half bit of a failure flag.  Applications
do not now and will never care whether a failure is due to any of the
myriad of reasons for getting a SERVFAIL or REFUSED DNS DNS response,
including the new reason of failure to validate.


Vernon Schryver    vjs at rhyolite.com