"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-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Reindl Harald
Sent: Wednesday, November 18, 2015 4:42 AM
To: bind-users@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
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
