The equivalent of Dnsmasq's resolv-file option in BIND9 is the forwarders directive within a zone or options block, combined with recursion yes. Unlike Dnsmasq which reads upstream servers from a file, BIND requires explicit configuration of forwarder IP addresses. This setup directs unresolved queries to specified external DNS servers.
Understanding the Architectural Difference
Dnsmasq and BIND9 approach DNS resolution differently. Dnsmasq acts as a local caching server that often relies on the system's/etc/resolv.conf or a specific resolv-file to determine where to send queries it cannot resolve locally. It automatically parses this file to identify upstream nameservers. BIND9, however, is a full-featured authoritative and recursive resolver that does not automatically read system configuration files for upstream targets. Instead, administrators must explicitly define where BIND should send queries for domains it is not authoritative for.
This distinction means you cannot simply point BIND to a text file containing IP addresses. You must configure BIND to use the "Forwarding" mode or the "Root Hint" mode. For most local network setups mimicking Dnsmasq behavior, Forwarding mode is the correct choice. This involves telling BIND to forward all non-authoritative queries to a list of specific IP addresses, such as those provided by your ISP or public DNS providers like Google or Cloudflare.
Configuring Forwarders in BIND9
To replicate the behavior of reading upstream servers, you need to edit the main BIND configuration file, typically located at/etc/bind/named.conf.options on Debian-based systems or /etc/named.conf on Red Hat-based systems. The core component here is the forwarders statement.
You should open the configuration file with root privileges using a text editor. Look for the options block. If it does not exist, you may need to create it. Inside this block, you will define two critical directives: recursion and forwarders.
The recursion yes directive enables BIND to perform recursive queries, which is essential for a caching resolver. Without this, BIND would only answer queries for zones it is explicitly configured to serve authoritatively. Next, you define the forwarders block. This takes a list of IP addresses enclosed in braces.
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow port 53.
allow-query { any; };
recursion yes;
forwarders {
8.8.8.8;
8.8.4.4;
1.1.1.1;
};
dnssec-validation auto;
};resolv-file by providing a static list of upstream resolvers. Note that you can add as many IPs as needed, separated by semicolons.
Handling Local Overrides
Dnsmasq also allows for local host definitions via its own configuration files. In BIND, this is handled throughzone declarations. If you have local domain names that should not be forwarded but resolved internally, you must define these as zones in named.conf.local.
For instance, if you have a local zone example.com, you would declare it in named.conf.local:
zone "example.com" {
type master;
file "/etc/bind/zones/db.example.com";
};forwarders list defined in the options block. This two-step process ensures that local records are prioritized while external queries are forwarded efficiently.
Verification and Troubleshooting
After modifying the configuration, always check for syntax errors before restarting the service. Use the commandnamed-checkconf to validate your configuration files. If this command returns no output, your syntax is likely correct. If it reports errors, review the line numbers provided and correct them.
Once validated, restart the BIND service. On systemd-based systems, use systemctl restart named or systemctl restart bind9 depending on your distribution. To verify that forwarding is working, you can use dig or nslookup against the local BIND instance.
dig @localhost example.com +short/var/log/syslog or /var/log/messages, for any error messages related to connection refused or timeout.
It is also worth noting that if you are running BIND alongside other services, you might face conflicts. For example, if you are using Dnsmasq on the same machine, you must ensure they do not both listen on port 53. See our guide on Why dnsmasq failed to create listening socket for 172.17.0.1? for insights into socket binding issues that often arise in mixed environments.
Alternative: Using Root Hints
While forwarders are the direct equivalent to specifying upstream resolvers, BIND can also resolve queries without them by using root hints. Root hints are a file containing the IP addresses of the internet's root DNS servers. BIND contacts these servers iteratively to resolve queries. However, this method is slower and consumes more bandwidth than forwarding. For most local network applications where performance and reduced latency are priorities, configuringforwarders is the superior choice over relying solely on root hints.
If you are dealing with complex network environments involving IPv6 or specific routing requirements, consider how BIND interacts with other tools. Our article on Running Bind9 DNS64 Server with Dnsmasq for Local DNS Resolution with Loopback Interface for Router Advertisements explores advanced configurations where BIND and Dnsmasq work together, highlighting scenarios where their distinct capabilities complement each other.
Frequently Asked Questions
Can I use /etc/resolv.conf directly in BIND9?
No, BIND9 does not automatically read /etc/resolv.conf for upstream servers. You must manually configure the forwarders list in the named.conf.options file. While some older versions or specific wrappers might attempt to parse it, standard BIND9 requires explicit forwarder entries.
What happens if all my forwarders are unreachable?
If all configured forwarders fail to respond, BIND will typically return a SERVFAIL response to the client. Depending on your configuration, it may also try to fall back to root hints if the fallback option is enabled, but by default, it will not retry other forwarders indefinitely.
How do I prevent BIND from being used as an open resolver?
You must restrict the allow-recursion and allow-query options to trusted networks. By setting these to your local subnet (e.g., allow-recursion { 192.168.1.0/24; };), you ensure that only authorized clients can use your BIND server for recursive lookups, preventing abuse.
Does BIND cache forwarded responses?
Yes, BIND caches all responses it receives from forwarders, regardless of whether the response was positive or negative. The cache duration is determined by the TTL (Time To Live) values returned by the upstream servers, just like any other cached record.
How do I debug why BIND is not forwarding queries?
Enable detailed logging in your named.conf options by adding a logging channel with severity 'dynamic'. Check the system logs for messages indicating "forwarding query" or errors related to connection timeouts. Also, verify that your firewall rules permit outbound UDP port 53 traffic to the forwarder IPs.