Best Practices for DNS and Your Cato Account

For sites in different physical locations, you can achieve better performance by configuring different internal DNS servers for different sites. Alternatively, Cato’s DNS service uses Cato's global PoP locations in the Cato Cloud to provide your hosts with fast and global DNS resolution and can significantly reduce DNS latency. The PoPs store the DNS responses in the cache so that future DNS requests are served more quickly. A host that connects to the Cato Cloud and uses Cato’s DNS services, retrieves the DNS response from the PoP that it’s connected to (usually the closest PoP). Therefore, the DNS response time is very quick and reduces DNS latency.

We recommend that you use Cato’s DNS servers and gain the benefit of the global PoP locations in the Cato Cloud.

For situations that require local DNS servers, you can configure local servers that are physically close to the sites. For example, if you have a site in New York and a site in Singapore, you can use different local DNS servers for each site so that the DNS server in Singapore resolves DNS requests from the clients connected to the Singapore site only. The clients that are connected to the site in New York, don’t need to send DNS requests to the server in Singapore to resolve the query. It’s more efficient and improves the performance of your network.

For more about defining a custom DNS server for a site, see Configuring DNS Settings.

Cato recommends that you configure two different DNS servers for redundancy. Set Cato’s default DNS server (10.254.254.1 or x.y.z3 for internal DNS queries) as the primary and a trusted public DNS server as the secondary DNS server. For more information about trusted DNS servers, see Using Trusted DNS Servers. If the primary DNS server isn't available, Cato then uses the secondary DNS server to resolve the queries. If you are using an internal DNS server, configure DNS forwarding to resolve internal domains.

For macOS users, it’s recommended to only define primary/secondary DNS servers that don’t support DNSSEC such as 10.254.254.1 or an internal DNS server. Starting with macOS 13 Ventura, the operating system prefers DNSSEC (not supported by Cato inspection) to resolve DNS queries, which can break Cato DNS forwarding. For more information see macOS Ventura Users Unable to Reach Internal Resources Via Cato.

Remote users don’t connect through sites but directly to PoPs in the Cato Cloud. Therefore, if the DNS settings are not configured correctly, remote users can experience connectivity problems or can’t access internal resources. For example, if you configure DNS settings for the site rather than for the remote users, the remote users can’t access these internal resources in your domain. The DNS server can’t resolve DNS queries for the Clients since they aren't connected to the site. For this reason, you must configure DNS settings for the Clients to allow this connectivity.

Your account DNS settings are applied to all Sites and remote users. If you have specific DNS requirements for remote users or groups, enable the DNS policy.

Cato recommends that you protect your corporate assets and limit access to internal DNS servers as a best practice. For example, define that people accessing the guest network only use public DNS servers to resolve DNS queries. Create a separate VLAN for the guest network and assign this network to a group of guest users. Then, configure the DNS settings for this group with public untrusted DNS servers only. For more information about trusted networks see, Using Trusted DNS Servers.

To do this:

Cato's DNS Forwarding feature lets you achieve connectivity to local domains in your network.

Remote users usually don’t connect to sites but directly to the Cato Cloud. This means that there is no DNS server to resolve DNS queries for local domains. We recommend that you use DNS Forwarding rules to forward these queries to the relevant DNS internal server. The server resolves the query and lets SDP users connect to corporate internal resources.

DNS Forwarding only applies to DNS requests that are sent to a trusted DNS server (DNS servers configured for your account are considered trusted).

You can configure custom DNS settings for Sites or User/User groups. Custom DNS settings take priority over account-level DNS settings, including DNS Forwarding. However, if DNS Forwarding is configured to forward requests to a trusted DNS server or the DNS server configured for the account, then the account-level DNS settings are used.

Notes:

For Network Rules and firewall rules that are based on DNS (for example TLD, FQDN, and applications), the DNS traffic must use a DNS server that is trusted or defined for the account. Otherwise, these DNS-based rules aren’t applied to the traffic.

If you have an internal DNS server, you must forward the DNS queries to a Cato-trusted DNS server (including Cato DNS), or the DNS server configured for the account.

If you have a Network Rule for off-cloud traffic, make sure that it doesn't include DNS, so the DNS query is sent to a Cato-trusted DNS server.