SoylentNews is people
SoylentNews
Sysadmins are making mistakes configuring and managing DNSSec, and it's leaving systems that should be secure open to exploitation in DNS reflection attacks.
That's the conclusion of Neustar, in a study released here and which found that of more than 1,300 DNSSec-protected domains tested 80 per cent could be used in an attack.
The domains in question had DNSSec deployed, and also responded to the DNS “ANY” query. The ANY request asks the responder to provide all information about a domain – the MX (mail server) records, IP addresses, and so on. An ANY request therefore returns a lot more information than a simple request for the domain's IP address.
[...] Neustar reckons on average, the poorly-configured DNSSec servers could amplify an attacker's traffic by 28.9 times; they turned an 80 byte query into a 2,313 response; and the biggest response they received from one of the protected servers was 17,377 bytes, 217 times the size of the query.
Unfortunately, all of this isn't a bug, it's a feature: even with DNSSec, the purpose of the system is to answer queries – so it's not a matter of applying a patch; it's about taking care of systems.
(Score: 2) by Fnord666 on Thursday August 18 2016, @09:02PM
So assuming that the outbound filtering will never be a thing for the whole net, what would the downside(s) of having a DNS2 based on a TCP connection be?
The overhead of setting up a full TCP connection is a lot for what are otherwise very lightweight protocols. It also consumes a lot of resources on the server waiting to see if someone is going to reuse the socket, etc.
(Score: 2) by maxwell demon on Friday August 19 2016, @05:08PM
What about having a data size limit for UDP responses, and if the response would be larger, send a "retry by TCP" error message instead?
The Tao of math: The numbers you can count are not the real numbers.