Based on the code you linked to, there might be a bug in the add_supplemental_resolvers flow which will exclude search domains entirely. Which is inline with what we see in our experiments.
Yes, see the same behavior on mac. With scutil --dns, we can see that only the value in matchDomains is being applied to resolver as search domain. Based on matchDomainsNoSearch true or false. The value in searchDomains has no bearing whatsoever.
I tried with an app that lets us send ping, see the same issue there. Can try with a new sample app, but I expect it would behave the same.
Yes, for this experiment it was in destinationIP mode.
IncludeAllNetworks is off.
For split tunnel mode, we don't set the default route (Which was the mode for this test).
We do set the default route when testing with split tunnel off, where the expectation is all traffic goes through tunnel.
Hey Quinn, thank you for your reply. I am seeing this on iOS. An end user enters a single label field in a browser (tested with Safari and Chrome). For example, user enters https://myapp in Safari while my packetTunnelProvider VPN is connected, but we never see the DNS packet.
Hey Quinn, that was explaining the setup, split tunneling is implemented at a logical level. The issue we are facing is around debugging the situation once we actually write packets to the TUN interface.
Based on the code you linked to, there might be a bug in the add_supplemental_resolvers flow which will exclude search domains entirely. Which is inline with what we see in our experiments.
Yes, see the same behavior on mac. With scutil --dns, we can see that only the value in matchDomains is being applied to resolver as search domain. Based on matchDomainsNoSearch true or false. The value in searchDomains has no bearing whatsoever.
I tried with an app that lets us send ping, see the same issue there. Can try with a new sample app, but I expect it would behave the same.
Yes, for this experiment it was in destinationIP mode.
IncludeAllNetworks is off.
For split tunnel mode, we don't set the default route (Which was the mode for this test).
We do set the default route when testing with split tunnel off, where the expectation is all traffic goes through tunnel.
Hey Quinn, thank you for your reply. I am seeing this on iOS. An end user enters a single label field in a browser (tested with Safari and Chrome). For example, user enters https://myapp in Safari while my packetTunnelProvider VPN is connected, but we never see the DNS packet.
Hey Quinn, that was explaining the setup, split tunneling is implemented at a logical level. The issue we are facing is around debugging the situation once we actually write packets to the TUN interface.