Reset Search



KB16461 - DNS resolution fails through NC and Pulse if the ISP enables DNS assistance, hijacking, or redirection.

« Go Back


Last Modified Date8/10/2016 2:42 PM
This article describes the issue of Domain Name System (DNS) resolution failure through Network Connect (NC) and Pulse, if the Internet Service Provider (ISP) enables any kind of DNS hijacking and split tunnel is enabled. The DNS hijacking service may also be known as DNS assistance or DNS redirection.
Problem or Goal
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.) and (2.), and you want to ping a server called “test”, the query sent to your DNS server will be The end result,, 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, 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, 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 and it resolves to on your corporate DNS, This DNS server is configured for use on the PCS. If we do a ping for server “test”, the query will be since 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,, resolves to a bogus IP, windows does not send another query which appends the correct DNS suffix,, 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    DNS    Standard query A
201   2XXX-09-25    13:27:01.669    DNS    Standard query response, No such name
201 Packet Details -
.... .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    DNS    Standard query A
121    2XXX-09-25    13:27:01.702     DNS    Standard query response A
121 Packet Details -
1... .... .... .... = Response: Message is a response
.... .0.. .... .... = Authoritative: Server is not an authority for domain
As of PCS version 7.4RX and Pulse 5.0, Search device DNS only can be selected to avoid ISP's which have DNS hijacking implemented. When the Search device DNS only option is selected, DNS on the end user’s system are replaced with device DNS. Note that this option is applicable only for Windows platforms.

Alternatively, the following workarounds may also be configured:
  • Configure your role to disable split tunneling. This will ensure that DNS queries can only be resolved by the PCS DNS servers.
NOTE: In 7.1Rx or later, the split tunnel options have been updated on PCS. Ensure that the PCS tunnel routes take precedence, even when split tunneling is disabled; otherwise you will still observe the issue. If PCS tunnel routes do not take precedence, then access to the local subnet will still be allowed. In this case, it is possible that DNS queries may still be sent out via the physical adapter and result in the issue.
  • Implement the use of Canonical Name or CNAME records on your internal DNS servers. When a DNS server looks up a name and finds a CNAME record, it returns the canonical name. Then the DNS server sends out a new query by using the canonical name. For more information, refer to the following link:See the following link:​
For example (VPN Adapter Trace):
PKT#  Date       Time            Source          Destination     Proto  Info
200   2XXX-09-25 13:27:01.651    DNS    Standard query A
201   2XXX-09-25 13:27:01.669    DNS    Standard query response CNAME A
  •  Manually switch the clients over to OpenDNS servers, which do not implement DNS redirection; such as and
Related Links
Attachment 1 
Created ByData Deployment



Was this article helpful?



Please tell us how we can make this article more useful.

Characters Remaining: 255