<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Global Protect: Split DNS - NSLOOKUP &amp;amp; DIG expected behaviour in General Topics</title>
    <link>https://live.paloaltonetworks.com/t5/general-topics/global-protect-split-dns-nslookup-amp-dig-expected-behaviour/m-p/396515#M91380</link>
    <description>&lt;P&gt;Thanks&amp;nbsp;&lt;a href="https://live.paloaltonetworks.com/t5/user/viewprofilepage/user-id/9981"&gt;@Mick_Ball&lt;/a&gt;&amp;nbsp;- I did think that this was the case.&amp;nbsp; Thanks for taking the time to to test and confirm.&lt;/P&gt;</description>
    <pubDate>Thu, 08 Apr 2021 08:25:32 GMT</pubDate>
    <dc:creator>cg7201</dc:creator>
    <dc:date>2021-04-08T08:25:32Z</dc:date>
    <item>
      <title>Global Protect: Split DNS - NSLOOKUP &amp; DIG expected behaviour</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/global-protect-split-dns-nslookup-amp-dig-expected-behaviour/m-p/396286#M91353</link>
      <description>&lt;P&gt;What is the expected NSLOOKUP / DIG behaviour when using Split DNS and attempting to resolve an excluded domain?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;We are seeing the following:&lt;/P&gt;&lt;P class="lia-indent-padding-left-30px"&gt;&lt;EM&gt;nslookup excludeddomain.com&lt;/EM&gt;&lt;BR /&gt;&lt;EM&gt;Server: dc.domain.local&lt;/EM&gt;&lt;BR /&gt;&lt;EM&gt;Address: 10.0.0.10&lt;/EM&gt;&lt;/P&gt;&lt;P class="lia-indent-padding-left-30px"&gt;&lt;EM&gt;*** dc.domain.local can't find excludeddomain.com: Non-existent domain&lt;/EM&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Is this expected (obviously it resolves if I tell it to use an external DNS server)?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;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.&amp;nbsp; In Wireshark we can see the DNS requests being made via the VPN adapter only.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;If I browse to&amp;nbsp;&lt;EM&gt;excludeddomain.com,&amp;nbsp;&lt;/EM&gt;Global Protect debug logs shows it cycles through all the DNS suffixes assigned to the VPN adapter and then resolves using the physical adapter.&amp;nbsp; In Wireshark we can see the DNS query is only passed to the physical adapter.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;We are on PAN OS&amp;nbsp;&lt;SPAN&gt;9.1.3-h1 and GlobalProtect&amp;nbsp;5.2.5&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;Portal Agent config: Split-Tunnel Option = Both Network and DNS&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;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:&amp;nbsp;&lt;A href="https://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client/116016-technote-AnyConnect-00.html" target="_blank" rel="noopener"&gt;Behavioral Differences Regarding DNS Queries and Domain Name Resolution in Different OSs - Cisco&lt;/A&gt; - where they state:&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;LI-CODE lang="markup"&gt;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).&lt;/LI-CODE&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Wed, 07 Apr 2021 11:20:13 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/global-protect-split-dns-nslookup-amp-dig-expected-behaviour/m-p/396286#M91353</guid>
      <dc:creator>cg7201</dc:creator>
      <dc:date>2021-04-07T11:20:13Z</dc:date>
    </item>
    <item>
      <title>Re: Global Protect: Split DNS - NSLOOKUP &amp; DIG expected behaviour</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/global-protect-split-dns-nslookup-amp-dig-expected-behaviour/m-p/396315#M91359</link>
      <description>&lt;P&gt;Hi&amp;nbsp;&lt;a href="https://live.paloaltonetworks.com/t5/user/viewprofilepage/user-id/176671"&gt;@cg7201&lt;/a&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;It has never caused any issues and am&amp;nbsp; seeing same results as you..&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Wireshark....&lt;/P&gt;&lt;P&gt;from nslookup the search suffix of the VPN is added immediately, it never tries without it hence unresolvable...&lt;/P&gt;&lt;P&gt;from browser i only see the entered domain name with no suffix added.&amp;nbsp; &amp;nbsp;and it resolves locally without any issues.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;The AnyConnect explanation makes sense here...&lt;/P&gt;</description>
      <pubDate>Wed, 07 Apr 2021 12:04:41 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/global-protect-split-dns-nslookup-amp-dig-expected-behaviour/m-p/396315#M91359</guid>
      <dc:creator>Mick_Ball</dc:creator>
      <dc:date>2021-04-07T12:04:41Z</dc:date>
    </item>
    <item>
      <title>Re: Global Protect: Split DNS - NSLOOKUP &amp; DIG expected behaviour</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/global-protect-split-dns-nslookup-amp-dig-expected-behaviour/m-p/396515#M91380</link>
      <description>&lt;P&gt;Thanks&amp;nbsp;&lt;a href="https://live.paloaltonetworks.com/t5/user/viewprofilepage/user-id/9981"&gt;@Mick_Ball&lt;/a&gt;&amp;nbsp;- I did think that this was the case.&amp;nbsp; Thanks for taking the time to to test and confirm.&lt;/P&gt;</description>
      <pubDate>Thu, 08 Apr 2021 08:25:32 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/global-protect-split-dns-nslookup-amp-dig-expected-behaviour/m-p/396515#M91380</guid>
      <dc:creator>cg7201</dc:creator>
      <dc:date>2021-04-08T08:25:32Z</dc:date>
    </item>
  </channel>
</rss>

