Cato Networks Knowledge Base

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: 10.254.254.1 (Cato PoP DNS server) as the primary server and a list of trusted public DNS servers, such as 8.8.8.8 (Google DNS server) as the secondary. For sites in China, Cato uses 1.2.4.8 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.

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. 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 or 1.1.1.1) 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.

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.

Connectivity for SDP Users with DNS Forwarding

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 only over UDP and not over 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 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 (New) Configuring DNS Settings.

Cato DNS Security

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

    DNS_parked_domains.png
  • Block DNS rebinding attacks by defining proper WAN segmentation

Was this article helpful?

7 out of 7 found this helpful

Comments

3 comments

  • Comment author
    Yaakov Simon

    Updated to add information about Cato's DNS security

    0
  • 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 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.

    0
  • Comment author
    Community Manager The chief of community conversations. Community manager

    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 onlhy 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 people-pop@catonetworks.com.

    Kind Regards,

    Dermot Doran (Cato Networks Community Manager).

    0

Please sign in to leave a comment.