When configuring BIND9 with multiple forwarders, a common question arises about query prioritization. The forwarders directive in named.conf accepts multiple DNS servers, but their operational behavior isn't always intuitive.

BIND9 processes forwarders in sequential order with the following characteristics:

• Queries are first sent to the top-listed forwarder
• If no response is received within the timeout period (default 5 seconds)
• BIND9 progresses to the next forwarder in the list
• This continues until a response is received or all forwarders are exhausted

Here's how to properly structure your forwarding configuration for prioritized resolution:

options {
    forwarders {
        192.0.2.1;    // Primary ISP DNS (first priority)
        203.0.113.45; // Secondary OpenNIC DNS
    };
    forward only;     // Important for strict forwarding control
    forward first;    // Default behavior (tries forwarders before recursion)
};

To monitor which forwarder is being used for queries:

# Enable query logging
rndc querylog on

# View live queries in the system log
tail -f /var/log/syslog | grep named

# Alternative detailed debugging
named -g -d 3

Sample debug output showing forwarder selection:

client @0x7f1e9406b0f0 192.168.1.100#12345 (example.com): query
sending to 192.0.2.1#53
query response timeout
sending to 203.0.113.45#53

For more granular control over forwarder behavior:

options {
    forwarders {
        192.0.2.1 port 5353;    // Custom port forwarder
        203.0.113.45;
    };
    forward only;
    max-forward-timeout 2000;   // 2 second timeout per forwarder
    max-forward-names 3;        // Max forwarders to try
};

When mixing IANA and alternative root DNS systems:

• Always place trusted forwarders first in the list
• Consider using forward first to maintain fallback to root servers
• Implement TSIG for authenticated forwarding when possible

Use this command to check forwarder performance:

rndc stats
grep "queries forwarded" /var/log/named.stats

When configuring forwarders in BIND9, the order of DNS servers in the forwarders list matters. BIND9 processes forwarders sequentially from first to last, only moving to the next server if the previous one fails to respond (timeout) or returns SERVFAIL. It does not load balance or randomly select forwarders.

For your specific case of prioritizing ISP DNS while still supporting OpenNIC domains, here's the optimal configuration:

options {
    forwarders {
        192.0.2.1;    // Primary ISP DNS (first priority)
        192.0.2.2;    // Secondary ISP DNS
        198.51.100.1; // OpenNIC DNS (last resort)
    };
    forward only;     // Never fall back to root servers
};

To verify which forwarder is being used for specific queries:

Method 1: Using rndc querylog

# Enable query logging
rndc querylog on

# Tail the query log (typically in /var/log/named/queries.log)
tail -f /var/log/named/queries.log

Method 2: Using dig with +trace

dig @localhost example.com +trace
dig @localhost project +trace

For more granular control, consider using view-based forwarding for different TLDs:

view "opennic" {
    match-clients { any; };
    match-destinations { any; };
    match-recursive-only yes;
    
    zone "geek" {
        type forward;
        forwarders { 198.51.100.1; };
    };
    
    zone "project" {
        type forward;
        forwarders { 198.51.100.1; };
    };
};

view "default" {
    match-clients { any; };
    match-destinations { any; };
    
    // All other queries go to ISP DNS
    forwarders { 192.0.2.1; 192.0.2.2; };
};

Your concern about OpenNIC potentially hijacking IANA domains is valid. The sequential forwarder approach protects against this, as BIND9 will:

• First try ISP DNS for all queries
• Only use OpenNIC if ISP DNS fails to respond
• Never use OpenNIC for IANA domains if ISP DNS returns NXDOMAIN