Recursive DNS lookup clarification

[#1]

Hi IB Community,

I am redesigning our Infoblox deployment that I inherited and has been running for more than 10 years. During the discovery, I was confused with one of the DNS resolution behaviour and wanted to clarification.

Scenario:

A production IB grid for internal DNS only. The grid has 3 IP addresses listed in grid DNS forwarder and all those IP belongs to Infoblox appliances.....example below

ns1abc - Have fowarders 8.8.8.8 and 1.1.1.1. Use Forwarders Only is Selected.

ns1xyz - Have fowarders 8.8.8.8 and 1.1.1.1. Use Forwarders Only is NOT Selected.

ns1mnp - Have fowarders 8.8.8.8 and 1.1.1.1. Use Forwarders Only is NOT Selected.

ns1abc and multiple other IB appliances are in a NS-group that is authoritative for mydomain.com

ns1xyz and ns1mnp and multiple other IB appliances are in another NS-group that is authoritative for test.mydomain.com.

The confusion is around DNS record resolution in zone test.mydomain.com. ns1abc is giving a non-authoritative response for record1.test.mydomain.com. How did that recursrive DNS lookup work when ns1abc is not in the NS-group and has external forwarders configured and when itself is listed in the Grid DNS properties as one of the Infoblox IP address?

Thanks

-S

[#2]

Hello Sneha,

Did you inspect the DNS view which served that non-authoritative response from ns1abc ? If not, take a look at ns1abc's named.conf & identify the view which is suppose to serve this request. If this specific query didn't fall into the view authoritative for mydomain.com & if test.mydomain.com's NS info has been registered with your provider for public avaialbility, I guess its normal recursion(As long as the serving view had recursion enabled). 

Now if you say :

• This specific query for record1.test.mydomain.com fell into a ns1abc's DNS view authoritative for mydomain.com.
• ns1abc is not a part of the authoritative NS group for test.mydomain.com.
• There's no delegation for test.mydomain.com added to ns1abc.

Then i'd say that its a violation of RFC & you'd need to sync up with Technical Support. But I'm kind of 100% sure that you'd find the reason if you take a closer look at the resolution heirarchy.

Good luck.

[#3]

The first thing that I would do in this case is test each server to see how it handles non-recursive queries for the record in question, then look for delegations/SOA for each parent domain, if needed. For me, at least, it helps make the named.conf a little more 3D so I can visualize what the configurations are doing. 

You'll need dig for this - there's a download at isc.org and Infoblox has training on how to use dig, or you can use the widget in the Dashboards.

dig record1.test.mydomain.com +norecurse @ns1abc 

dig record1.test.mydomain.com +norecurse @ns1xyz 

dig record1.test.mydomain.com +norecurse @ns1mnp 

If those tests gave you name servers under the authority section and answer how the record resolves, you don't need to do the following for the test subdomain, unless you want to be thorough. The first two will be the most interesting and the last 4 should be themselves.

dig test.mydomain.com NS @ns1abc 

dig test.mydomain.com SOA@ns1abc 

dig test.mydomain.com NS @ns1xyz 

dig test.mydomain.com SOA@ns1xyz 

dig test.mydomain.com NS @ns1mnp 

dig test.mydomain.com SOA@ns1mnp 

The first two should be itself and the last 4 might be interesting.

dig mydomain.com NS @ns1abc 

dig mydomain.com SOA@ns1abc 

dig mydomain.com NS @ns1xyz 

dig mydomain.com SOA@ns1xyz 

dig mydomain.com NS @ns1mnp 

dig mydomain.com SOA@ns1mnp 

One setting you probably want to check in the GUI is under each zone's properties in the view, under the Settings tab - look at the bottom of that screen for "Don't use forwarders to resolve queries in subzones".