12-12-2017 05:08 PM
I may have misunderstood how forwarders work when configured for a DNS view. I have an internal and external dns view. The internal view is a subset of the external view. The internal view contains the zones/records we want to keep private. Since the internal view contains a small subset of the the external view, I can configure a forwarder at the internal DNS view level. If a request comes into the internal DNS view and that zone does not exist there, it will forward to the external DNS view. The problem is that this seems to only work for forward mapping zones. It does not work for reverse mapping zones. Is this the expected behavior?
Solved! Go to Solution.
12-13-2017 10:02 AM
I've been playing with this for a while now and it looks like the forwarder is actually working. However, something is still different when querying the different DNS views. I've discovered that when I am on a host that uses the external DNS view, I can query any host IP and everything works using:
dig <host_ip> @<dns_server>
When I am on a host that uses the internal DNS view that same query does not work unless I specify the "-x" option for dig.
dig -x <host_ip> @<dns_server>
So I guess my new question is: Why does the dig command work in the external DNS view without the -x option but the internal DNS view requires the -x option?
12-13-2017 12:56 PM
"dig -x" is used for resolving reverse lookups. "-x" is the shortcut for reverse lookups.
It is wierd that in the external view the reverse lookup work without using -x.
Could you provide the dig output from both the internal and external view?
12-13-2017 01:06 PM
I just checked and this seems to be working as expected. I went back through my command history and discovered what went wrong. I had two SSH windows opened, one was on a host using the internal DNS view, the other was on a host using the external DNS view. I was comparing query results between the two. I inadvertently typed "nslookup <ipaddress>" instead if "dig <ipaddress>" That's why I though the dig command was working in the one window. So it turns out this was a huge mistake on my part. Shouldn't be configuring production system when you are tired.
12-13-2017 01:16 PM
Glad that it worked.
Now to answer the intial question, there should not be any difference between a forward lookup and reverse lookup zones with regards to how the forwarder should work(assuming both forward and reverse zones are configured similarly).
10-24-2018 07:16 AM - edited 10-24-2018 07:24 AM
To configure forwarders in the internal DNS view you do the following:
1) Go to Data Management ---> DNS ---> Zones
2) Check the box next to the internal DNS view
3) Click the EDIT icon
4) Click on forwarders in the left pane
5) Add the forwarders in the right pane
6) Save and close
I might be wrong about this next part but I think this is how it works: When a query comes in to the internal view, and the queried zone is not in the internal view, the Infoblox device sends a query to the forwarder(s) you have listed. That "forwarded" query shows the source IP address as the Infoblox device, not the original client. That forwarded query follows the same rules (eg. match clients list) as the original query. The Infoblox interfaces should not be in the match clients list (for the internal DNS view) or they will end up querying the internal DNS view again.
None of the Infoblox interfaces on my grid members are listed in the match clients list for the internal DNS view. I tested the configuration on a lab system first and it worked perfectly. When I moved it to production it worked fine.
10-24-2018 07:21 AM
One thing I did not test, and this might be interesting, would be to add all the of Infoblox IPs to the match clients list of the internal view. Then query someting in the external view to see if the request would be forwarded back to the internal view and cause an endless loop. I'm going to try this to see if it crashes the system.