09-07-2020 01:30 PM
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.
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 184.108.40.206 and 220.127.116.11. Use Forwarders Only is Selected.
ns1xyz - Have fowarders 18.104.22.168 and 22.214.171.124. Use Forwarders Only is NOT Selected.
ns1mnp - Have fowarders 126.96.36.199 and 188.8.131.52. 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?
09-08-2020 11:50 AM
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.
09-12-2020 11:21 AM
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".