In today's connected world, the Domain Name System (DNS) acts as an essential component to make the internet work seamlessly. However, misconfigurations in DNS servers, especially ones running ISC BIND before version 9.4.1-P1, can open doors to serious security issues like Denial of Service (DoS) attacks. One such vulnerability goes by the name CVE-2006-0987.

In this post, we'll break down this vulnerability in simple terms, show you the risks with some code snippets, and provide tips and resources to help you secure your DNS servers. Let’s dive in!

What is CVE-2006-0987?

CVE-2006-0987 refers to a vulnerability in the default setup of ISC BIND (prior to 9.4.1-P1) when it's running as a caching name server. In this configuration, BIND allows *any* remote client to ask it to resolve DNS queries—this is called an "open recursive resolver."

But the problem doesn't end there. The server would also provide "additional delegation information," which is basically extra data that helps attackers even more.

Attackers can send fake (spoofed) requests to your server, using someone else's IP as the sender.

- Your BIND server unwittingly replies to the victim, not just with an answer, but with lots of additional data, magnifying the traffic.

This leads to "amplification" – a small request causes a big response.

- If repeated quickly, it can overwhelm your server or flood the target with unwanted traffic, causing a *Denial of Service* or participating in a DDoS attack.

Step-by-Step: How the Attack Works

1. The attacker sends a DNS query to your open BIND server, but spoofs the source IP to be their intended victim.
2. Your DNS server receives the query, processes it, and replies with a large DNS response to the victim.
3. Because DNS responses can be much larger than the original requests, the victim gets flooded (amplified traffic).
4. If coordinated with many bots or sent to many open resolvers, this turns into a significant DDoS attack.

Simple Code Snippet: Example DNS Query Amplification

Here's a simplified snippet (using Python and scapy) that demonstrates crafting a DNS request with a spoofed source IP:

from scapy.all import *

# Target open resolver (the vulnerable BIND server)
resolver_ip = "192..2.1"

# Victim IP that we want to flood
victim_ip = "203..113.10"

# Construct DNS query
dns_query = IP(src=victim_ip, dst=resolver_ip)/UDP(sport=12345, dport=53)/DNS(rd=1, qd=DNSQR(qname="ANY", qtype="ANY"))

# Send the spoofed packet
send(dns_query)

*Note: Never run this on real systems or the public internet! This is for educational purposes only.*

Real-World Impact

- Traffic Amplification: BIND’s open resolver can multiply traffic by 10x, 20x, or even more, depending on the query type.
- Unwitting Participation in Attacks: Your server could be used in large DDoS campaigns without your knowledge.

How to Fix & Protect Your BIND Server

The main solution is to restrict your server from acting as an open resolver. Here are practical steps:

Update Your BIND

Upgrade to BIND 9.4.1-P1 or later, as newer versions adjust the default configuration and fix this vulnerability.

Edit your named.conf to restrict recursion to trusted clients (like your internal network)

options {
    recursion yes;
    allow-recursion { 127...1; 192.168../24; }; // Only allow trusted networks
    allow-query { 127...1; 192.168../24; }; // Only allow local queries
};

*Restart BIND after changes:*

sudo systemctl restart named

*Now, only your local network can use your resolver. Everyone else is blocked from recursive queries.*

Additional Resources

- CVE-2006-0987 at NVD
- ISC BIND Security Advisory (archived)
- US-CERT Alert TA13-088A: DNS Amplification Attacks
- How to Test for Open DNS Recursion

Conclusion

CVE-2006-0987 underscores why default configurations must be reviewed and restricted, especially for critical internet infrastructure like DNS servers. Take a moment to check your BIND server setup, especially if it's an older version. Make sure you're not an unwitting accomplice in someone else's DDoS attack!

Stay safe, update your software, and always keep your DNS servers locked down.

*This exclusive guide was written for anyone managing DNS infrastructure or learning about network security.*

Timeline

Published on: 03/03/2006 11:02:00 UTC
Last modified on: 04/03/2025 01:03:51 UTC