Fortinet black logo

Administration Guide

Split DNS Rules

Split DNS Rules

FortiSASE users will often need to resolve internal hostnames that are not resolvable by public DNS servers in scenarios including but not limited to:

  • When agent-based users are located within the organization’s local network, also known as being on-net, and users must use an internal DNS server instead of a public DNS server.

  • When agent-based, agentless, or site-based FortiExtender users are located remotely, FortiSASE Private Access has been configured with Secure Private Access (SPA) hubs, and users must use an internal DNS server behind the SPA hub.

To support these scenarios, FortiSASE DNS settings can be configured for split DNS using Split DNS Rules.

Split DNS works as follows:

  • Selectively use an internal DNS server only when it is necessary to resolve hostnames for the specified internal domain(s).

  • Resolve all other hostnames for external domains using the implicit DNS rule.

Split DNS is more efficient than sending all DNS requests to internal DNS servers because it reduces any potential latency and downtime with using internal DNS servers for resolving public hostnames if any issues arise with these limited availability and limited resource internal DNS server deployments. For resolving hostnames for external domains, split DNS leverages the redundancy, extensive resources, and geographical coverage of public DNS servers with anycast capabilities.

Note

For the scenario with on-net users who must use an internal DNS server to resolve hostnames for the internal domain, configuring split DNS using an internal DNS server with a private IP address and without an SPA hub configured in FortiSASE will yield inconsistent results. When an SPA hub is not configured in FortiSASE, ensure that split DNS is configured using an internal DNS server with a public IP address.

Split DNS supports using an internal DNS server with a private IP address only when an SPA hub is configured in FortiSASE.

Note

FortiSASE can connect to DNS, RADIUS, or LDAP servers with internal IP addresses or FQDNs if you set Access Type to Private in the RADIUS or LDAP server settings, internal servers are located behind a secure private access (SPA) hub, and the SPA hub in FortiSASE has been configured with BGP per overlay.

When the FortiSASE Endpoint Management Service uses LDAP servers with Groups & AD Users for endpoint profile assignments, these servers must use public IP addresses or publicly accessible FQDNs with Access Type set to Public in the LDAP server settings and may require some configuration or topology changes.

See Network restrictions removed.

To secure DNS requests, the DNS-over-HTTPS (DoH) protocol secures DNS requests and replies sent and received over HTTPS and works with public DNS servers that support this protocol. DoH is enabled by default on modern web browsers including Chrome, Edge, and Firefox and is supported by Google’s public DNS servers, which is the default for upgraded FortiSASE deployments. Therefore, for split DNS rules to work with DNS servers that support DoH, SSL deep inspection must be enabled for agent-based remote users on FortiSASE.

Prerequisites

SSL Deep Inspection

Split DNS requires SSL deep inspection to be enabled on FortiSASE so that FortiSASE can intercept the DNS traffic.

  • To confirm SSL deep inspection is enabled, go to Configuration > Security and under the SSL Inspection widget ensure Deep Inspection is displayed.

  • To enable SSL deep inspection, go to Configuration > Security and in the SSL Inspection widget click on Customize. In the SSL Inspection pane, select Deep Inspection and click OK.

See Certificate and deep inspection modes for further details on deep inspection.

Install FortiSASE CA Certificate for Agentless and Site-based FortiExtender Users

With deep inspection enabled, FortiSASE proxies traffic from the client. While being proxied, connections using secure protocols like HTTPS have their certificates replaced and signed by FortiSASE. To avoid seeing warnings and errors, the client must trust the signing Certificate Authority (CA) and have a valid certificate chain back to the root CA. Therefore, installing FortiSASE’s CA certificate on the client’s trusted certificate store is important.

FortiSASE supports automatically installing the FortiSASE CA certificate for agent-based users with FortiClient installed on their endpoints.

The FortiSASE CA certificate must be manually installed on endpoints for agentless SWG users and site-based FortiExtender users.

  • For agentless SWG users, installing this CA certificate is already part of the SWG onboarding process.

  • For endpoints using a site-based FortiExtender, installing this CA certificate is an additional step that must be performed.

See Certificate installation for installing the FortiSASE CA certificate. Although these steps are geared toward onboarding SWG users, they also apply for site-based FortiExtender users.

