Cato Networks can provide DNS service for your account and act as your DNS server. By default, Cato uses the following DNS servers: 10.254.254.1 (Cato PoP DNS server) as the primary server and 8.8.8.8 (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 8.8.8.8, 1.1.1.1, and 9.9.9.9.
This section contains best practices and recommendations for configuring DNS with Cato and can help you achieve more security, redundancy, and better performance.
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.
Cato recommends that you configure two different DNS servers for redundancy. If you are using an internal DNS server, set your internal DNS server as the primary and a public DNS server (Cato's trusted DNS servers are: 8.8.8.8, 1.1.1.1, and 9.9.9.9) 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 don’t have an internal DNS server, we recommend that you use Cato’s default DNS servers and don't configure the DNS settings.
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.
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.
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:
The DNS Forwarding feature lets you achieve connectivity to local domains in your network.
SDP 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 configured DNS internal server. The server resolves it and lets SDP users connect to corporate internal resources.
Notes:
-
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
For network rules and firewall rules that are based on DNS (for example TLD, FQDN, and applications), the DNS traffic must be routed to Cato service. If the DNS traffic isn’t routed through Cato, these DNS based rules aren’t applied. Therefore, if you have an internal DNS server, you must forward the DNS to Cato or use Cato’s DNS server. For more about configuring the DNS settings, see Configuring DNS Settings.
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.
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
-
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
3 comments
Updated to add information about Cato's DNS security
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 10.254.254.1 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 10.254.254.1 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 10.254.254.1 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.
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:
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 community@catonetworks.com
Kind Regards,
Dermot Doran (Cato Networks Community Manager).
Please sign in to leave a comment.