We're seeing two odd things with DNS in our Network Extension.
One is a problem which appears to be related to an interaction between enforceRoutes and DNS
One of the configurations we have is setting ourselves as the default DNS resolver by setting matchDomains to [@""], and specifying a list of DNS searchDomains.
When enforceRoutes is YES we aren't seeing all the DNS resolution we expect. When enforceRoutes is NO it looks like it's working. Same iOS version (16.3), same VPN extension. The only difference in configuration is enforceRoutes set to YES in the failing case. excludeLocalNetworks in YES in each case.
Is there some known interaction there that I'm missing?
The other issue is that some customers with that configuration aren't seeing DNS name completion. I.e., if matchDomains is
[ @"aaa.com", @"aab.com" ]
then trying to resolve
foo
in a browser should attempt foo.aaa.com and foo.aab.com. We're not seeing that at all. If matchDomains is the same as searchDomains then resolution is happening fine.
Ok, we figured out what was happening here.
enforceRoutes doesn't just ensure that traffic destined for the tunnel gets there, it also makes sure that traffic which does not match the tunnel does not go to the tunnel.
We set the DNS resolver as the IP of the VPN interface, but that's not always one of the includedRoutes for the VPN. In that case enforceRoutes ON will make DNS resolution not use the tunnel.
The workaround appears to be adding the IP address of the VPN interface to the includedRoutes. We haven't seen any side-effects from that yet.
This is a pretty weird behavior for enforceRoutes. Not the only unexpected problem we've seen with that flag -- We have another question open in the forums related to enforceRoutes as well, and its interaction with excludedRoutes: