Skip to main content

Tutorial: Configure Split DNS and Domain Suffix

Abstract

Learn how to configure Split DNS in Access Server, including routing DNS traffic through the VPN, resolving specific domains, and setting domain suffixes — with practical configuration examples.

Overview

Split DNS and domain suffix settings determine how VPN clients resolve DNS queries when connected to Access Server.

This tutorial demonstrates three common deployment scenarios:

  • Route all DNS queries through the VPN.

  • Route DNS queries for specific domains through the VPN (Split DNS).

  • Use a domain suffix to resolve short hostnames to fully qualified domain names (FQDNs).

Prerequisites

  • Access Server 3.1.0+ installed.

  • Administrator access to the Admin Web UI.

  • Root access to the Access Server console (for the CLI verification steps).

  • One or more users or groups configured.

  • Split-tunnel routing enabled.

  • Internal DNS servers available.

Important

For Access Server 3.1.0 and newer, Split DNS (DNS resolution zones) is only pushed to clients when both of the following are true:

  • DNS Server Proxy is set to Auto.

  • No domain routing rules are applied to the user (at the global, group, or user level).

If a user has domain routing rules applied, Access Server doesn't push DNS resolution zones to that user's client, and the Split DNS examples below won't take effect. For more on these settings, see Tutorial: Configure DNS Settings in Access Server.

Note

In our documentation, we use example IPv4 addresses and subnets reserved for documentation, such as 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24.

Ensure you replace them with valid IPv4 addresses and subnets for your network(s).

Example 1: Route all DNS queries through the VPN

Scenario

Your organization uses split-tunnel routing, but you want VPN clients to send all DNS queries to your internal DNS servers (192.0.2.5 and 192.0.2.6) through the VPN.

Step 1: Configure DNS servers

  1. Sign in to the Admin Web UI.

  2. Navigate to Access Controls → Internet Access and DNS.

  3. Under Internet gateway, select Split-Tunnel.

  4. Under DNS Servers, clear Use detected DNS servers.

  5. Remove any listed DNS servers and add your internal DNS servers (192.0.2.5 and 192.0.2.6).

  6. Select Save and Restart.

Step 2: Verify the configuration

  1. Connect to the VPN.

  2. Check the VPN client logs. You should see the internal DNS servers pushed to the client:

    18 [dhcp-option] [DNS] [192.0.2.5]
19 [dhcp-option] [DNS] [192.0.2.6]

  3. Check the client routing table on the VPN client device. You should see routes for the internal DNS servers pointing to the tunnel:

    192.0.2.5  255.255.255.255
192.0.2.6  255.255.255.255

Example 2: Route DNS queries for a specific domain through the VPN (Split DNS)

Scenario

Your organization hosts customdomain.example.com internally. Only queries for this domain should use the VPN and internal DNS servers. All other DNS queries should continue using the client's local DNS server.

Step 1: Configure Split DNS

  1. Sign in to the Admin Web UI.

  2. Navigate to Access Controls → Internet Access and DNS.

  3. Under Internet gateway, select Split-Tunnel.

  4. Under DNS Servers, clear Use detected DNS servers.

  5. Remove any listed DNS servers and add your internal DNS servers (192.0.2.5 and 192.0.2.6).

  6. Under DNS resolution zones (optional), add the internal domain (customdomain.example.com) that you want resolved only by the internal DNS servers.

    Tip

    This setting also works as a wildcard domain. DNS queries for both customdomain.example.com and *.customdomain.example.com are resolved by the internal DNS servers.

  7. Select Save and Restart.

Step 2: Verify the client configuration

  1. Connect to the VPN.

  2. Check the VPN client logs. You should see the internal DNS servers and the DNS resolution zone domain pushed to the client:

    18 [dhcp-option] [DNS] [192.0.2.5]
19 [dhcp-option] [DNS] [192.0.2.6]
20 [dhcp-option] [DOMAIN] [customdomain.example.com]

  3. Verify the internal DNS servers have routes in the client routing table. You should see routes pointing to the tunnel:

    192.0.2.5  255.255.255.255
