Best Practices for DNS and Your Cato Account

Overview of Cato DNS Service

Cato Networks can provide DNS service for your account and act as your DNS server. By default, Cato uses the following DNS servers: (Cato PoP DNS server) as the primary server and (Google DNS server) as the secondary. For sites in China, Cato uses a list of DNS servers located in China as the primary DNS server, however this can be changed to any China regional public DNS resolver.

To use the Cato DNS server, no changes are required in the Cato Management Application, or you can configure the DNS settings and configure your account to use private DNS servers. Using the Cato DNS service provides a number of security protections and advantages. The service processes all DNS requests and generates the responses, which allows Cato to inspect the requests. If required, the DNS queries are securely forwarded to trusted global DNS providers which include,, and Other DNS providers are considered as an untrusted DNS server.

Best Practices for DNS

This section contains best practices and recommendations for configuring DNS with Cato and can help you achieve more security, redundancy, and better performance.

Improving Network Performance for Internal DNS Servers

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 fast and global DNS resolving 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 example, 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 for your network.

Setting Primary and Secondary DNS Servers for Failover

Cato recommends that you configure two different DNS servers for redundancy. Set Cato’s default DNS server ( as the primary and a public DNS server (Cato's trusted DNS servers are:,, and as the secondary DNS server. 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 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.

Working with DNS for SDP Users

SDP users don’t connect through the account’s sites but directly to the Cato Cloud. Therefore, if the DNS settings are not configured correctly, SDP 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 SDP users, the SDP 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 SDP Clients to allow this connectivity.

You can define DNS settings for:

  • Individual SDP users (Accounts > Users > <user name> > User Configuration > DNS)

  • Groups of SDP users (Assets > Groups > <group name> > DNS).

When you use the Cato DNS server, all the DNS queries are resolved in the PoPs in the Cato Cloud, so these issues for SDP users aren't relevant. You can use DNS forwarding rules to give SDP users connectivity to internal DNS servers. See below, Connectivity for SDP Users with DNS Forwarding.

Protecting Internal Resources for Guests

Cato recommends that you protect your corporate assets and limit the access to internal DNS servers as a best practice. For example, you define that people accessing the guests’ network only use public DNS servers to resolve DNS queries. Create a separate VLAN for the guests’ network and assign this network to a group of guest users. Then, configure the DNS settings for this group with public DNS servers only. The following screenshot shows a group of guest users with public DNS servers configuration:


Connectivity for Remote Users with DNS Forwarding

The 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 Cato trusted DNS server
  • The DNS server configured for the account

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.


  • Cato can forward DNS queries only if you use Cato’s default DNS servers with the default DNS settings

  • DNS Forwarding can process DNS requests over either UDP and TCP

  • The PoPs don't store DNS forwarding requests in the cache

Forwarding DNS Traffic to Cato

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. For more about configuring the DNS settings, see Configuring DNS Settings.

Cato DNS Security Features

DNS is a potential security vulnerability, and the Cato DNS service includes many security features and protections. We recommend that wherever possible, you use Cato as the DNS server for your account. In addition, the Cato IPS and firewall security services provide many security benefits for DNS traffic.

DNS Security Protections with Cato IPS

Cato's IPS is an essential component for mitigating DNS related threats. When IPS is enabled on your account with the Block action, Cato monitors DNS requests and responses, and provides protections based on reputation, behavioral signatures, and heuristics. Cato's IPS provides the following DNS protections:

  • DNS Tunneling – Payload-carrying protocols are encapsulated inside DNS requests and responses to bypass inspection by firewalls and access control mechanisms. The Cato Security team uses Machine Learning to generate IPS protections to identify and block this technique (read more in this blog post)

  • DNS Messenger – Malicious textual content is included inside DNS requests and use the DNS communication to traverse the network. The communication itself is identified by dedicated heuristic protections in the IPS engine and the initial malicious payload is identified by Next Gen Anti-Malware engine.

  • DNS-Based Exploits & DNS Vulnerability Attacks - Cato's IPS protects against known exploits and vulnerabilities and the Security team is constantly adding protections for new CVEs and exploits of DNS vulnerabilities to the IPS engine.

  • Use of DGA (Domain Generation Algorithm) - DGA is seen in various malware families and periodically generates a predictable list of domain names that attackers can register for their command and control servers. Cato identifies the use of DGA using dedicated intelligence feeds as well as heuristics.

  • Cache Poisoning, Phantom, Amplification, Hijack, NXDomain - These are attacks that target the DNS service itself and its responses. Cato maintains a group of 3rd party DNS providers which are known to be trustworthy and secure (for example, Google DNS). The Cato DNS server automatically inspects every request and then forwards them to one of these DNS providers (depending on the location) which uses protections against these threats.

  • Additional Cato DNS protections:

    • Reputation intelligence feeds also include compromised domain zones

    • Identifies obsolete or malfunctioning query types

DNS Best Security Practices for WAN and Internet Firewall

Cato also recommends these configurations for the WAN and Internet firewall to further mitigate risks:

  • Block evasive uses of DNS by restricting the DNS over HTTPS - DoH service in the firewall rulebases

  • In the Internet firewall block the Parked domain Application Category for DNS traffic

  • Block DNS rebinding attacks by defining proper WAN segmentation

Was this article helpful?

8 out of 9 found this helpful


  • Comment author
    Yaakov Simon

    Updated to add information about Cato's DNS security

  • Comment author
    Bert-Jan Kamp

    Please note that caching DNS requests for internal domains is simply NOT supported by Cato as far as I can tell. This means that in general ONLY Internet DNS requests are cached when using as a DNS server. As a result to ensure proper and swift DNS resolution for internal domains customers ALWAYS need a local DNS server or at least a regional DNS server unfortunately. The DNS KB articles are not clear about this and very ambiguous. 

    In addition configuring Global DNS servers and/or Site DNS servers does not do anything when using as the DNS server for your clients. These DNS servers ONLY have meaning when Cato performs DHCP otherwise it is NO use to configure these. This is also NOT mentioned in the DNS KB articles.

    If I am incorrect please let me know.

    At the moment when using Cato a customer WILL require local or at least regional DNS servers to serve customer domain DNS queries more quickly and Cato DNS forwarding and for client DNS should NOT be used for best performance (only as forwarders at the customer DNS servers). In principle there are a lot of improvements that can be made by Cato to speed up DNS resolution in my opinion.

  • Comment author
    Dermot - Community Manager Only 42 of these badges will be awarded.  They are reserved for people who have played a key role in helping build the Cato Community through their contributions! Community Pioneer The chief of community conversations. Community manager
    • Edited

    Hello Bert-Jan!

    My apologies that this comment was only approved now.  I will ask our documentation team to review the omissions you have highlighted.  These are:

    • DNS servers only have meaning when Cato performs DHCP
    • Need for local/regional DNS server

    The other points you raised here are best addressed via our new online community.  There is a topic "Cato Product Suggestions" that would be ideal for discussing these points further.  If you have any further questions in relation to this, please contact us via the community, or, if you prefer, via

    Kind Regards,

    Dermot Doran (Cato Networks Community Manager).

Add your comment