Policy Hierarchy
Netskope Policy Engine is hierarchical and it adopts a top-to-bottom, first-match approach.
This means that as soon as the traffic being analyzed matches with the higher policy in the hierarchy, Netskope Policy Engine enforces that policy and it applies the action corresponding to that policy. No other policies that are further down the hierarchy will be evaluated.
Policy Matching
With regards to DNSaaS, consider the following use cases:
- DNS queries sent by devices and/or DNS Servers to the DNSaaS Anycast IPs over the Internet
- In this case, the only information DNSaaS has about the source of the connection is the Public egress IP used by the customer’s Client or the DNS Server performing the query
- DNS queries sent by DNS Servers to the DNSaaS Anycast IPs over a Tunnel (IPSec/GRE)
- In this case, the information DNSaaS has about the source of the connection are the Public egress IP of the IPSec/GRE tunnel and the private IP of the DNS Server performing the query
- DNS queries sent by devices to the DNSaaS Anycast IPs over a Tunnel (IPSec, GRE), where Netskope Client is not deployed on the Client, and where SAML authentication is disabled, or the user has not authenticated yet
- In this case, the information DNSaaS has about the source of the connection are the Public egress IP of the IPSec/GRE tunnel and the private IP of the Client performing the query
- DNS queries sent by devices to the DNSaaS Anycast IPs over a Tunnel (IPSec, GRE), where Netskope Client is deployed on the Client, it’s disabled due to the presence of the Tunnel, but it’s configured to send the User Credentials to Netskope
- In this case, the information DNSaaS has about the source of the connection are the Public egress IP of the IPSec/GRE tunnel, the private IP of the Client and the User Identity performing the query
- DNS queries sent by DNS Servers to any public DNS Server IPs over a Tunnel (IPSec/GRE), and the DNS queries are forcibly resolved via the DNSaaS service using the Custom DNS Server configuration
- In this case, the information DNSaaS has about the source of the connection are the Public egress IP of the IPSec/GRE tunnel and the private IP of the DNS Server performing the query
- DNS queries sent by devices to to any public DNS Server IPs over a Tunnel (IPSec, GRE), where Netskope Client is not deployed on the Client, where SAML authentication is disabled, or the user has not authenticated yet, and the DNS queries are forcibly resolved via the DNSaaS service using the Custom DNS Server configuration
- In this case, the information DNSaaS has about the source of the connection are the Public egress IP of the IPSec/GRE tunnel and the private IP of the Client performing the query
- DNS queries sent by devices to to any public DNS Server IPs over a Tunnel (IPSec, GRE), where Netskope Client is deployed on the Client, it’s disabled due to the presence of the Tunnel, but it’s configured to send the User Credentials to Netskope, and the DNS queries are forcibly resolved via the DNSaaS service using the Custom DNS Server configuration
- In this case, the information DNSaaS has about the source of the connection are the Public egress IP of the IPSec/GRE tunnel, the private IP of the Client and the User Identity performing the query
- DNS queries sent by devices to the DNSaaS Anycast IPs over the Netskope Client tunnel
- In this case, the information DNSaaS has about the source of the connection are the Public egress IP of the Netskope Client tunnel, the private IP of the Client and the User Identity performing the query
- DNS queries sent by devices to any DNS Server IP (internal and public) over the Netskope Client tunnel, and forcibly resolved via the DNSaaS service using the Custom DNS Server configuration
- In this case, the information DNSaaS has about the source of the connection are the Public egress IP of the Netskope Client tunnel, the private IP of the Client and the User Identity performing the query
Based on the different possible use cases above, only specific source criteria can be used to match the Real-Time-Protection Policy associated with any given DNS profile. And as the DNS Policies, like any other Real-Time-Protection Policy, are hierarchical, it’s important to carefully structure the hierarchy to ensure the right Policy applies to the right traffic.
For instance, consider the use case of DNS queries sent to DNSaaS Anycast IPs from Clients in a Guest WiFi network, where the DNSaaS Anycast IPs are configured via the DHCP, and where some devices have the Netskope Client deployed, and others don’t.
In this case, all the devices that have the Netskope Client deployed will send the DNS queries to the DNSaaS Anycast IPs via the Netskope Client tunnel, while the devices that don’t have the Netskope Client deployed will send the DNS queries to the DNSaaS Anycast IPs via the Internet.
In terms of DNS Policies we will be able to differentiate the users only on the DNS queries coming from devices with the Netskope Client deployed, while we can only apply a broader DNS Policy based on the Egress IP used by the guest WiFi network for all the devices without the Netskope Client deployed.
In essence, criteria like the Users used on DNS Policies can only be evaluated if the DNS queries are coming from machines with the Netskope Client deployed. For this reason, we also need to configure DNS Policies that apply to specific Users/Groups above DNS Policies that apply to IP addresses/networks, to ensure that the most specific DNS Policies that apply to the User/Group identities match before the DNS Policies that apply to the Egress IPs (which may be the same).