Not every DNS traffic spike is a DDoS attack 


You’re a network administrator going about your normal business. Suddenly, you’re seeing a huge spike in inbound traffic to your website, your application or your web service. You immediately shift resources around to cope with the changing pattern, using automated traffic steering to shed load away from overburdened servers. After the immediate danger has passed, your boss asks: what just happened? 

Is it really a DDoS attack? 

It’s tempting to raise a false alarm in these situations. Distributed denial of service (DDoS) attacks are an increasingly common issue, with both the number and scale of attacks rising significantly every year. Plenty of network administrators will say “must have been a DDoS attack of some kind” when there’s a notable increase in traffic, even if they don’t have any direct evidence to support the claim. 

Proving or disproving that a DDoS attack happened can be a thorny issue for network administrators and even security teams.  

If you’re using a basic pre-packaged registrar Domain Name System (DNS) offering, you probably don’t have access to DNS traffic data at all. If you’re using a premium DNS service, the data might be there. Most authoritative DNS providers have some kind of observability option. At the same time, getting it in the right format (raw logs, SIEM integration, pre-built analysis) and the right level of granularity may be an issue

What’s actually causing DNS traffic spikes 

We analyze a lot of DNS traffic information with IBM® NS1 Connect® DNS Insights, an optional add-on to IBM NS1 Connect Managed DNS.  

DNS Insights captures a wide range of data points directly from NS1 Connect’s global infrastructure, which we then make available to customers through pre-built dashboards and targeted data feeds. 

As we review these data sets with customers, we found that relatively few of the spikes in overall traffic or error-related responses like NXDOMAIN, SERVFAIL or REFUSED are related to DDoS attack activity. Most spikes in traffic are instead caused by misconfiguration. Normally, you’ll see error codes resulting from around 2-5% of total DNS queries. However, in some extreme cases, we’ve seen instances where over 60% of a company’s traffic volume results in an NXDOMAIN response.  

Here are a few examples of what we’ve seen and heard from DNS Insights users: 

“We’re being DDoS-ed by our own equipment” 

A company with over 90,000 remote workers was experiencing an extraordinarily high percentage of NXDOMAIN responses. This was a long-standing pattern, but one shrouded in mystery as the network team lacked sufficient data to figure out the root cause. 

Once they delved into the data collected by DNS Insights, it became clear that the NXDOMAIN responses were coming from the company’s own Active Directory zones. The geographic pattern of DNS queries provided further proof that the company’s “follow the sun” operating model was replicated in the pattern of NXDOMAIN responses.  

At a basic level, these misconfigurations were impacting network performance and capacity. Digging further into the data, they found a more serious security issue as well: Active Directory records were being exposed to the internet through attempted Dynamic DNS updates. DNS Insights provided the missing link the network team needed to correct these entries and plug a serious hole in their network defenses. 

“I’ve been wanting to look into these theories for years” 

A company that had acquired multiple domains and web properties over the years through M&A activity routinely saw notable increases in NXDOMAIN traffic. They assumed that these were dictionary attacks against moribund domains, but the limited data they had access to could neither confirm nor deny that this was the case. 

With DNS Insights, the company finally pulled back the curtain on the DNS traffic patterns that produced such anomalous results. They discovered that some of the redirects they had put in place for purchased web properties weren’t configured correctly, resulting in misdirected traffic and even the exposure of some internal zone information.  

By looking at the source of NXDOMAIN traffic in DNS Insights, the company was also able to identify a Columbia University computer science course as the source of elevated traffic to some legacy domains. What may have appeared to be a DDoS attack was a group of students and professors probing a domain as part of a standard exercise. 

“Which IP has been causing those high QPS records?” 

A company experienced periodic spikes in query traffic but couldn’t identify the root cause. They assumed it was a DDoS attack of some kind but had no data to support their theory. 

Looking at the data in DNS Insights, it turned out that internal domains—not external actors—were behind these bursts of increased query volume. A misconfiguration was routing internal users to domains intended for external customers. 

Using the data captured by DNS Insights, the team was able to rule out DDoS attacks as the cause and address the actual problem by correcting the internal routing issue.  

DNS data identifies root causes 

In all these cases, the heightened query traffic that network teams initially attributed to a DDoS attack turned out to be a misconfiguration or internal routing error. Only after looking deeper into DNS data were the network teams able to pinpoint the root cause of perplexing traffic patterns and anomalous activity. 

At NS1, we’ve always known that DNS is a critical lever that helps network teams improve performance, add resilience and lower operating costs. The granular, detailed data that comes from DNS Insights is a valuable guide that connects the dots between traffic patterns and root causes. Plenty of companies provide raw DNS logs, but NS1 is taking it a step further. DNS Insights processes and analyzes data for you, lowering the effort and time needed to troubleshoot your network. 

Learn more about the information contained in DNS Insights

Was this article helpful?

YesNo



Source link

Leave a Reply

Your email address will not be published.