DNS Forwarder bind9

Hi,

your forwarders substatement contains the ipadress. If there are multiple then you use ; as a delimiter:

options {
	forwarders { ip_adress; ip_adress; };
};

Select allOpen in new window

Cheers

as I said, the procedure is clear to me. I just don't know how the DNS requests of the clients of bind9 are answered by which DNS forwarder. "dig", "nslookup" don't give me any answers.
By the way, here is the script FYI
bind9 /etc/bind/named.conf.options
...
forwarders {
                #include /etc/bind/forwarder_list
                //8.8.8.8;  
...

script:
#!/bin/bash

#start namebench and wait

pids="""
namebench --output=/tmp/namebench_resolvconf_template --template=resolv.conf &
wait $pids
sed -e 's|nameserver ||' /tmp/namebench_resolvconf_template > /etc/bind/forwarder_list
awk '{print $1}' /etc/bind/forwarder_list > /tmp/tab
sed 's/$/;/' /tmp/tab > /etc/bind/forwarder_list
service bind9 restart

I think the queries are answered in a round-robin fashion. This can be configured though.

OK but shouldn't there be a tool like dig, nslookup which shows me the bind9 DNS-Forward-Query?
rndc querylog shows me the client DNS queries but unfortunately not how bind9 resolves them using the "round-robin' DNS-Forwarder method.

Background of my question is: namebench is looking for the "fastest" DNS server.
Some of the detected DNS servers are fast, but the name resolution, i.e. the correctness or the negative DNS response may not be 100%. Many of my admin colleagues simply leave google DNS 8.8.8.8 or 8.8.4.4 in the DNS forwarder and I think that's not very dynamic. That's what namebench is constructed for :-)

Round robin means that for one query bind will ask the first server, for the second query it will ask the second forwarder and so on. When it reaches the end of the list of forwarders, it will start again with the first one.

Looking at newer messages in the mailing lists, it seems that this is no longer the case.

Forwarders are selected based on an RTT(round-trip-time)-based algorithm, so none of this configuration complexity should be necessary from a performance/availability standpoint. The algorithm will choose faster forwarders over slower ones, and penalization/eventual-redemption of failed/non-responding forwarders is built into the algorithm. It's similar to the NS-selection algorithm; in fact, it might be a common server-selection routine that handles both situations.

Have you considered the option of not forwarding *at*all*? If your BIND instances have direct access to the Internet DNS, then forwarding isn't usually a good choice anyway. As a side benefit, talking directly to the authoritative nameservers should allay the privacy concerns associated with talking through a third party.

So, what you want to do, seems not to be necessary.

Thanks for the RTT tip.
That means you can save the whole namebench method and actually take 8.8.8.8 and 8.8.4.4 or the DNS from the Internet Service Provider.

Which name server bind9 actually chooses is determined by which of the requested name servers is closer to the corresponding namespace, i.e. which one finally sends the answer.

This means that for the next request that is similar to the first one, bind9 no longer asks the DNS forwarder but the name server that responded as soon as possible.

So DNS Forward is actually obsolete.

Your comment tells me that the forwarder directive in bind9 is not necessary because bind9 gets the fastest DNS anyway?