I have several DNS servers across multiple networks, including a BIND master at 192.168.0.200, Active Directory DNS servers at 192.168.0.225 and 10.1.1.250, and a BIND resolver on a firewall with WAN address 192.168.0.12 and LAN address 10.16.1.1. A static route connects the networks.
Hosts can ping each other across every VLAN, and TCP port 53 appears open from all tested sources. However, DNS queries behave differently depending on the resolver and zone. Queries for host3.vmlan work consistently, while queries for host1.void.local, host2.local, and host4.sym.local often time out when sent through 10.16.1.1 or 192.168.0.225. The same names resolve correctly through 192.168.0.200 or 10.1.1.250 in some cases.
The BIND configuration allows queries from the internal networks and enables recursion, with Google DNS configured as the forwarder. DNSSEC validation is enabled, with validation excluded for the internal zones. I also tested recursive and non-recursive queries. The failing resolver sometimes produces a timeout, while the working resolver returns the expected address.
Since routing and ping appear to work, is this more likely to be caused by BIND ACLs, recursion, forwarding, views, DNSSEC, or a firewall DNS redirect rather than an IP routing issue?
3 Answers
Start with the resolver at 10.16.1.1 and compare its behavior directly. Test both recursive and non-recursive queries, then inspect BIND's logs while making the request. A TCP port check only confirms that something is listening; it does not prove that the DNS server accepts or successfully processes the query. Also avoid using .local for ordinary unicast DNS because that namespace is reserved for multicast DNS, and use a properly delegated internal domain instead.
This looks much more like a DNS configuration problem than a routing problem. A successful TCP handshake on port 53 proves that the hosts can reach the DNS service, and the fact that one zone resolves while another times out points away from a broken route.
Check BIND's allow-query, allow-recursion, and allow-query-cache ACLs carefully. If requests arrive from a network that is missing from the ACL, BIND can silently drop them, which appears as a timeout to the client. Also verify whether the failing zones use a different forwarder or conditional forwarder than the zones that work.
Run dig against a failing server with both +norecurse and +recurse from working and non-working networks, while watching named's query log. If the query appears and is denied, investigate ACLs or views. If it never reaches BIND, check firewall NAT, DNS redirection, or resolver interception. It is also worth testing UDP behavior with dig +bufsize=512 to rule out EDNS or fragmentation issues.
The firewall-side logs only show the queries reaching the master DNS server; the other firewall has little useful information even with debug logging enabled. Local queries such as dig @127.0.0.1 google.com work, so I am adding more query details and checking the ACL and forwarding behavior.
The pattern is per-zone rather than per-network: the same resolver can answer host3.vmlan but time out for other names. That usually means the resolver is handling those namespaces differently. Confirm that the internal zones exist on the expected authoritative servers and that the conditional forwarders still point to the correct AD DNS addresses. Temporarily disabling DNSSEC validation can also help isolate validation problems, although DNSSEC normally produces an error rather than a silent timeout.
Check BIND views as well if they are configured. A request from a particular source network may be landing in a view that lacks the expected zone or forwarder, producing different results even though port 53 is reachable.