Of course, regardless of the target, the mechanism behind the attack remains exactly the same.
Generally speaking, you'd notice a nonsense name attack when your recursive name server starts running out of recursive query slots, as evidenced by the syslog message earlier. These messages provide the IP addresses of the queriers denied access by the lack of slots.
First, ask yourself whether the IP addresses in the messages are addresses your name server should be serving. If not, you may be able to simply configure your name server with an access control list to restrict queries to authorized queriers. If the malicious queries are coming from legitimate IP addresses, clearly you'll need to use another mechanism.
One possibility is to use BIND's very handy Response Policy Zones feature to temporarily prevent your name server from sending queries for the troublesome zone. An RPZ rule to prevent your name server from looking up foo.example domain names could be as simple as:
*.foo.example.your.rpz.zone. IN CNAME .
You also need to set an option called qname-wait-recurse to no (for more information on these options click here). This will cause your name server to respond to queries for domain names in foo.example with NXDOMAIN without querying the foo.example name servers.
If your recursive name servers don't run BIND 9.10 yet (the first version of BIND that supports this option), or don't run BIND at all, you can still temporarily set up an empty foo.example zone to prevent your name server from trying to look up data in the misbehaving one. The zone data file would be minimal:
@ IN SOA ns1 root 2015010700 1h 15m 30d 10m
IN NS ns1
Configure your recursive name server as authoritative for the zone — an exercise left to the reader — and it'll simply answer most queries for foo.example domain names with NXDOMAIN (except queries for foo.example's SOA or NS record, obviously).
Just remember that the RPZ rules or zone configuration is temporary. After the attack ends, you'll need to remove them to be able to resolve domain names in the zone again.
The good folks at the Internet Systems Consortium, who develop the BIND name server, are also working on new mechanisms to address the issue more subtly, by introducing two new configuration options: fetches-per-server and fetches-per-zone.
Fetches-per-server places a limit on the number of concurrent queries a recursive name server can have outstanding to a single authoritative name server. The imposed limit is actually dynamic, and adjusted downward based on timeouts experienced when querying the authoritative name server. Fetches-per-zone places a limit on the number of concurrent queries a recursive name server can have outstanding for a single zone.
Between these two features, administrators should be able to reduce the chance that their BIND name servers will be victims — inadvertent or not — of nonsense name DDoS attacks like these.
Sign up for MIS Asia eNewsletters.