Articles

Fix DNS "Answer from Unexpected Source" Warning in BIND (2026)

April 16, 2026 7 min read

The BIND DNS server is refusing to answer queries for a zone, reporting that it received an answer from an unexpected source.

This usually means that a DNS response arrived at your BIND server, but the source IP address of that response wasn’t one of the IP addresses BIND expected to receive responses from for that specific query. The most common culprit is a misconfigured forwarder or a DNS cache poisoning attempt.

Here are the common causes and how to fix them:

1. Misconfigured Forwarders in named.conf

  • Diagnosis: Check your named.conf (or included zone files) for forwarders directives within your options block or specific zone stanzas. If you have a forwarders list, BIND will send queries to those servers and expect responses only from them. If a query is answered by a server not in that list, you’ll get this warning.
    # Example named.conf snippet
options {
    directory "/var/named";
    // ... other options
    forwarders {
        192.168.1.10;  # This is a local forwarder
        8.8.8.8;       # This is Google DNS
    };
    // ...
};
  • Fix:
    • Option A (Recommended if you want to use forwarders): Ensure the IP addresses listed in the forwarders directive are correct and accessible. If you’ve recently changed your network or upstream DNS providers, update this list. For example, if 192.168.1.10 is no longer a valid forwarder, remove it.
      # Example fix: Remove an invalid forwarder
forwarders {
    # 192.168.1.10;  <-- Commented out or removed
    8.8.8.8;
};
      After modifying named.conf, reload BIND: sudo systemctl reload named.
    • Option B (If you don’t want to use forwarders): Remove the forwarders directive entirely. BIND will then attempt to resolve queries itself using root hints.
      # Example fix: Remove the entire forwarders block
options {
    directory "/var/named";
    // ... other options
    // forwarders { ... }; <-- Removed
    // ...
};
      Reload BIND: sudo systemctl reload named.
  • Why it works: BIND is designed to respect the explicit instructions you give it. If you tell it to only ask specific servers (forwarders), it will flag any response that comes from a different source as suspicious, preventing potential cache poisoning or incorrect delegation.

2. DNS Cache Poisoning Attempt / Malicious Intermediary

  • Diagnosis: This warning is a security feature. If BIND receives a DNS response that appears to be for a query it made, but the IP address of the sender isn’t an expected source (e.g., not the forwarder you configured, or not a server authoritative for the domain in a direct query), it flags it. This could indicate an attacker trying to inject false DNS records into your cache. Check your BIND logs for unexpected source messages.
    # Example log message
# client 10.0.0.5#54321: received message for query from 172.16.0.1#53: unexpected source
    In this example, BIND expected a response for a query from 10.0.0.5 but received it from 172.16.0.1, which it didn’t expect.
  • Fix:
    • If you are using forwarders: Review your forwarders configuration (as in point 1). Ensure you are forwarding to trusted, reliable upstream DNS servers. If you suspect a specific upstream forwarder is compromised or misbehaving, remove it from the list temporarily and observe.
    • If you are not using forwarders (direct resolution): This warning is less common but could indicate a network issue or a compromised DNS server on the path to the authoritative server. Ensure your network is secure and that no unauthorized DNS servers are reachable.
    • Implement DNSSEC: While not a direct fix for the warning itself, DNSSEC provides cryptographic validation of DNS responses, making cache poisoning much harder. If you control the zones served by this BIND instance, consider signing them.
  • Why it works: By identifying responses from unexpected sources, BIND prevents itself from accepting potentially malicious or incorrect data, thereby protecting your network from DNS cache poisoning.

3. Incorrect Network Configuration or Routing

  • Diagnosis: If your BIND server is on a complex network, or if there are routing issues, a DNS response might be misdirected. A query sent to Server A might be answered by Server B, and due to a routing anomaly, the response to BIND arrives from an IP address that BIND doesn’t associate with Server B. Use tcpdump to inspect traffic on your BIND server’s DNS port (UDP/53 and TCP/53) when a query is made.
    sudo tcpdump -n -i eth0 udp port 53 or tcp port 53 -vv
    Observe the source IP of the incoming DNS response and compare it to the IP of the server you expected to respond.
  • Fix: Troubleshoot your network routing. Ensure that DNS responses are arriving at BIND from the expected network path. This might involve checking firewall rules, router configurations, or network switch settings. If a specific IP is causing issues, you might need to block it at the firewall if it’s not a legitimate server.
  • Why it works: Correct network paths ensure that BIND receives responses from the servers it queried, or from the legitimate authoritative servers for a domain, without them being intercepted or rerouted unexpectedly.

4. Firewall or Network Device Interference

  • Diagnosis: Some firewalls or Intrusion Prevention Systems (IPS) might inspect DNS traffic and, in some cases, rewrite or inject packets. If a firewall is intercepting DNS responses and sending its own modified version, or if it’s blocking responses from the expected source and allowing them from a different one, BIND will see this as an "unexpected source." Temporarily disable any firewalls or IPS devices between your BIND server and its forwarders (or the internet, if not using forwarders) and see if the warning disappears.
  • Fix: Configure your firewall or IPS to allow legitimate DNS traffic from your forwarders or to the authoritative DNS servers. You may need to create specific rules to allow UDP/TCP traffic on port 53 to/from your BIND server’s IP and your upstream DNS servers’ IPs.
  • Why it works: By ensuring that no network device is interfering with or modifying DNS packets in an unexpected way, BIND receives the original, untampered responses from their true sources.

5. Local DNS Cache Corruption (Less Common with Modern BIND)

  • Diagnosis: Although BIND is the server, its own cache could theoretically become corrupted, leading it to believe it should receive a response from a specific source when it actually received it from another. This is rare for the "unexpected source" warning itself but can contribute to general DNS confusion. Clear BIND’s cache: sudo rndc flush.
  • Fix: After clearing the cache, restart BIND (sudo systemctl restart named) to ensure it reloads its configuration cleanly.
  • Why it works: A clean cache removes any potentially stale or incorrect state information that might lead BIND to expect a response from a source that is no longer valid or was never correct.

6. Misconfigured allow-query or allow-recursion

  • Diagnosis: While allow-query and allow-recursion control who can query your server, a misconfiguration here can indirectly lead to confusion. If your server is configured to only allow recursive queries from a specific IP range, and a query comes in from an IP outside that range, the response might be handled in a way that triggers this warning if the server tries to resolve it internally and gets an unexpected answer. Check your named.conf for allow-query and allow-recursion directives.
    # Example named.conf snippet
acl "trusted" { 192.168.1.0/24; 10.0.0.0/8; };
options {
    // ...
    allow-query { trusted; localhost; };
    allow-recursion { trusted; localhost; };
    // ...
};
  • Fix: Ensure that allow-query and allow-recursion are configured correctly to permit queries from legitimate clients. If you intend for your BIND server to resolve queries for external clients, ensure those client IPs are included in the ACLs.
  • Why it works: Correct access control ensures that BIND processes queries from authorized clients as intended, preventing unusual handling paths that might lead to unexpected source warnings.

The next error you’ll likely encounter if you haven’t addressed the root cause is a complete failure to resolve DNS queries, or continued "unexpected source" warnings leading to dropped queries.

Want structured learning?

Take the full Dns course →