How to remediate – DNS Server Recursive Query Cache Poisoning Weakness

1. Introduction

The DNS Server Recursive Query Cache Poisoning Weakness allows a remote attacker to query your name server for third-party names, potentially leading to cache poisoning attacks. This impacts confidentiality, integrity and availability of DNS resolution services. It typically affects internal name servers or publicly accessible resolvers that are not properly restricted. A successful attack can redirect users to malicious websites or disrupt network connectivity.

2. Technical Explanation

The vulnerability occurs when a DNS server allows recursive queries from unintended hosts. Attackers exploit this by sending crafted DNS requests, attempting to insert false records into the server’s cache. If successful, subsequent legitimate users querying for those domains will receive the attacker’s malicious information. The CVE associated with this issue is CVE-1999-0024.

• Root cause: Unrestricted recursive query access on the DNS server.
• Exploit mechanism: An attacker sends a crafted DNS request to resolve a domain they control, then modifies the response to include malicious records for legitimate domains. This is often done via UDP.
• Scope: BIND 8 and BIND 9 name servers are known to be affected when not configured correctly. Other name server software may also be vulnerable.

3. Detection and Assessment

• Quick checks: Use dig or nslookup to query for a third-party domain (e.g., www.nessus.org) and see if it resolves successfully when run from outside your network.
• Scanning: Nessus vulnerability scanner ID 10862 can detect this issue.
• Logs and evidence: Check DNS server logs for excessive recursive query requests originating from unexpected sources. Log file locations vary depending on the name server software used.

dig www.nessus.org @<your_dns_server_ip>

4. Solution / Remediation Steps

Restrict recursive queries to authorized hosts only. The following steps provide guidance for BIND 8 and BIND 9.

4.1 Preparation

• Stopping the DNS service may briefly interrupt name resolution. Plan accordingly. A roll back plan is to restore the backed-up named.conf file and restart the service.
• Changes require approval from network administrators.

4.2 Implementation

1. Step 1: Open your BIND configuration file (named.conf).
2. Step 2: For BIND 8, add the line ‘allow-recursion { ; };’ within the ‘options’ section. Replace ‘‘ with a space separated list of trusted IP addresses or networks.
3. Step 3: For BIND 9, define an ACL containing allowed IPs using the ‘acl’ command (e.g., ‘acl “trusted” { ; };’). Then add ‘allow-recursion { trusted; };’ within the ‘options’ section.
4. Step 4: Restart the DNS service to apply the changes.

4.3 Config or Code Example

Before

options {
  directory "/var/cache/bind";
};

After

options {
  directory "/var/cache/bind";
  allow-recursion { 192.168.1.0/24; };
};

4.4 Security Practices Relevant to This Vulnerability

• Least privilege: Restricting access to only necessary hosts minimizes the attack surface.
• Secure defaults: Avoid using default configurations that allow unrestricted recursive queries.

4.5 Automation (Optional)

Ansible can automate configuration changes. The following example shows how to update named.conf, but requires careful testing.

---
- hosts: dns_servers
  become: true
  tasks:
    - lineinfile:
        path: /etc/bind/named.conf
        regexp: '^options {'
        line: 'options {n  directory "/var/cache/bind";n  allow-recursion { 192.168.1.0/24; };' # Replace with your network
    - service: name bind restart

5. Verification / Validation

Confirm the fix by checking that recursive queries are now restricted to authorized hosts. Re-run the earlier detection method and verify it no longer resolves third party domains from outside your network.

• Post-fix check: Run dig www.nessus.org @<your_dns_server_ip> from an external host. The query should fail to resolve, indicating the restriction is working.
• Re-test: Repeat the quick check from Section 3. It should no longer be possible to resolve third party domains from outside your network.
• Smoke test: Verify that internal DNS resolution continues to function normally for authorized hosts.
• Monitoring: Monitor DNS server logs for failed recursive query attempts originating from unauthorized sources.

dig www.nessus.org @<your_dns_server_ip>

6. Preventive Measures and Monitoring

• Baselines: Implement a security baseline that enforces restricted recursive query access on all DNS servers.
• Pipelines: Integrate configuration checks into CI/CD pipelines to prevent accidental misconfiguration of DNS settings.
• Asset and patch process: Regularly review DNS server configurations as part of your asset management and patching cycle.

7. Risks, Side Effects, and Roll Back

• Risk or side effect 2: Restarting the DNS service can cause a brief interruption of name resolution. Schedule changes during off-peak hours.
• Roll back: Restore the backed-up named.conf file and restart the DNS service to revert to the previous configuration.

8. References and Resources

• Vendor advisory or bulletin: http://www.nessus.org/u?c4dcf24a
• NVD or CVE entry: CVE-1999-0024
• Product or platform documentation relevant to the fix: BIND documentation on access control lists.