Access to Internal DNS Server

Ensure that your FortiSASE remote users have access to the internal DNS server.

Note

For the scenario with on-net users who must use an internal DNS server to resolve hostnames for the internal domain, configuring split DNS using an internal DNS server with a private IP address and without an SPA hub configured in FortiSASE will yield inconsistent results. When an SPA hub is not configured in FortiSASE, ensure that split DNS is configured using an internal DNS server with a public IP address.

Split DNS supports using an internal DNS server with a private IP address only when an SPA hub is configured in FortiSASE.

Note

FortiSASE can connect to DNS, RADIUS, or LDAP servers with internal IP addresses or FQDNs if you set Access Type to Private in the RADIUS or LDAP server settings, internal servers are located behind a secure private access (SPA) hub, and the SPA hub in FortiSASE has been configured with BGP per overlay.

When the FortiSASE Endpoint Management Service uses LDAP servers with Groups & AD Users for endpoint profile assignments, these servers must use public IP addresses or publicly accessible FQDNs with Access Type set to Public in the LDAP server settings and may require some configuration or topology changes.

See Network restrictions removed.

Configuring Split DNS Rules

To configure Split DNS Rules:
  1. Go to Configuration > DNS.

  2. Click Create.

  3. In the Create DNS Rule pane, enter the Primary DNS Server, (optional) Secondary DNS Server, and one or more Domains. Click + to add more fields to enter in additional domains. Click OK.

  4. Observe that the split DNS rule has been created and is displayed in the table.

Note

If you are using split DNS to resolve local domains using an internal DNS server with an SPA hub configured, then the Web Filter or DNS Filter blocks access to these local domains from FortiClient remote users if the Newly Observed Domain category is set to Block in the respective security component. In this case, you must create URL Filter entries for the Web Filter or Domain Filter entries for the DNS Filter to allow access to these local domains.

Note

If you are using split DNS to resolve local domains using an internal DNS server with an SPA hub configured, to ensure access to the internal DNS server from FortiClient remote users you must have a Private Access policy configured that allows DNS requests to that specific server.

Split DNS Rules

FortiSASE users will often need to resolve internal hostnames that are not resolvable by public DNS servers in scenarios including but not limited to:

  • When agent-based users are located within the organization’s local network, also known as being on-net, and users must use an internal DNS server instead of a public DNS server.

  • When agent-based, agentless, or site-based FortiExtender users are located remotely, FortiSASE Private Access has been configured with Secure Private Access (SPA) hubs, and users must use an internal DNS server behind the SPA hub.

To support these scenarios, FortiSASE DNS settings can be configured for split DNS using Split DNS Rules.

Split DNS works as follows:

  • Selectively use an internal DNS server only when it is necessary to resolve hostnames for the specified internal domain(s).

  • Resolve all other hostnames for external domains using the implicit DNS rule.

Split DNS is more efficient than sending all DNS requests to internal DNS servers because it reduces any potential latency and downtime with using internal DNS servers for resolving public hostnames if any issues arise with these limited availability and limited resource internal DNS server deployments. For resolving hostnames for external domains, split DNS leverages the redundancy, extensive resources, and geographical coverage of public DNS servers with anycast capabilities.

Note

For the scenario with on-net users who must use an internal DNS server to resolve hostnames for the internal domain, configuring split DNS using an internal DNS server with a private IP address and without an SPA hub configured in FortiSASE will yield inconsistent results. When an SPA hub is not configured in FortiSASE, ensure that split DNS is configured using an internal DNS server with a public IP address.

Split DNS supports using an internal DNS server with a private IP address only when an SPA hub is configured in FortiSASE.

Note

FortiSASE can connect to DNS, RADIUS, or LDAP servers with internal IP addresses or FQDNs if you set Access Type to Private in the RADIUS or LDAP server settings, internal servers are located behind a secure private access (SPA) hub, and the SPA hub in FortiSASE has been configured with BGP per overlay.

When the FortiSASE Endpoint Management Service uses LDAP servers with Groups & AD Users for endpoint profile assignments, these servers must use public IP addresses or publicly accessible FQDNs with Access Type set to Public in the LDAP server settings and may require some configuration or topology changes.

