DNS response data gives you a network security edge
Before getting into DNS response data, let’s talk about everyday life: What if you asked a question and received nothing in response?
As in, “Hey John, can I get you something from the café?” Or, “What time does that meeting start?” And in return you get… total silence.
How useful would that be? Sure, there’s some value in knowing what your question was, but the answer is the most important part. You can’t move forward without it.
In the realm of DNS, we have traditionally cared just about the question section. Information about a DNS lookup was enough. But logging a queried domain only tells a fraction of the story.
With BlueCat, we’ve changed the paradigm by logging DNS queries and responses—moving to the answer section. In doing so, we’re uncovering a wealth of information about what’s happening on your networks.
In this post, we’ll touch on DNS inner workings and remind ourselves how we get response data. Next, we’ll explore why those query responses are so valuable. And finally, we’ll look at how using response data with BlueCat can boost your network security.
What is DNS response data?
Quick reminder: DNS, or domain name system, is the phone book of the internet. DNS protocol translates domain names that humans easily remember, like bluecatnetworks.com, into IP addresses, which are the language of the internet.
DNS operates whether it’s an IPv4 address, like 184.108.40.206, or a more complex IPv6 address, like 2002:db8::8a3f:362:7897. It allows computers, servers, and other networked devices, each with their unique IP addresses, to talk to each other. And it gets users to the website they’re looking for.
Exploring further, let’s look at one of the most common DNS query types, a recursive query.
When your computer or device—also known as your DNS client—makes a DNS query, a DNS resolver receives and logs the question. It then accesses DNS records, also called address records, that are hosted on a DNS name server, also sometimes called an authoritative name server. The resolver searches for the IP address it needs from among the records.
Then, it sends the response, along with a response code, back to your computer. That’s your response data.
We should note that, in large enterprises, this activity can happen over handfuls or even several dozen load-balancing distributed servers.
Why DNS response data matters
Response packets and contextual information show us what’s actually going on, giving us the power to apply some intelligence.
Your DNS data is a repository of network security gold.
Suppose a hacker infiltrates your network and redirects everybody who goes to bluecatnetworks.com to their phishing site. If you’re only logging users’ queries, everything would appear to be perfectly fine. There would be no way to identify that the answer is pointing users to a malicious site.
Only the response packets and contextual information show us what’s actually going on, giving us the power to apply some intelligence to that process.
Asking better questions
By incorporating response data into our workflow, we can ask better questions to conduct a more thorough forensic analysis. For example:
- Where is that DNS query resolving to?
- What is the reputation of the IP that the DNS query resolves to?
- Why does the response not match the query data?
- Who is telling us that this the correct answer?
- What do the query types and message formats tell us about intent?
In everyday terms, when I ask for directions, does the answer lead me to the right spot, or is it leading me to a dangerous area? Instead of directing the query to a good IP address, we discover that it’s being sent to an IP address we don’t recognize. Ok, then let’s investigate what DNS server answered.
It is increasingly clear that responses may be more valuable than questions.
Identifying compromised hosts
According to Cisco, 91 percent of malware uses DNS in attacks. Shady top-level domains are often used to disseminate spam or malware. Furthermore, there are targeted and sophisticated attacks used to extract credentials or implant malware like DNS tunneling, DNS poisoning, and DNS hijacking.
Let’s take a look at the latter attack type as an example of how response data can be used to thwart it.
In the example DNS hijacking below, a bad actor compromises your domain registrar account and modifies the A record of your domain. The record will point from your IP address to an IP address that they control, redirecting users to that same bad IP address every time. It’s easy and quick for a hacker to set up.
DNS response data is a critical key to detecting this type of attack.
On the left, you can see that, prior to the domain registrar account being compromised, mydomain.com was resolving to the IP address 220.127.116.11. This normal activity would show in your response data.
On the right, once the hacker has modified the A record to point to 18.104.22.168 instead, how would you know? It would be very difficult to detect this change without seeing DNS response data here as well.
When we arm network defenders with DNS response data, they can identify which hosts in their network visited the compromised domain when it was resolving to 22.214.171.124. With that information, they can know which hosts to check for further signs of malicious activity.
The benefit of DNS response data for network security
We can’t ignore the prospect of DNS as a threat vector.
If hackers are able to mask their scheme by looking like a good address, blocking answers—not questions—becomes extremely important. In cases like these, the question may not be malicious. But the answer is.
Looking at response data as a way to detect malicious activity in your DNS zone seems like a no-brainer, yet it is surprisingly rare. Until recently, most enterprises were only blocking bad DNS questions, while ignoring response data completely.
Logging queries and responses
With BlueCat’s platform, both DNS query messages and responses are logged together at every service point. As a result, you get a complete picture of the DNS activity on your network.
BlueCat’s platform also gives you the ability to set policies. And with response data, admins can create policies that are more informed and precise. You can monitor, set alerts for, or entirely block specific DNS servers with bad reputations.
For added protection, you can also send your DNS logs to a network Security Information and Event Management (SIEM) tool. Splunk, for example, integrates seamlessly with BlueCat. You can set an alert for this kind of anomaly with a SIEM.
Learn more about Intelligent Security from BlueCat.
Five network pros’ manual error horror stories
Members of BlueCat’s Network VIP community detail the errors they committed, the resulting fallout, and what important lessons they learned.
10 best Ansible modules for infrastructure as code
10 (plus a bonus) Ansible automation modules that anyone—from a beginner to a power user—can leverage to transform their network infrastructure to code.
Cloud Webinar Series: Part 3
Manage overlapping cloud networks like a boss.
NSA and CISA: Protective DNS key to network defense
U.S. cyber agencies now point to protective DNS as a defense strategy, confirming what BlueCat already knew: DNS is critical to detecting network threats.