What is the expected NSLOOKUP / DIG behaviour when using Split DNS and attempting to resolve an excluded domain? We are seeing the following: nslookup excludeddomain.com Server: dc.domain.local Address: 10.0.0.10 *** dc.domain.local can't find excludeddomain.com: Non-existent domain Is this expected (obviously it resolves if I tell it to use an external DNS server)? Global Protect debug logs shows it cycles through all the DNS suffixes assigned to the VPN adapter but never moves on to the physical adapter. In Wireshark we can see the DNS requests being made via the VPN adapter only. If I browse to excludeddomain.com, Global Protect debug logs shows it cycles through all the DNS suffixes assigned to the VPN adapter and then resolves using the physical adapter. In Wireshark we can see the DNS query is only passed to the physical adapter. We are on PAN OS 9.1.3-h1 and GlobalProtect 5.2.5 Portal Agent config: Split-Tunnel Option = Both Network and DNS I am just curious to find out if the above is expected behaviour and if so, is there any official Palo documentation where it is advised not to use NSLOOKUP or DIG - similar to CISCO documentation here: Behavioral Differences Regarding DNS Queries and Domain Name Resolution in Different OSs - Cisco - where they state: Note: Avoid the use of the NSLookup when you test the name resolution on the client. Instead, rely on a browser or use the ping command. This is because NSLookup does not rely on the OS DNS resolver. AnyConnect does not force the DNS request via a certain interface but allows it or rejects it dependent upon the split DNS configuration. In order to force the DNS resolver to try an acceptable DNS server for a request, it is important that split DNS testing is only performed with applications that rely on the native DNS resolver for domain name resolution (all applications except NSLookup, Dig, and similar applications that handle DNS resolution by themselves, for example).
... View more