Differences Between Recursion Desired and Recursion Available

[Darcy Kevin (FCA)]

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:bind-users-bounces at lists.isc.org] On Behalf Of Barry Margolin
Sent: Friday, October 06, 2017 12:47 PM
To: comp-protocols-dns-bind at isc.org
Subject: Re: Differences Between Recursion Desired and Recursion Available

In article <mailman.714.1507277541.702.bind-users at lists.isc.org>,
 Harshith Mulky <harshith.mulky at outlook.com> 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
bind-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users