Differences Between Recursion Desired and Recursion Available

[Harshith Mulky]

Hello Experts,

I read this from RFC1035 about RD and RA Bits

RD Recursion Desired - this bit may be set in a query and is copied into the response if recursion supported by this Name Server. If Recursion is rejected by this Name Server, for example it has been configured as Authoritative Only, the response (answer) does not have this bit set. Recursive query support is optional.

RA Recursion Available - this bit is valid in a response (answer) and denotes whether recursive query support is available (1) or not (0) in the name server.

From these, I understood, that in a query(at resolver) if RD bit is set(RD=1), and if a server is authoritative, it will set RA bit to 0 and send back a referral response for the resolver to continue the Referral Procedure. IF the server had supported Recursion, then it would have completed the Referral Procedure and set the RA bit to 1 and sent response to Resolver.

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 Recursion is supported on the server, Would the server do the Referral Queries and set the RA bit while sending Response?

If Recursion is not supported on the server, Would the Referral Query fail from the resolver?

Please can anybody give any pointers in this case?

Thanks

Harshith

[Mukund Sivaraman]

On Fri, Oct 06, 2017 at 08:11:56AM +0000, Harshith Mulky 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 Recursion is supported on the server, Would the server do the
> Referral Queries and set the RA bit while sending Response?
>
> If Recursion is not supported on the server, Would the Referral Query
> fail from the resolver?
>
> Please can anybody give any pointers in this case?

These can be found in RFC 1034. See 4.3.2 on the nameserver algorithm,
that'll take you to 5.3.3 when RD=1 and the nameserver provides
recursion.

Mukund

[Barry Margolin]

In article <mailman.714.150727...@lists.isc.org>,

Harshith Mulky <harshit...@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

[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-user...@lists.isc.org] On Behalf Of Barry Margolin
Sent: Friday, October 06, 2017 12:47 PM
To: comp-protoc...@isc.org
Subject: Re: Differences Between Recursion Desired and Recursion Available

In article <mailman.714.150727...@lists.isc.org>,
Harshith Mulky <harshit...@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-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

[Barry Margolin]

In article <mailman.717.150731...@lists.isc.org>,

"Darcy Kevin (FCA)" <kevin...@fcagroup.com> wrote:

> 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.

It also makes sense from a technical perspective -- why should the
result of a query depend on coincidences of history of the server? Cache
is meant for performance improvement, but it shouldn't affect the
semantics.