DNS Architecture

  • Updated on May 31, 2024
  • 7 minutes to read
  • Contributors

DNS Resolution Overview

SonicWall Cloud Secure Edge (CSE) applies Internet Threat Protection (ITP) policies to devices, which protects them from internet resources that are not maintained by a trusted organization. Depending on how a device is configured (i.e., whether it has an ITP policy associated with it), there are several different DNS resolution paths.

DNS resolution can happen through CSE’s components, the device’s default DNS resolver, or CSE’s Global DNS service. CSE’s Global DNS service works on two different IP addresses, which resolve or block any DNS requests received in accordance with the ITP policy applied.

Device Side Resolution

Encrypting DNS

In app versions >= v3.14, CSE defaults to resolving DNS over TLS, which encrypts each DNS request over the internet.

Fallback process

When sending a DNS request, CSE falls back in cases where there are DNS timeouts, adhering to the following processes:

If app is >v3.14 and the original request from the device is DNS via UDP:

  • First, try DNS over TLS;
  • Then try DNS over UDP;
  • Then try DNS over TCP;
  • Then fallback to local receiver.

If app is >v3.14 and the original request from the device is TCP via UDP:

  • First, try DNS over TLS;
  • Then try DNS over TCP;
  • Then try DNS over UDP;
  • Then fallback to local receiver.

If app is <v3.14 and the original request from the device is DNS via UDP:

  • First, try DNS over UDP;
  • Then try DNS over TCP;
  • Try DNS over TLS;
  • Then fallback to local receiver.

If app is <v3.14 and the original request from the device is TCP via UDP:

  • First, try DNS over TCP;
  • Then try DNS over UDP;
  • Try DNS over TLS;
  • Then fallback to local receiver.

DNS Resolution via CSE’s Global DNS Service

When the DNS request resolves via CSE’s Global DNS Service, the domain the end user is trying to resolve matches to an ITP Policy. CSE’s Global DNS Service will verify whether the DNS request is trying to resolve an allowed or a blocked domain, and it will fail or resolve the request accordingly. Failed requests are returned a 301 Redirect on the configured block page.

DNS Resolution via an Access Tier or the Connector

When the DNS request resolves to the Access Tier or the Connector, the domain the end user is trying to resolve matches to a private domain specified in either the org’s Access Tier or Connector configuration.

DNS Resolution via an Access Tier

When the DNS request resolves to the Access Tier, the domain the end user is trying to resolve matches to a public domain specified in either the org’s Access Tier or Connector configuration. In this case, the request is only resolved at the Access Tier because no Connector is required for routing traffic to a public domain. If the org is using Banyan’s Global Edge, then the DNS request will be resolved via the Global Edge.

DNS Resolution via default resolver

When the DNS request is resolved using the device’s default resolver, the domain the end user is trying to resolve does not match any configured Service Tunnel or ITP policy domains in the org. Alternatively, if the domain matches a local domain on the device’s LAN, it will resolve via the default resolver, even if the domain matches an ITP policy or a Service Tunnel.