- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
04-07-2021 02:59 AM - edited 04-07-2021 04:20 AM
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).
04-07-2021 05:04 AM
Hi @cg7201
Yes this is expected behavior, not that i know of any documentation to confirm this but the same happens for me when using split DNS.
It has never caused any issues and am seeing same results as you..
Wireshark....
from nslookup the search suffix of the VPN is added immediately, it never tries without it hence unresolvable...
from browser i only see the entered domain name with no suffix added. and it resolves locally without any issues.
The AnyConnect explanation makes sense here...
04-07-2021 05:04 AM
Hi @cg7201
Yes this is expected behavior, not that i know of any documentation to confirm this but the same happens for me when using split DNS.
It has never caused any issues and am seeing same results as you..
Wireshark....
from nslookup the search suffix of the VPN is added immediately, it never tries without it hence unresolvable...
from browser i only see the entered domain name with no suffix added. and it resolves locally without any issues.
The AnyConnect explanation makes sense here...
04-08-2021 01:25 AM
Thanks @Mick_Ball - I did think that this was the case. Thanks for taking the time to to test and confirm.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!