Fix BIND "Response from Unexpected Source" Warning (2026)

BIND is refusing to answer queries because it received a response from an IP address it didn’t expect.

Common Causes and Fixes:

Stale Forwarder Information: BIND’s cache might have old, incorrect IP addresses for a forwarder.
- Diagnosis: Check your named.conf or named.conf.options for forwarders entries. Then, use dig @<forwarder_ip> google.com to see if that forwarder responds. If it does, but BIND still complains, the issue is likely BIND’s internal state.
- Fix: Flush BIND’s cache. Connect to BIND’s rndc control channel:
```
rndc flush
```
- Why it works: This clears BIND’s entire cache, forcing it to re-resolve forwarder IPs and fetch fresh information from authoritative sources.
Misconfigured allow-query or allow-recursion: Access control lists are too restrictive, preventing BIND from sending responses back to the client that initiated the query.
- Diagnosis: Examine your named.conf for allow-query and allow-recursion statements. If they are too specific (e.g., only allowing queries from localhost), BIND might be trying to respond to a client IP that isn’t on the list.
- Fix: Broaden the ACL for internal networks. For example, if your internal network is 192.168.1.0/24:
```
acl "trusted" { 127.0.0.1; 192.168.1.0/24; };
options {
    allow-query { trusted; };
    allow-recursion { trusted; };
    // ... other options
};
```
- Why it works: This explicitly permits BIND to accept queries and send recursive answers to clients within your defined trusted network.
Network Address Translation (NAT) Issues: If BIND is behind a NAT device and the NAT device is not correctly tracking connection states, it might send responses to the wrong internal IP.
- Diagnosis: Verify the public IP address your BIND server is advertising is correctly mapped to its private IP by your NAT device. Check your firewall/router’s NAT configuration for port 53 (UDP and TCP).
- Fix: Ensure your NAT device has "stateful inspection" or "connection tracking" enabled for UDP/TCP port 53. If your BIND server is on 192.168.1.100 and its public IP is 203.0.113.50, the NAT device must correctly map incoming port 53 traffic on 203.0.113.50 to 192.168.1.100.
- Why it works: Stateful NAT keeps track of outgoing connections and ensures incoming responses are routed back to the correct internal host that initiated the request.
Split-Horizon DNS Misconfiguration: If you have different DNS views for internal and external clients, and the external view is incorrectly configured to use internal forwarders, or vice-versa.
- Diagnosis: Review your view stanzas in named.conf. Check the forwarders and allow-query/allow-recursion directives within each view. Ensure the forwarders specified for the external view are external IPs, and for the internal view are internal IPs.
- Fix: Correct the forwarders directive within the relevant view. For an external view, you might have:
```
view "external" {
    match-clients { any; };
    recursion yes;
    allow-query { any; };
    forwarders { 8.8.8.8; 8.8.4.4; }; // Public DNS servers
};
```
- Why it works: This ensures that queries from external clients are forwarded to public DNS servers, and responses are expected from those public servers, preventing unexpected source errors.
Third-Party DNS Resolvers Intercepting Traffic: Another DNS server on the network (e.g., a router’s built-in DNS resolver) is intercepting the query and responding before BIND can.
- Diagnosis: Use tcpdump on the BIND server to monitor traffic on port 53 (UDP and TCP) for queries originating from your clients. See if you get a response from an IP address that isn’t your configured forwarder or an authoritative server for the domain.
```
tcpdump -n -i eth0 udp port 53 or tcp port 53
```
- Fix: Disable or reconfigure the rogue DNS server. Often, this is a setting on your router or gateway device. Ensure clients are only pointing to your BIND server for DNS resolution.
- Why it works: By removing the interfering DNS server, BIND becomes the sole resolver, ensuring it receives and processes all responses directly.
BIND Process Restarted While Queries Were Pending: If BIND was restarted abruptly, it might lose track of ongoing queries. When responses arrive for those old queries, BIND might not recognize them.
- Diagnosis: Check BIND’s logs for messages indicating a restart (rndc stop, systemctl stop named, etc.) around the time the "unexpected source" warnings appear.
- Fix: Perform graceful restarts of BIND using rndc reload or rndc reconfig when possible. If a full restart is necessary, ensure all pending queries have timed out or been answered before stopping the service.
- Why it works: Graceful restarts allow BIND to finish ongoing operations, and stopping the service after pending queries expire prevents it from receiving stale responses.

You will likely hit a "client @0x… UDP: … SERVFAIL" error if you misconfigure your allow-recursion directive to be too restrictive.