recursion yes/no?

Wed Jan 25 10:37:10 UTC 2023

It helps a lot!!

I think I understand now.

Have a great day!

Regards

David

From: Greg Choules <gregchoules+bindusers at googlemail.com> 
Sent: 25 January 2023 10:34
To: David Carvalho <david at di.ubi.pt>
Cc: bind-users at lists.isc.org
Subject: Re: recursion yes/no?

Hi David.

With "minimal-responses", usually I would set it to "no" for a purely authoritative server because resolvers need all the help they can get. But for a purely recursive server I would set it to "yes" because end users don't need (any wouldn't do anything with it anyway) Authority or Additional data. So a hybrid server is a bit stuck between those two settings.

However, from 9.16 BIND now has extra choices (as Evan pointed out). To answer your follow up question I would stick with "no-auth-recursive" as this is exactly the scenario it is designed for.

"dig" (by default, like all stub clients) will make recursive queries; i.e. RD=1. If your server has "minimal-responses no-auth-recursive;" set (or nothing at all since that's the default) then a vanilla query from dig will *not* receive anything it doesn't need to, just like real users. If you *want* to see all the Authority and Additional data then add "+norecurse" to your dig command, which causes it to set RD=0. Your server is then not being asked to do recursion, so it will just reply with everything (if anything) it has.

Hope that helps.
Greg

On Wed, 25 Jan 2023 at 10:16, David Carvalho <david at di.ubi.pt <mailto:david at di.ubi.pt> > wrote:

Good morning and thank you so much!

Now I understand. My servers are not pure authoritative, so I’ll have to keep the recursion enabled.

As for the answers in Authority and Additional sections, after setting minimal-responses to no, now I get the usual output when querying.

For what I understand, there is no downside in maintaining this setting, right?

Thank you!

Kind regards.

David

From: Greg Choules <gregchoules+bindusers at googlemail.com <mailto:gregchoules%2Bbindusers at googlemail.com> > 
Sent: 24 January 2023 18:12
To: David Carvalho <david at di.ubi.pt <mailto:david at di.ubi.pt> >
Cc: bind-users at lists.isc.org <mailto:bind-users at lists.isc.org> 
Subject: Re: recursion yes/no?

Hi David.

"recursion yes;" tells named that it can (if it has to) make queries to other places if it needs more information in order to answer a client query. Pure authoritative servers shouldn't need it and should have "recursion no;". So the first question is, do your servers make queries out to other places? If so, recursion must be enabled.

Secondly, do you have "minimal-responses" configured on either/both servers? If so, what is it set to? There were changes in 9.16 so maybe these explain your observations.

Cheers, Greg

On Tue, 24 Jan 2023 at 16:49, David Carvalho via bind-users <bind-users at lists.isc.org <mailto:bind-users at lists.isc.org> > wrote:

Hello.

I hope someone could help to understand the following.

I have “my.domain.pt <http://my.domain.pt> ” and a master and slave server for the “my” part. I have been using “recursion yes” in both named.conf, as I want them to be both authoritative and cache for my clients.

Last week I migrated my slave DNS server to version 9.16 and only today, after having issues with the primary server migration, I realized that for most queries, my slave DNS does not answer the “ADDITIONAL SECTION” unless I specify “+norec” with the dig command.

My named.conf files only differ in IPs and “master/slave” setting.

My questions:

Should I use recursion on both? (Bear in mind that I also want them to provide chache to clients)

Why do I need “dig +norec” to get the exact output on my slave server? 

Kind regards

David

-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

bind-users mailing list
bind-users at lists.isc.org <mailto:bind-users at lists.isc.org> 
https://lists.isc.org/mailman/listinfo/bind-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20230125/1dcaedab/attachment-0001.htm>