192.0.2.6  255.255.255.255

  4. Verify the DNS resolution zone is configured properly. On Windows, run the following command as an administrator in PowerShell:

    Get-DnsClientNrptPolicy

    • Example output:

      PS C:\Windows\system32> Get-DnsClientNrptPolicy


Namespace                        : .customdomain.example.com
QueryPolicy                      :
SecureNameQueryFallback          :
DirectAccessIPsecCARestriction   :
DirectAccessProxyName            :
DirectAccessDnsServers           :
DirectAccessEnabled              :
DirectAccessProxyType            : NoProxy
DirectAccessQueryIPsecEncryption :
DirectAccessQueryIPsecRequired   : False
NameServers                      : {192.0.2.5, 192.0.2.6}
DnsSecIPsecCARestriction         :
DnsSecQueryIPsecEncryption       :
DnsSecQueryIPsecRequired         : False
DnsSecValidationRequired         : False
NameEncoding                     : Utf8WithoutMapping

      Tip

      This example uses a PowerShell command from Windows. On macOS, use scutil --dns.

Step 3: Verify Split DNS traffic

  1. Connect a VPN client to the server.

  2. On the console for the machine hosting Access Server, start a packet capture:

    tcpdump -eni any port 53

  3. From the VPN client, run:

    ping customdomain.example.com

    • Example output from the VPN client:

      PS C:\Windows\system32> ping customdomain.example.com

Pinging customdomain.example.com [192.0.2.20] with 32 bytes of data:
Reply from 192.0.2.20: bytes=32 time=28ms TTL=57
Reply from 192.0.2.20: bytes=32 time=26ms TTL=57
Reply from 192.0.2.20: bytes=32 time=26ms TTL=57
Reply from 192.0.2.20: bytes=32 time=27ms TTL=57

Ping statistics for 192.0.2.20:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 26ms, Maximum = 28ms, Average = 26ms

    • Example output from the tcpdump on Access Server:

      12:07:40.451498 as0t2 In  ifindex 686 ethertype IPv4 (0x0800), length 75: 172.27.232.5.52089 > 192.0.2.5.53: 46505+ A? customdomain.example.com. (27)
12:07:40.451534 eth0  Out ifindex 2 2a:db:03:a7:44:c9 ethertype IPv4 (0x0800), length 75: 192.0.2.2.52089 > 192.0.2.5.53: 46505+ A? customdomain.example.com. (27)
12:07:40.473124 eth0  In  ifindex 2 fe:00:00:00:01:01 ethertype IPv4 (0x0800), length 91: 192.0.2.5.53 > 192.0.2.2.52089: 46505 1/0/0 A 192.0.2.20 (43)
12:07:40.473174 as0t2 Out ifindex 686 ethertype IPv4 (0x0800), length 91: 192.0.2.5.53 > 172.27.232.5.52089: 46505 1/0/0 A 192.0.2.20 (43)

This ensures DNS traffic for the specified domain is routed through the VPN tunnel. If you ping another domain, you won't see anything in the tcpdump output, because only DNS queries for customdomain.example.com are sent to the tunnel.

Example 3: Configure a domain suffix

Scenario

Users should be able to connect to customdomain instead of typing customdomain.example.com, while ensuring DNS queries for example.com continue to use the internal DNS servers.

Step 1: Configure a domain suffix

  1. Sign in to the Admin Web UI.

  2. Navigate to Access Controls → Internet Access and DNS.

  3. Under Internet gateway, select Split-Tunnel.

  4. Under DNS Servers, clear Use detected DNS servers.

  5. Remove any listed DNS servers and add your internal DNS servers (192.0.2.5 and 192.0.2.6).

  6. Under Default Domain Suffix (optional), enter the internal domain (example.com) you want short hostnames to autocomplete to as an FQDN.

  7. Under DNS resolution zones (optional), add the internal domain (example.com) you want resolved only by the internal DNS servers.

    Tip

    This setting also works as a wildcard domain. DNS queries for both example.com and *.example.com are resolved by the internal DNS servers.

  8. Select Save and Restart.

Step 2: Verify the client configuration

  1. Connect to the VPN.

  2. Check the VPN client logs. You should see the internal DNS servers, the DNS resolution zone, and the domain suffix pushed to the client:

    18 [dhcp-option] [DNS] [192.0.2.5]
