does bind depends on system DNS settings for lookup?

Darcy Kevin (FCA) kevin.darcy at fcagroup.com
Wed Nov 18 23:50:55 UTC 2015


"Iterative" resolution means following the delegation hierarchy (by sending queries with the RD flag set to 0) to get an answer; "recursive" resolution means sending a query off (with the RD flag set to 1) and relying on the other party to get a complete answer back to you. In order for recursive resolution to be successful, the "upstream" resolver must honor recursion for the client; it signals its willingness to do so by setting the RA flag in its responses to 1.

The distinction between the two types of resolution is kind of like the difference between hiring people with specific skills (e.g. carpenter, plumber, electrician) to work on your house, where you have to do all of the work of identifying/locating them, giving them tasks, arranging payment, etc., versus hiring a general contractor and letting them take care of all the co-ordination and details.

The confusion comes in when it is stated that a DNS node provides "recursive service". What that means, is that, *as*a*provider*, the node receives and honors recursive queries from its clients, but *as*a*consumer*, it typically uses iterative resolution to get the answers. So it's essentially "recursive" on one side (queries come in with RD=1), "iterative" on the other (queries go out with RD=0). Once one understands the provider/consumer distinction, things become a lot clearer.

As for the difference between stub resolvers and forwarders; in protocol-architecture terms, there isn't any difference. They both generate recursive queries and rely on other recursion-honoring DNS nodes to resolve names for them. In *system* architecture terms, however, a stub resolver is only for the benefit of itself, whereas "forwarder" usually refers to a device, server or subsystem that provides DNS resolution to multiple clients. Again, the consumer/provider distinction comes into play. As a shared, scaled resource, forwarders are more likely to provide "value-add" services (such as DNSSEC validation), and to be implemented in a way that maximizes resilience and performance (e.g. running on Anycast addresses).

The previous paragraph should not be read as an *endorsement* of forwarding, however. Personally, I think forwarding is over-used and abused, and I prefer other methods of providing nameservice to clients, e.g. replication, iterative resolution, or, if necessary to work around broken delegations, "stub" zones. Forwarding should, in my opinion, only be used when one faces hard connectivity constraints that can't be accommodated any other way, e.g. needing to resolve Internet names, but within security policies and/or routing constraints which don't allow direct contact with Internet nameservers.

And don't even get me started on forwarding *chains*. Grrr...

										- Kevin

-----Original Message-----
From: bind-users-bounces at lists.isc.org [mailto:bind-users-bounces at lists.isc.org] On Behalf Of Reindl Harald
Sent: Wednesday, November 18, 2015 4:42 AM
To: bind-users at lists.isc.org
Subject: Re: does bind depends on system DNS settings for lookup?



Am 18.11.2015 um 05:42 schrieb Dil Lee:
> This is probably a dummy question.
> My understand of bind in handling non-authoritative queries is:
> 1) forward mode. It just forward the client queries to an upstream DNS 
> server, which is defined in "forwarders" directive.
> 2) recursive mode. It actually start asking from root DNS server, then 
> 2nd level DNS server etc till it finally get an authoritative answer 
> for the host in question.
> Non of these modes seems to depends/relates to the system DNS settings 
> on the host which bind is running on, e.g. /etc/resolv.conf . AMIRITE?

no beause it would not make sense to do so when /etc/resolv.conf contains only 127.0.0.1 which is a common dns-cache setup on inbound mailservers



More information about the bind-users mailing list