Tunnel Bug - DNS Upstream Not Excluded

[NicFragale]

In some situations the intercepts that are passed down from the Ziti Controller to a client could match the active DNS IP(s) used by the client system. This causes everything to stop working (Ziti fails). I have witnessed this in MacOS (perhaps also in iOS), but it could exist in other tunnel implementations as well.

PreReqs:

1. The client of the service was in a network that had DHCP and DNS handed to it.
2. The client received a DHCP and DNS offering that set the DNS IPs to a PUBLIC RESOLVER (IE 8.8.8.8). If the DNS IPs were set to a PRIVATE RESOLVER (IE 192.168.1.1), this usually meant that the tunnel excluded the DNS IPs by simple nature of the local routes being protected from intercept. This could still happen if there is not explicitly defined routes that include the DNS IPs used which are still in a private and local network...just by default gateway.

To recreate this:

1. Create an intercept that is wide. In my case, I was intercepting ALL SERVICES (aka Internet, 0.0.0.0/1 and 128.0.0.0/1 TCP&UDP).
2. Assign this service to a MacOS device for intercepting/dialing.
3. Due to the wideness of this service, it should also include the DNS IP (PUBLIC) that the client needs in order to resolve.
4. Witness that the DNS IP is not excluded during tunnel startup and the result is that DNS stops working for the client (including Ziti).

Desired Effect: Review the system just like is done for exclusion of the default gateway, local routes, Ziti Controller/Routers, etc. and ensure that the DNS IP(s) are also excluded during startup.

Potential Side-Effects: DNS redirection in this basic way really prevents a client from ever being able to "full tunnel" traffic to one or more external proxy points defined as services. Exclusion of DNS IPs allows normal operations, but general purpose resolution will never work. IE: I can't intercept all DNS requests and send them to be resolved somewhere else over the Ziti network.