This list contains the best practices that should be followed when implementing DNSaaS in the majority of use cases, but it shouldn’t be considered as an exhaustive list as some best practices may depend on the environment, use cases, implementation.
When implementing DNSaaS the following are the most general best practices:
- Configure the Egress IPs used by devices and/or DNS Servers to perform DNS queries through DNSaaS over the Internet on the tenant, in order to authorise the DNS queries from those IP addresses and identify those DNS queries against the Customer tenant
- Ensure that in all the networks where there are devices without the Netskope Client deployed, or devices and/or DNS Server behind a Tunnel (IPSec/GRE), direct connections to any other public DNS server are blocked by the network edge devices, including DoH (DNS over HTTPS), DoT (DNS over TLS) and DoQ (DNS over Quic) to avoid manual configurations that would bypass the DNSaaS protection
- When using DNSaaS as a Custom DNS Server on DNS profiles that apply to traffic to any possible DNS Server IP coming from Netkope Clients and/or Tunnels(IPsec/GRE), ensure that the devices can’t find other protocols to perform DNS queries. For this reason, we recommend to implement the following Policies in FWaaS:
- DNS over HTTPS (DoH) is blocked by the appropriate Policy in the tenant
- DNS over TLS (DoT) is blocked by a Custom Firewall Application for port TCP 853 in the tenant
- DNS over QUIC (DoQ) is blocked by a Custom Firewall Application for port UDP 443 in the tenant
- Configure all the DNS Policies matching Users/Groups above any DNS Policy defined solely on the Source IPs. This is to guarantee that the DNS Policies that target Identities are evaluated before the DNS Policies targeting the source networks
- If you are using any tunnel (NSClient, IPSec/GRE), Netskope is able to prioritize the traffic and will be more performant, but if the traffic is direct, it will be up to the ISP and subject their speeds and may possibly be less performant