A standard Domain Name System (DNS) server query will always specify a target domain name in the order of the DNS Suffix Search List defined on the client machine. For example, if you have two DNS suffixes defined on your client, (1.) primarydomain.com and (2.) secondarydomain.com, and you want to ping a server called “test”, the query sent to your DNS server will be test.primarydomain.com. The end result, test.primarydomain.com, is often called the Fully Qualified Domain Name (FQDN), it is a name that uniquely identifies a host in the DNS hierarchy. The DNS server checks the FQDN in the DNS Name Query against locally-stored address records, and if it cannot resolve that name, then another query is sent with the next DNS suffix in the list, in our example that would be domain name, secondarydomain.com. So in our case the next query would be test.secondarydomain.dom.
When you are connected to NC with split tunneling enabled and the PCS is set to
Search the device's DNS servers first, then client, we ensure that the DNS query is always sent to the NC adapter just a few milliseconds before sending the query to the Local Area Network (LAN) adapter’s DNS servers. This way if the server name is internal to your corporate network then this gives your PCS DNS server’s a chance to resolve the query first. If it is an external server name such as www.google.com, then your LAN adapter DNS servers will also get the chance to try and resolve the server name.
Normally if your Internet Service Provider (ISP) DNS is not an authority for your internal corporate domain and it cannot resolve the DNS query, it will simply respond with
No such name, and if the DNS suffix appended to server name is the not correct FQDN for the server, the PCS DNS servers will also respond with
No such name. However, there are several ISPs such as Rogers, Bell Canada, EarthLink, etc… which are now implementing a DNS redirection service. This DNS Redirection service works based on the assumption that if your ISP’s DNS servers cannot resolve your server address, then you must have typed in the wrong URL or that the link was a typo. What DNS redirection service does in these cases, is redirect you to their own search site which offers you suggestions in the form of corrected Web addresses, related keywords and search results in an effort to help you get to the website that you are looking for. In order to accomplish this, your ISP’s DNS servers have to resolve your corporate server names to their search site even though they are not an authority for your domain.
If you have
Search the device's DNS servers first, then client set on your NC Connection Profile (
Users > Resource Policies > NC Connection Profiles), then this would resolve the issue for all queries which resolve to the first suffix in your DNS Suffix Search List because Pulse or NC would be the first DNS server to get the query and it will resolve it before the local ISP has a chance to resolve it to a bogus IP. However, DNS name resolution would still be broken for name lookups that resolve to other DNS suffixes configured further down in the list. This is because your ISP’s DNS servers have already resolved the server name bogus ISP before we ever had to the chance to send out the DNS query with the correct DNS suffix.
For Example: You have a corporate server which has a FQDN of test.secondarydomain.com and it resolves to 10.10.10.5 on your corporate DNS, 10.10.10.100. This DNS server is configured for use on the PCS. If we do a ping for server “test”, the query will be test.primarydomain.com since primarydomain.com is the first domain in the suffix search list. This query is not resolvable by PCS DNS server, even though the query was sent a few milliseconds faster to the PCS DNS. Since the local ISP DNS server, 207.69.131.10, resolves test.primarydomain.com to a bogus IP, windows does not send another query which appends the correct DNS suffix, secondarydomain.com, to the server name, test, and the PCS does not get the chance to resolve the server name with the correct FQDN.
PCS is set to
Search the device's DNS servers first, then client
DNS Suffix Search List
VPN Adapter Trace and LAN Adapter trace taken at the same time.
VPN Adapter Trace:
PKT# Date Time Source Destination Proto Info
200 2XXX-09-25 13:27:01.651 10.10.10.120 10.10.10.100 DNS Standard query A test.primarydomain.com
201 2XXX-09-25 13:27:01.669 10.10.10.100 10.10.10.120 DNS Standard query response, No such name
201 Packet Details -
Flags:
.... .1.. .... .... = Authoritative: Server is an authority for domain
LAN Adapter Trace
PKT# Date Time Source Destination Proto Info
120 2XXX-09-25 13:27:01.669 192.168.1.10 207.69.131.10 DNS Standard query A test.primarydomain.com
121 2XXX-09-25 13:27:01.702 207.69.131.10 192.168.1.10 DNS Standard query response A 67.63.55.2
121 Packet Details -
Flags:
1... .... .... .... = Response: Message is a response
.... .0.. .... .... = Authoritative: Server is not an authority for domain