19 [dhcp-option] [DNS] [192.0.2.6]
20 [dhcp-option] [DOMAIN] [example.com]
21 [dhcp-option] [ADAPTER_DOMAIN_SUFFIX] [example.com]

  3. Verify the internal DNS servers have routes in the client routing table. You should see routes pointing to the tunnel:

    192.0.2.5  255.255.255.255
192.0.2.6  255.255.255.255

  4. Verify the DNS resolution zone is configured properly. On Windows, run the following command as an administrator in PowerShell:

    Get-DnsClientNrptPolicy

    • Example output:

      PS C:\Windows\system32> Get-DnsClientNrptPolicy


Namespace                        : .example.com
QueryPolicy                      :
SecureNameQueryFallback          :
DirectAccessIPsecCARestriction   :
DirectAccessProxyName            :
DirectAccessDnsServers           :
DirectAccessEnabled              :
DirectAccessProxyType            : NoProxy
DirectAccessQueryIPsecEncryption :
DirectAccessQueryIPsecRequired   : False
NameServers                      : {192.0.2.5, 192.0.2.6}
DnsSecIPsecCARestriction         :
DnsSecQueryIPsecEncryption       :
DnsSecQueryIPsecRequired         : False
DnsSecValidationRequired         : False
NameEncoding                     : Utf8WithoutMapping

    Tip

    This example uses a PowerShell command from Windows. On macOS, use scutil --dns.

  5. Verify the domain suffix is configured properly. On Windows, run the following command as an administrator in PowerShell:

    Get-DnsClient

    • Example output:

      PS C:\Windows\system32> Get-DnsClient

InterfaceAlias               Interface ConnectionSpecificSuffix ConnectionSpecificSuffix RegisterThisConn UseSuffixWhen
                             Index                              SearchList               ectionsAddress   Registering
--------------               --------- ------------------------ ------------------------ ---------------- -------------
Local Area Connection               18 example.com              {}                       True             False

    Tip

    This example uses a PowerShell command from Windows. On macOS, use scutil --dns.

Step 3: Verify name resolution

  1. Connect a VPN client to the server.

  2. On the console for the machine hosting Access Server, start a packet capture:

    tcpdump -eni any port 53

  3. From the VPN client, run:

    ping customdomain

    • Example output from the VPN client:

      PS C:\Windows\system32> ping customdomain

Pinging customdomain.example.com [192.0.2.20] with 32 bytes of data:
Reply from 192.0.2.20: bytes=32 time=28ms TTL=57
Reply from 192.0.2.20: bytes=32 time=26ms TTL=57
Reply from 192.0.2.20: bytes=32 time=26ms TTL=57
Reply from 192.0.2.20: bytes=32 time=27ms TTL=57

Ping statistics for 192.0.2.20:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 26ms, Maximum = 28ms, Average = 26ms

    • Example output from the tcpdump on Access Server:

      12:07:40.451498 as0t2 In  ifindex 686 ethertype IPv4 (0x0800), length 75: 172.27.232.5.52089 > 192.0.2.5.53: 46505+ A? customdomain.example.com. (27)
12:07:40.451534 eth0  Out ifindex 2 2a:db:03:a7:44:c9 ethertype IPv4 (0x0800), length 75: 192.0.2.2.52089 > 192.0.2.5.53: 46505+ A? customdomain.example.com. (27)
12:07:40.473124 eth0  In  ifindex 2 fe:00:00:00:01:01 ethertype IPv4 (0x0800), length 91: 192.0.2.5.53 > 192.0.2.2.52089: 46505 1/0/0 A 192.0.2.20 (43)
12:07:40.473174 as0t2 Out ifindex 686 ethertype IPv4 (0x0800), length 91: 192.0.2.5.53 > 172.27.232.5.52089: 46505 1/0/0 A 192.0.2.20 (43)

The short hostname resolves to its FQDN, and the DNS traffic is routed through the VPN tunnel. If you ping a host outside the configured domain, you won't see anything in the tcpdump output, because only DNS queries for *.example.com are sent to the tunnel.

Next steps

For related DNS and routing configuration, see:

In this section: