For this reason, "stub" resolvers typically set RD=1, and only "full-service
resolvers", such as the one integrated into named (although there are
standalone ones, like Knot, Unbound, [1]), generate RD=0 queries. Full-service
resolvers are capable of taking the referrals, and using them to follow the
delegation chain all of the way down to an authoritative nameserver that can
give a definitive answer. Stub resolvers are a lot dumber -- they just send a
query and process the response, without a lot of referral-chasing, RTT-based
nameserver selection, data ranking and so forth. RFC 1034, Section 5.3.1,
describes stub resolvers, and RFC 1123, Section 6.1.3.1, briefly describes the
difference between stub resolvers and full-service resolvers.
If a stub resolver gets a referral, because of a misconfiguration, policy-based
denial of recursion by an upstream resolver, or for whatever reason, it'll pass
that back to the invoker as "no answer". It's not smart enough to dig deeper
and find the answer. That takes code, and resources, and defeats the whole
purpose of being a "stub" resolver, which is supposed to be relatively
lightweight. Most platforms have added name caching, as a performance
optimization, either directly embedded into the OS (e.g. Windows) or as a
separate daemon/service (e.g. nscd). This makes the stub resolver seem smarter
than originally envisioned, but under the covers, it's still just a single
query/response mechanism (albeit with failover/retry capability), and thus
referrals aren't useful to it.
It should be noted that answering from cache, e.g. when a server gets an RD=0
query, or if it doesn't happen to honor recursion for that particular client,
was originally (perhaps naively) unrestricted, but, given evolving
privacy/security concerns, is now restricted by default, in all (or almost all)
implementations. For BIND, it's controlled by allow-query-cache.
- Kevin
[1] One full-service resolver not mentioned above is "dnscache", part of the
djbdns package. I call this out separately because DNSSEC is against DJB's
religion (apparently), so this software will likely never support DNSSEC
validation.
-----Original Message-----
From: bind-users [mailto:[email protected]] On Behalf Of Barry
Margolin
Sent: Friday, October 06, 2017 12:47 PM
To: [email protected]
Subject: Re: Differences Between Recursion Desired and Recursion Available
In article <[email protected]>,
Harshith Mulky <[email protected]> wrote:
> What I am not able to understand is, What would happen when resolver
> does not set Recursion Desired bit in the query it sends?
If RD is not set, the server should simply not recurse. It answers with
whatever it has in its cache or authoritative data. If it has the answer, it
sends that; otherwise, if it has referral data, it sends that.
--
Barry Margolin
Arlington, MA
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/bind-users
