Running a DNSSec responder? Make sure it doesn't help the black hats
Systems can be roped into amplification attacks
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.
And DNSSec returns bigger responses anyhow. As the Neustar report notes: “With digital hashed signatures and complex key exchanges, DNSSEC records are considerably larger than standard DNS”.
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.
The test was conducted using recursive servers that weren't under Neustar's control.
As well as being a denial-of-service vector, if a domain is paying for DNS by the query, the company says this kind of attack can drive up their costs.
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.
Hence the best advice is for operators to filter out the ANY request, and put abuse-detection mechanisms in place. ®