We have an internal and external DNS view and the internal view is always checked first using a match_cleint_list. The internal view has a forwarder configured (this is a grid-wide setting) and that forwarder is an anycast address that all grid members have. If an internal client queries the internal view and the target is not found, the request is forwarded to the anycast address. Since the anycast address is on every box, the query gets forwarded to the anycast loopback address and the query stays local to the grid member. We have been successfully using this config for over ten years.
We recently added a new "internal" grid member that does not have an anycast address and it isn't going to get one. Both internal and external DNS views are hosted on this new grid member. There seems to be no way to get this one grid member to forward a query from the internal view to the external view without leaving the box. Since the internal view has the anycast address configured as a forwarder, the forwarded query HAS to leave the local grid member to be forwarded to a different grid member that has the anycast address. I am trying to come up with a solution to allow the query to forward from the internal to the external view without leaving the local box.
Here are some things I have tried:
Configure the anycast address on the "internal" grid member as a loopback interface but don't make it an anycast address just make it a loopback interface. NIOS will not allow this. It knows about the anycast address on the other grid members and it will not allow me to create a non-anycast loopback interface on this "internal" grid member using the same IP.
As an alternate plan I configured a loopback IP of 192.168.200.1 as the loopback and configured DNS to listen on this additional interface. From the console of the grid member I can successfully run dig commands and query the external DNS view. The 192 network is not in the internal view's match_client_list so there is no forwarding going on when testing from the console.
Next I tried adding that 192.168.200.1 address to the grid member's list of forwarders. An external query forwards to that 192 address but no response is seen from the client.
Finally, I tried adding that 192 address to the internal dns view's list of forwarders. So now I have the anycast address in there in addition to that 192 loopback address. Again, a traffic capture shows the query forwarding to the 192 address but the client sees no response. If I'm on the console of the grid member I can successfully run a dig command against that 192 loopback address.
For some reason when a query gets forwarded to the loopback address, the client never sees the answer back. We don't use the 192 private network space anywhere in our network. I'm at a loss as to why the forward to the loopback works from the console but not from the client's query.
