There seems to be a serious problem with how zScaler interferes with the TCP/IP stack to hijack DNS requests.
I noticed the problem when trying to resolve a random jsgdfgsdf.yahoo.fr (yahoo resolves all subdomains so it is great for testing without worrying about the cache). I get
> nslookup kjsdjkdssdssqdqsddd.yahoo.fr 220.127.116.11 Server: one.one.one.one Address: 18.104.22.168 DNS request timed out. timeout was 2 seconds. Non-authoritative answer: Name: src.g03.yahoodns.net Address: 22.214.171.124 Aliases: kjsdjkdssdssqdqsddd.yahoo.fr rc.yahoo.com
Note the 2 seconds timeout. It does not depend on the target DNS resolver ( 126.96.36.199 in this case)
I checked with Wireshark and the behavior is peculiar to say the least (the grayed out section i the internal suffix, you can skip these lines):
As you can see, there is a ~2 seconds delay after the first successful query (which turns 188.8.131.52 into one.one.one.one for display reasons), and then the request gos on correctly.
EXCEPT that there is an ICMP 3.3 sent back from me to 184.108.40.206. Why? And why here?
It looks like zScaler messes seriously with the resolver.
Funnily enough, a qualified FQDN (with a dot at the end) is OK:
> nslookup kjhjkhjddodfdru.yahoo.fr. 220.127.116.11 Server: one.one.one.one Address: 18.104.22.168 Non-authoritative answer: Name: src.g03.yahoodns.net Address: 22.214.171.124 Aliases: kjhjkhjddodfdru.yahoo.fr rc.yahoo.com
This is even more surprising : how the use of suffixes (automatically added by Windows, unfortunately) could matter?
The next funny thing is that when you use the Windows resolver (ping kjhkjehkjze.yahoo.fr), there is no problem.
This is really the DNS request via a direct resolution of the DNS (by querying its port 53 directly) that poses a problem.
Ah - and of course, there is no problem when zScaler is switched off.