There’s a new species of Distributed Denial of Service (DDoS) attack targeting name servers, which could be called the “nonsense name” attack. It can wreak havoc on recursive and authoritative name servers alike, and some of our customers at Infoblox have fallen victim to it—but it’s not always clear whether they were actually the targets.

The “nonsense name” DDoS attack works like this:

-  An attacker chooses a zone to attack, say foo.example.

-  A botnet controlled by the attacker generates random domain names in the zone, with nonsense-first labels, such as asdfghjk.foo.example and zxcvbnm.foo.example.

-  The bots send many queries for those domain names to recursive name servers.

-  Those recursive name servers, in turn, send queries to foo.example’s authoritative name servers for those domain names.

-  The authoritative name servers send responses saying that the domain names in question don’t exist (in the DNS business, what’s called an NXDOMAIN response).

-  The recursive name servers relay that response to the original querier and cache the non-existence of the domain name.

-  Lather, rinse, repeat.

If the attacker can generate queries quickly enough, the aggregate query rate will overwhelm the foo.example name servers. That’s when the fun really starts:

-  The bots continue sending queries for the generated domain names to recursive name servers.

-  Now that the authoritative name servers have stopped responding, the recursive name servers take much longer to process each query. In the case of the BIND name server, the name server can wait 30 seconds and send dozens of (unanswered) queries before giving up.

-  This uses up recursive query slots on the recursive name server, which eventually runs out, denying additional recursive queries—some of them legitimate.

When this happens, a BIND name server sends a message like the following to syslog:

Jan 21 14:44:00 ns1 named[4242]: client 192.168.0.1#1110: no more recursive clients: quota reached

At that point, the name server will refuse additional recursive queries, denying service to clients.

Who’s the target?

In most cases, the organization running the authoritative name servers (in this example, those for foo.example) seems to bethe target. For example, some of the domain names in attacks we’ve seen are used by Chinese gambling sites. (Maybe someone is trying to exact revenge on the house for some tough losses?) However, the recursive name servers involved end up as collateral damage in the attack. Could they have actually been the targets?

We’ve seen some evidence of this. Some of the zones involved in attacks against our customers have mysteriously disappeared a day or two after the attack, indicating that they likely weren’t in active use (and in fact were probably registered in a “Domain Tasting” scheme). The attackers could have deliberately registered these zones with slow or unresponsive name servers, so that resolution of domain names in the zone would take as long as possible.

Of course, regardless of the target, the mechanism behind the attack remains exactly the same.

Mitigation

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.

Source: http://www.networkworld.com/article/2875970/network-security/a-new-kind-of-ddos-threat-the-nonsense-name-attack.html