These configurations are required to ensure DNSaaS will work properly in different scenarios.
For machines without the Netskope Client and/or DNS Servers, not behind a Netskope Tunnel (IPSec/GRE) where the DNSaaS Anycast IPs have been configured as DNS Servers (for Clients) or Forwarders (for DNS Servers)
In this scenario, which is the most typical for DNSaaS, we’ll consider the minimum configurations required to make DNSaaS to work properly.
In this scenario we are dealing with:
- Clients (any possible device, Server, IoT) that don’t have the Netskope Client deployed, where the DNSaaS Anycast IPs are configured as DNS Servers
- DNS Server machines that are responsible for the DNS resolution of Clients in the Network, where the DNSaaS Anycast IPs are configured as DNS Forwarders for all the non-authoritative domains
DNSaaS Service Configuration
Since the connections to the Netskope Anycast IPs will be coming from the Internet, some configurations are needed to ensure that the DNSaaS service will accept the queries (Netskope DNSaaS is not a Public Resolver opened to the Internet !), and that the traffic is attributed to the correct customer’s tenant, and the customer’s policies will be applied.
To do so, customers must configure all the public egress IPs belonging to them that will be used by the clients and DNS Servers (as forwarders) when sending the DNS query to the Netskope DNSaaS service. This will ensure that the queries coming from those public egress IPs will be accepted by the DNSaaS service, and that they will be associated, and managed by the customer’s tenant.
Steering Configurations
There are no specific Steering Configurations settings for this use case, as Steering Configurations apply at the Netskope Client
Steering Exceptions
There are no specific Steering Exceptions settings for this use case, as Steering Exceptions apply at the Netskope Client.
For machines with the Netskope Client where the DNSaaS Anycast IPs have been configured as DNS Servers
In this scenario, which is not the most typical for DNSaaS, we’ll consider the minimum configurations required to make DNSaaS to work properly.
In this scenario we are dealing with Clients (generally user Desktops/Laptops) that have the Netskope Client deployed, where the DNSaaS Anycast IPs are also configured as DNS Servers.
DNSaaS Service Configuration
In this use case we want to send the DNS query towards the Anycast IPs inside the Netskope Client tunnel. For this reason we don’t need to configure DNSaaS with the customer’s public IPs to accept the queries via the Public Internet and associate them to the customer’s tenant, as the connections towards the Anycast IP will already come from the Netskope Client tunnel.
Steering Configurations
To ensure the DNS queries towards the Anycast IP are sent via the Netskope Client tunnel, customers must enable DNS Security on the Steering Configuration applied to the user enrolled by the Netskope Client
Steering Exceptions
To ensure the DNS queries towards the Anycast IP are sent via the Netskope Client tunnel, customers must avoid Destination Locations Steering Bypasses that are configured as “Bypass” (as opposed to just “Bypass, except for DNS traffic”) for the DNSaaS Anycast IPs.
To note that it’s always a best practice for any customer using DNS Security to configure DNS Steering Bypasses for their internal domain. Let’s note that in this use case any DNS query for any non-public domain is not resolvable by default.
Having specific internal domains configured as DNS Steering Exceptions will make the DNS query for those domains to be sent to the DNSaaS Anycast IPs directly via the Internet. Such queries will either be rejected by DNSaaS (depending on the DNSaaS Service Configuration and the Egress IP used by the Client), or they will be accepted by DNSaaS and resolved as NXDOMAIN.
Netskope Client and Tunnels interoperability
When the Netskope Client starts in a network where a Tunnel (IPSec/GRE) has been established with the Netskope Cloud it is possible to configure the client to disable itself due to the sensing of the Tunnel (how to enable or disable this sensing goes beyond this document). When the Netskope Client is disabled due to the sensing of a Tunnel it will provide user identification and notifications, but it doesn’t steer the traffic itself, so the traffic will go direct and it will be steered by the edge Tunnel created towards the Netskope Cloud depending on the routing/PBR configuration of the Edge device establishing the tunnel. For this reason it’s important to understand that the Steering Configurations and the Steering Exceptions no longer determine what traffic is steered towards the Netskope Cloud.
The Steering Configuration traffic type will no longer determine what traffic is steered towards the Netskope Cloud, and the Steering Exceptions will no longer determine what traffic should go direct, as all traffic will go direct. By all means, a part for what concerns user identification and notifications, when the Client is disabled due to the sensing of a Tunnel, the traffic will follow the same flow of a Device behind a Netskope Tunnel where the Netskope Client is not installed.
For machines with the Netskope Client where the DNS Servers configured are not the DNSaaS Anycast IPs
In this scenario, which can be very typical for DNSaaS, we’ll consider the minimum configurations required to make DNSaaS to work properly.
In this scenario we are dealing with Clients (generally user Desktops/Laptops) that have the Netskope Client deployed, where the DNS Servers configured on the Client are either internal DNs Servers or Public resolvers, most likely configured via DHCP. This is the most typical scenario for remote users, where the Customer can’t control the network the clients connect to.
DNSaaS Service Configuration
In this use case we want to send the DNS Query towards whatever DNS Server IP configured on the Client inside the Netskope Client tunnel. For this reason we don’t need to configure DNSaaS with the customer’s public IPs to accept the queries via the Public Internet and associate them to the customer’s tenant, as the Client will not try to use the DNSaaS Anycast IP in any circumstance.
In order to force the DNS resolution to be served by DNSaaS, customers must configure the “Custom DNS Server” in any DNS profile affecting the users enrolled by the Clients, to point to the DNSaaS Anycast IPs.
Steering Configurations
To ensure the DNS queries towards any DNS server configured on the Client are sent via the Netskope Client tunnel (and they are resolved by DNSaaS due to DNSaaS configured as Custom DNS Server on the DNS Profile), customers must enable DNS Security on the Steering Configuration applied to the user enrolled by the Netskope Client
Steering Exceptions
To ensure the DNS queries towards any DNS server configured on the Client are sent via the Netskope Client tunnel (and they are resolved by DNSaaS due to DNSaaS configured as Custom DNS Server on the DNS Profile), customers must avoid Destination Locations Steering Bypasses that are configured as “Bypass” (as opposed to just “Bypass, except for DNS traffic”) for any possible destination, including “Local IP address ranges” (RFC1918 destinations).
To note that it’s always a best practice for any customer using DNS Security to configure DNS Steering Bypasses for their internal domain. Let’s note that in this use case the Clients may be able to resolve internal domains using the DNS Server configured on the machine.
Having specific internal domains configured as DNS Steering Exceptions will make the DNS query for those domains to be sent to the original DNS server configured on the Client, allowing the Client to resolve local domains that are authoritative on the DNS Server configured on the Client.
Netskope Client and Tunnels interoperability
When the Netskope Client starts in a network where a Tunnel (IPSec/GRE) has been created towards the Netskope Cloud it is possible to configure it to disable itself due to the sensing of the Tunnel (how to enable or disable this sensing goes beyond this document). When the Netskope Client is disabled due to the sensing of a Tunnel it will provide user identification and notifications, but it doesn’t steer the traffic itself, so the traffic will go direct and it will be steered by the edge Tunnel created towards the Netskope Cloud depending on the routing/PBR configuration of the Edge device establishing the tunnel. For this reason it’s important to understand that the Steering Configurations and the Steering Exceptions no longer determine what traffic is steered towards the Netskope Cloud.
The Steering Configuration traffic type will no longer determine what traffic is steered towards the Netskope Cloud, and the Steering Exceptions will no longer determine what traffic should go direct, as all traffic will go direct. By all means, a part for what concerns user identification and notifications, when the Client is disabled due to the sensing of a Tunnel, the traffic will follow the same flow of a Device behind a Netskope Tunnel where the Netskope Client is not installed.
For machines and/or DNS Servers behind a Netskope Tunnel (IPSec/GRE) where the DNSaaS Anycast IPs have been configured as DNS Servers (for Clients) or Forwarders (for DNS Servers)
In this scenario, which can be quite typical for DNSaaS, we’ll consider the minimum configurations required to make DNSaaS to work properly.
In this scenario we are dealing with:
- Clients (any possible device, Server, IoT) that don’t have the Netskope Client deployed but are in a network that has a Tunnel (IPSec/GRE) towards Netskope, where the DNSaaS Anycast IPs are configured as DNS Servers
- DNS Server machines that are responsible for the DNS resolution of Clients in the Network that are in a network that has a Tunnel (IPSec/GRE) towards Netskope, where the DNSaaS Anycast IPs are configured as DNS Forwarders for all the non-authoritative domains
DNSaaS Service Configuration
In this use case we want to send the DNS query towards the Anycast IPs inside the Netskope Tunnel (IPsec/GRE). For this reason we don’t need to configure DNSaaS with the customer’s public IPs to accept the queries via the Public Internet and associate them to the customer’s tenant, as the connections towards the Anycast IP will already come from the Netskope Tunnel (IPSec/GRE).
Steering Configurations
There are no specific Steering Configurations settings for this use case, as Steering Configurations apply at the Netskope Client. Of course, customers must ensure that the PBR on their edge device that establishes the Tunnels with Netskope sends the traffic for the DNSaaS Anycast IPs inside the tunnel.
Steering Exceptions
There are no specific Steering Exceptions settings for this use case, as Steering Exceptions apply at the Netskope Client. Of course, customers must ensure that the PBR on their edge device that establishes the Tunnels with Netskope sends the traffic for the DNSaaS Anycast IPs inside the tunnel.
For machines and/or DNS Servers behind a Netskope Tunnel (IPSec/GRE) where the configured DNS Servers (for Clients) or Forwarders (for DNS Servers) are not the DNSaaS Anycast IPs
In this scenario, which can be quite rare DNSaaS, we’ll consider the minimum configurations required to make DNSaaS to work properly.
In this scenario we are dealing with:
- Clients (any possible device, Server, IoT) that don’t have the Netskope Client deployed but are in a network that has a Tunnel (IPSec/GRE) towards Netskope, where the DNS Servers configured on the Clients are Public resolvers
- DNS Server machines that are responsible for the DNS resolution of Clients in the Network that are in a network that has a Tunnel (IPSec/GRE) towards Netskope, where the DNS Forwarders configured are Public resolvers/DNS Root
To note that in this use case Netskope can’t capture and serve any DNS query sent to any local network, as that traffic cannot be sent to the Netskope Tunnels, which exist between a customer’s edge device and Netskope.
DNSaaS Service Configuration
In this use case we want to send the DNS query towards any Public Resolver/DNS Root IPs inside the Netskope Tunnel (IPsec/GRE). For this reason we don’t need to configure DNSaaS with the customer’s public IPs to accept the queries via the Public Internet and associate them to the customer’s tenant, as the connections towards the Anycast IP will already come from the Netskope Tunnel (IPSec/GRE).
In order to force the DNS resolution to be served by DNSaaS, customers must configure the “Custom DNS Server” in any DNS profile affecting the users enrolled by the Clients, to point to the DNSaaS Anycast IPs.
Steering Configurations
There are no specific Steering Configurations settings for this use case, as Steering Configurations apply at the Netskope Client. Of course, customers must ensure that the PBR on their edge device that establishes the Tunnels with Netskope sends the traffic for the Public Resolver/DNS Root IPs inside the tunnel.
Steering Exceptions
There are no specific Steering Exceptions settings for this use case, as Steering Exceptions apply at the Netskope Client. Of course, customers must ensure that the PBR on their edge device that establishes the Tunnels with Netskope sends the traffic for the Public Resolver/DNS Root IPs inside the tunnel.