These are the most commonly supported use cases for DNSaaS.
There can be other deployments where the use of DNSaaS, Tunnels (IPSec/GRE) and Netskope Clients are mixed. But those will be discussed in the Policy Ordering section.
Secure DNS Resolutions from devices without the Netskope Client (Servers, IoT devices, Unmanaged Devices) relying on local DNS Server forwarders and without the use of Tunnels (IPSec/GRE) towards Netskope
DNSaaS can help to secure the DNS resolution for external domains in an on-premise managed customer’s network where there are devices without the Netskope Client installed, and that there are no Tunnels (IPSec/GRE) between the customer network and Netskope. Such devices may be Servers, IoT devices, or any other unmanaged device that is connected to the network.
The high-level design of the use case is the following:
In this scenario, all the devices connected to the customer’s managed network are configured either via DHCP, or manually, to use a local DNS Server(s). With “local”, the DNS Server IP is a RFC1918 address, while the physical location of the DNS server may be elsewhere provided that an overlay routing allows the Clients to reach it.
All the DNS queries from the devices without the Netskope Client installed will necessarily go to the internal DNS Server(s).
While the internal DNS Server will be authoritative for all the internal domains/zones, in order to secure the resolution of external domain/zones customers can configure the Netskope DNSaaS Anycast IPs as Forwarders on the DNS Server(s).
This will ensure that all the recursive resolutions for external domains will be forwarded to the Netskope DNSaaS service, where the DNS policies can be applied.
Limitations
- Custom Categories are not currently available for DNSaaS Policies
- The current DNSaaS solution only provides a way to block the resolution or resolve the query with a sinkhole address. It’s not possible to use the DNSaaS solution to redirect the users to a block page managed by Netskope
- The current DNSaaS solution doesn’t support EDNS
- The current DNSaaS solution doesn’t support DNSSEC
- The current DNSaaS solution drops the query packets when the action is “block”. This means that the internal DNS Server must be configured to never attempt root resolutions or use any other forwarder, or ban the non-responding forwarders, in case it doesn’t receive an answer from the Netskope DNSaaS forwarders
- The current DNSaaS solution can identify the DNS requests coming from the customer’s Clients and the DNS Servers over the Internet only based on the Public IP address used by those devices when connecting to the DNSaaS Anycast IPs. Hence, DNS Policies and reporting can only be applied on the public egress IPs of the Clients/DNS Servers, and there can’t be granular visibility of the user entities initiating the requests
Apply basic Web Filtering via Secure DNS Resolutions from “guest” or “unmanaged” networks
DNSaaS can help to apply basic Web Filtering through secure DNS resolutions.
Such networks can be “guest” networks such as guest WiFi or guest wired networks, or they can be any network that doesn’t need internal resolution, and where unmanaged devices are connected, making impossible, but also redundant, any attempt for packet inspection of the web and non-web traffic.
In this scenario all the devices connected to the managed network are configured via DHCP to use the Netskope DNSaaS Anycast IPs as DNS Servers.
This will ensure that all the DNS resolutions will be sent to the Netskope DNSaaS service, where the DNS policies can be applied. The DNS Policies can be applied using all the Web Categories supported by the Netskope One Platform, providing an easy and effective way to impose Web (and non-web) filtering at the DNS resolution level.
Limitations
- Custom Categories are not currently available for DNSaaS Policies
- The current DNSaaS solution only provides a way to block the resolution or resolve the query with a sinkhole address. It’s not possible to use the DNSaaS solution to redirect the users to a block page managed by Netskope
Enforce the use of the Netskope Resolver for DNS queries sent by the Netskope Client
DNSaaS can ensure all the DNS queries captured by the Netskope Client will be resolved by the Netskope Resolver. If a customer uses DNSaaS for other use cases, it makes sense they’d consolidate all the external resolutions, including the ones coming from the Netskope Client, to be handled by the Netskope Resolver.
In this scenario, all the clients with the Netskope Client deployed, DNS security is enabled, so Netskope Client steers all the DNS queries that are not explicitly bypassed via the Steering Configuration (whether by IP destination or by queried record/domain). The DNS Servers configured on the Client are not the DNSaaS Anycast IPs, but they are internal or public DNS Servers configured via DHCP or manually by the user.
Customers can configure the DNSaaS Anycast IP addresses as “Custom DNS Servers” on the DNS Profiles to ensure that all the DNS queries that are steered by the Netskope Client, both the ones originally for an internal RFC1918 and the ones for any possible public DNS, will be resolved by the Netskope Resolver.
Limitations
- Custom Categories are not currently available for DNSaaS Policies
- The current DNSaaS solution only provides a way to block the resolution or resolve the query with a sinkhole address. It’s not possible to use the DNSaaS solution to redirect the users to a block page managed by Netskope. When using DNSaaS in conjunction with Netskope Clients it’s best practice to rely on the DNSaaS only for blocking security categories, and filter the traffic to other categories with the appropriate SWG and/or CFW Policies