See Network restrictions removed.

To secure DNS requests, the DNS-over-HTTPS (DoH) protocol secures DNS requests and replies sent and received over HTTPS and works with public DNS servers that support this protocol. DoH is enabled by default on modern web browsers including Chrome, Edge, and Firefox and is supported by Google’s public DNS servers, which is the default for upgraded FortiSASE deployments. Therefore, for split DNS rules to work with DNS servers that support DoH, SSL deep inspection must be enabled for agent-based remote users on FortiSASE.

Prerequisites

SSL Deep Inspection

Split DNS requires SSL deep inspection to be enabled on FortiSASE so that FortiSASE can intercept the DNS traffic.

  • To confirm SSL deep inspection is enabled, go to Configuration > Security and under the SSL Inspection widget ensure Deep Inspection is displayed.

  • To enable SSL deep inspection, go to Configuration > Security and in the SSL Inspection widget click on Customize. In the SSL Inspection pane, select Deep Inspection and click OK.

See Certificate and deep inspection modes for further details on deep inspection.

Install FortiSASE CA Certificate for Agentless and Site-based FortiExtender Users

With deep inspection enabled, FortiSASE proxies traffic from the client. While being proxied, connections using secure protocols like HTTPS have their certificates replaced and signed by FortiSASE. To avoid seeing warnings and errors, the client must trust the signing Certificate Authority (CA) and have a valid certificate chain back to the root CA. Therefore, installing FortiSASE’s CA certificate on the client’s trusted certificate store is important.

FortiSASE supports automatically installing the FortiSASE CA certificate for agent-based users with FortiClient installed on their endpoints.

The FortiSASE CA certificate must be manually installed on endpoints for agentless SWG users and site-based FortiExtender users.

  • For agentless SWG users, installing this CA certificate is already part of the SWG onboarding process.

  • For endpoints using a site-based FortiExtender, installing this CA certificate is an additional step that must be performed.

See Certificate installation for installing the FortiSASE CA certificate. Although these steps are geared toward onboarding SWG users, they also apply for site-based FortiExtender users.

Access to Internal DNS Server

Ensure that your FortiSASE remote users have access to the internal DNS server.

Note

For the scenario with on-net users who must use an internal DNS server to resolve hostnames for the internal domain, configuring split DNS using an internal DNS server with a private IP address and without an SPA hub configured in FortiSASE will yield inconsistent results. When an SPA hub is not configured in FortiSASE, ensure that split DNS is configured using an internal DNS server with a public IP address.

Split DNS supports using an internal DNS server with a private IP address only when an SPA hub is configured in FortiSASE.

Note

FortiSASE can connect to DNS, RADIUS, or LDAP servers with internal IP addresses or FQDNs if you set Access Type to Private in the RADIUS or LDAP server settings, internal servers are located behind a secure private access (SPA) hub, and the SPA hub in FortiSASE has been configured with BGP per overlay.

When the FortiSASE Endpoint Management Service uses LDAP servers with Groups & AD Users for endpoint profile assignments, these servers must use public IP addresses or publicly accessible FQDNs with Access Type set to Public in the LDAP server settings and may require some configuration or topology changes.

See Network restrictions removed.

Configuring Split DNS Rules

To configure Split DNS Rules:
  1. Go to Configuration > DNS.

  2. Click Create.

  3. In the Create DNS Rule pane, enter the Primary DNS Server, (optional) Secondary DNS Server, and one or more Domains. Click + to add more fields to enter in additional domains. Click OK.

  4. Observe that the split DNS rule has been created and is displayed in the table.

Note

If you are using split DNS to resolve local domains using an internal DNS server with an SPA hub configured, then the Web Filter or DNS Filter blocks access to these local domains from FortiClient remote users if the Newly Observed Domain category is set to Block in the respective security component. In this case, you must create URL Filter entries for the Web Filter or Domain Filter entries for the DNS Filter to allow access to these local domains.

Note

If you are using split DNS to resolve local domains using an internal DNS server with an SPA hub configured, to ensure access to the internal DNS server from FortiClient remote users you must have a Private Access policy configured that allows DNS requests to that specific server.