A new kind of DDoS threat: The "Nonsense Name" attack

It can wreak havoc on recursive and authoritative name servers alike

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.

Join the CSO newsletter!

Error: Please check your email address.

Tags network securitysecurityDNS

More about InfobloxZones

Show Comments

Featured Whitepapers

Editor's Recommendations

Solution Centres

Stories by By Cricket Liu, Chief Infrastructure Officer, Infoblox

Latest Videos

  • 150x50

    CSO Webinar: The Human Factor - Your people are your biggest security weakness

    ​Speakers: David Lacey, Researcher and former CISO Royal Mail David Turner - Global Risk Management Expert Mark Guntrip - Group Manager, Email Protection, Proofpoint

    Play Video

  • 150x50

    CSO Webinar: Current ransomware defences are failing – but machine learning can drive a more proactive solution

    Speakers • Ty Miller, Director, Threat Intelligence • Mark Gregory, Leader, Network Engineering Research Group, RMIT • Jeff Lanza, Retired FBI Agent (USA) • Andy Solterbeck, VP Asia Pacific, Cylance • David Braue, CSO MC/Moderator What to expect: ​Hear from industry experts on the local and global ransomware threat landscape. Explore a new approach to dealing with ransomware using machine-learning techniques and by thinking about the problem in a fundamentally different way. Apply techniques for gathering insight into ransomware behaviour and find out what elements must go into a truly effective ransomware defence. Get a first-hand look at how ransomware actually works in practice, and how machine-learning techniques can pick up on its activities long before your employees do.

    Play Video

  • 150x50

    CSO Webinar: Get real about metadata to avoid a false sense of security

    Speakers: • Anthony Caruana – CSO MC and moderator • Ian Farquhar, Worldwide Virtual Security Team Lead, Gigamon • John Lindsay, Former CTO, iiNet • Skeeve Stevens, Futurist, Future Sumo • David Vaile - Vice chair of APF, Co-Convenor of the Cyberspace Law And Policy Community, UNSW Law Faculty This webinar covers: - A 101 on metadata - what it is and how to use it - Insight into a typical attack, what happens and what we would find when looking into the metadata - How to collect metadata, use this to detect attacks and get greater insight into how you can use this to protect your organisation - Learn how much raw data and metadata to retain and how long for - Get a reality check on how you're using your metadata and if this is enough to secure your organisation

    Play Video

  • 150x50

    CSO Webinar: How banking trojans work and how you can stop them

    CSO Webinar: How banking trojans work and how you can stop them Featuring: • John Baird, Director of Global Technology Production, Deutsche Bank • Samantha Macleod, GM Cyber Security, ME Bank • Sherrod DeGrippo, Director of Emerging Threats, Proofpoint (USA)

    Play Video

  • 150x50

    IDG Live Webinar:The right collaboration strategy will help your business take flight

    Speakers - Mike Harris, Engineering Services Manager, Jetstar - Christopher Johnson, IT Director APAC, 20th Century Fox - Brent Maxwell, Director of Information Systems, THE ICONIC - IDG MC/Moderator Anthony Caruana

    Play Video

More videos

Blog Posts

Market Place