--- title: Solving DNS Resolution Problems canonical: https://openvpn.net/as-docs/dns-resolution-problems/ product: Access Server Docs description: This topic explains how to check whether the DNS query you make from your OpenVPN client device is making it through the VPN tunnel. --- # Solving DNS Resolution Problems This guide shows you how to test whether a DNS query from an OpenVPN client device successfully goes through the VPN tunnel to the target DNS server. This helps you determine whether issues occur on the client or server side. Access Server supports pushing instructions to VPN clients to use specific DNS servers. You can configure two DNS servers using the Admin Web UI. You can configure these from the command line for advanced configurations with more than two. Access Server also supports sending additional instructions for DNS resolution zones and default domain suffixes. > **Tip** > > What's DNS? Refer to [1. What is DNS?](https://openvpn.net/as-docs/common-technical-questions/#1--what-is-dns-) > **Important** > > Operating systems handle DNS differently. Some try all DNS servers at once and accept the first response. Not all operating systems support split DNS. This guide should help you with issues that arise from these differences. ## Testing DNS resolution from a client system This section shows how to test your DNS resolution from a device connected to Access Server. ### Before you begin Ensure you've configured the DNS settings for Access Server: 1. Sign in to the Admin Web UI. 2. Select **Configuration → VPN Settings**. 3. Set **Have clients use specific DNS Servers** to **Yes** under **DNS Settings**. 4. Enter the **Primary DNS Server**. 5. Enter the **Secondary DNS Server** (optional). 6. Select **Save Settings** and **Update Running Server**. - All OpenVPN clients' DNS requests go through Access Server to the specified DNS server. For our example: - We installed OpenVPN Connect on Windows 11 and are connected to Access Server. - We set the primary DNS server to 8.8.8.8, the public Google DNS server. ### Monitor activity with tcpdump > **Note** > > In our documentation, we use example IPv4 addresses and subnets [reserved for documentation](https://en.wikipedia.org/wiki/Reserved_IP_addresses#IPv4), 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). Here, we use the tool **tcpdump** to monitor activity on TCP and UDP port 53, the default port for DNS queries. We flush the local DNS resolver cache on the client side and resolve several domains by pinging them. > **Tip** > > We only have a few connected clients in our test situation. If you're testing on a production system with many connected clients, you can append a grep filter by IP address to filter the **tcpdump** queries so they return data specific to the VPN client's IP address. **To monitor activity from the server side:** 1. Connect to the console and get root privileges. 2. Install tcpdump: ``` apt-get update apt-get install tcpdump ``` 3. After installation, run **tcpdump** with these parameters: ``` tcpdump -eni any port 53 ``` 4. (Optional) Filter by the VPN client IP address: ``` tcpdump -eni any port 53 and host 203.0.113.22 ``` **Create activity on the client side:** 1. Open a command prompt on the VPN client device. (For example, run the **cmd** program on Windows to open the command prompt app.) 2. Enter this command to wipe the DNS resolver cache so it won't pull results from its local memory: ``` ipconfig /flushdns ``` 3. Now create activity by resolving some domain names: ``` ping www.google.com ping www.openvpn.net ping www.facebook.com ``` - Each of these should yield results like this: ``` Pinging www.google.com [216.58.212.228] with 32 bytes of data: Reply from 216.58.212.228: bytes=32 time=4ms TTL=56 Reply from 216.58.212.228: bytes=32 time=3ms TTL=56 Reply from 216.58.212.228: bytes=32 time=3ms TTL=56 Reply from 216.58.212.228: bytes=32 time=3ms TTL=56 Ping statistics for 216.58.212.228: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 3ms, Maximum = 4ms, Average = 3ms ``` **View the client activity from the server:** 1. Return to your console or SSH session for Access Server. 2. If DNS resolution works correctly, you see results like this: ``` 18:03:07.976553 In ethertype IPv4 (0x0800), length 76: 203.0.113.2.49531 > 8.8.8.8.53: 53268+ A? www.google.com. (32) 18:03:07.976579 Out 00:0c:29:c7:60:e9 ethertype IPv4 (0x0800), length 76: 192.0.2.133.49531 > 8.8.8.8.53: 53268+ A? www.google.com. (32) 18:03:07.981162 In 34:31:c4:8e:b5:67 ethertype IPv4 (0x0800), length 92: 8.8.8.8.53 > 192.0.2.133.49531: 53268 1/0/0 A 216.58.211.100 (48) 18:03:07.981181 Out ethertype IPv4 (0x0800), length 92: 8.8.8.8.53 > 203.0.113.2.49531: 53268 1/0/0 A 216.58.211.100 (48) ``` The VPN client at 203.0.113.2 sent a DNS request to Access Server. Access Server sent the request to the DNS server at 8.8.8.8, to find the A record (IP address for the DNS name www.google.com. The request went out through the network interface with the MAC address 00:0c:29:c7:60:e9, the Access Server network interface that goes to the internet since the 8.8.8.8 DNS server is on the internet. This line shows a DNS result received. This line shows the result relayed back to the VPN client. ## Split-DNS when using DNS resolution zones Access Server supports split DNS, which resolves only certain zones (domains) through a DNS server pushed by the VPN server and the rest through your existing local DNS servers. ### Configure split-DNS in Access Server 1. Sign in to the Admin Web UI. 2. Select **Configuration → VPN Settings**. 3. Enter a single domain or list of comma-separated domains for **DNS Resolution Zones**. 4. Select **Save Settings** and **Update Running Server**. - Clients will receive an instruction to resolve those domains through the DNS server pushed by Access Server and resolve the rest through the client's local DNS server. - When you use split DNS, you don't see the pushed DNS server in your ipconfig output. The DNS server isn't implemented at the network interface configuration level. Instead, it's implemented in the DNS system in a DNS resolution policy table. > **Note** > > Not all OpenVPN clients support this, and there are some differences in behavior between versions of OpenVPN. You can achieve the best results with OpenVPN Connect v3. > **Tip** > > To query this, you can use the **scutil** command-line utility on macOS or **netsh** on Windows. You can also use PowerShell on Windows, which we cover further down. ### Split DNS example Here, we give an example of how split DNS and normal DNS resolution look through the VPN tunnel. Commands to see network configuration and DNS resolution policy on Windows: ``` ipconfig /all netsh namespace show effectivepolicy ``` Commands to see network configuration and DNS resolution policy on macOS: ``` ifconfig scutil -dns ``` Example output on Windows when split DNS is currently in use: ``` (OpenVPN) adapter Local Area Connection: Description . . . . . . . . . . . : TAP-Windows Adapter V9 for OpenVPN Connect DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1 fec0:0:0:ffff::2%1 fec0:0:0:ffff::3%1 Ethernet adapter Ethernet: Description . . . . . . . . . . . : Intel(R) 82574L Gigabit Network Connection DNS Servers . . . . . . . . . . . : 192.0.2.254 DNS Effective Name Resolution Policy Table Settings Settings for .openvpn.net ---------------------------------------------------------------------------- Generic (DNS Servers) : 1.2.3.4 ``` The local DNS server handling most requests: **Ethernet** at 192.0.2.254. The DNS server pushed by Access Server to resolve requests for the zone **.openvpn.net**: 1.2.3.4. In our example, \*.openvpn.net is resolved through the VPN DNS server. All others resolve through the local DNS server 192.0.2.254. > **Note** > > The VPN interface gets three IPv6 self-assigned DNS server addresses. The operating system assigns these, not OpenVPN, and they shouldn't affect DNS resolution. Example output on Windows when split DNS isn't used: ``` (OpenVPN) adapter Local Area Connection: Description . . . . . . . . . . . : TAP-Windows Adapter V9 for OpenVPN Connect DNS Servers . . . . . . . . . . . : 1.2.3.4 DNS Effective Name Resolution Policy Table Settings Settings for . ---------------------------------------------------------------------------- Generic (DNS Servers) : 1.2.3.4 ``` The DNS server is assigned to the network adapter as the only top-level zone for DNS resolution. All DNS queries get redirected to the server at 1.2.3.4. ### Split DNS commands for PowerShell on Windows You can run the following commands as an administrator in PowerShell. - Commands to see the network configuration and DNS resolution policy: ``` Get-NetIPConfiguration Get-DnsClientServerAddress Get-DnsClientNrptPolicy Get-DnsClientNrptRule ``` - Example output on Windows when split DNS is used: ``` PS C:\Users> Get-NetIPConfiguration InterfaceAlias : Local Area Connection InterfaceIndex : 4 InterfaceDescription : TAP-Windows Adapter V9 for OpenVPN Connect DNSServer : fec0:0:0:ffff::1 fec0:0:0:ffff::2 fec0:0:0:ffff::3 InterfaceAlias : Ethernet InterfaceIndex : 6 InterfaceDescription : Intel(R) 82574L Gigabit Network Connection DNSServer : 192.0.2.254 PS C:\Users> Get-DnsClientServerAddress InterfaceAlias Interface Address ServerAddresses Index Family -------------- --------- ------- --------------- Local Area Connection 4 IPv6 {fec0:0:0:ffff::1, fec0:0:0:ffff::2, fec0:0:0:ffff::3} Ethernet 6 IPv4 {192.0.2.254} PS C:\Users> Get-DnsClientNrptPolicy Namespace : .openvpn.net QueryPolicy : NameServers : {1.2.3.4} ``` - Example output on Windows when split DNS isn't used: ``` PS C:\Users> Get-NetIPConfiguration InterfaceAlias : Local Area Connection InterfaceIndex : 4 InterfaceDescription : TAP-Windows Adapter V9 for OpenVPN Connect DNSServer : 1.2.3.4 PS C:\Users> Get-DnsClientServerAddress InterfaceAlias Interface Address ServerAddresses Index Family -------------- --------- ------- --------------- Local Area Connection 4 IPv4 {1.2.3.4} PS C:\Users> Get-DnsClientNrptPolicy PS C:\Users> Get-DnsClientNrptRule PS C:\Users> ``` ## Using default domain suffix Access Server supports setting a default suffix so Windows clients can resolve host names to fully qualified domain names (FQDN). This feature is helpful for a network using a Windows Domain or Active Directory server. You configure this in Access Server: 1. Sign in to the Admin Web UI. 2. Select **Configuration → VPN Settings**. 3. Enter a default suffix for **Default Domain Suffix**. 4. Select **Save Settings** and **Update Running Server**. - Windows clients will receive an instruction to resolve host names to FQDN names. After configuring the default domain suffix, you can test it from one of your Windows clients. You can run a command from Command Prompt or PowerShell. - Command to see the default domain suffix using the command prompt: ``` ipconfig /all ``` - Commands to see the default domain suffix using PowerShell: ``` Get-DnsClient Get-DnsClientGlobalSetting ``` - Example output when a default domain suffix is in use via command prompt: ``` PS C:\Users> ipconfig /all Windows IP Configuration DNS Suffix Search List: openvpn.net Local Area Connection Adapter: Connection-specific DNS Suffix. . : openvpn.net Description . . . . . . . . . . . . . . . : TAP-Windows Adapter V9 for OpenVPN Connect ``` - Example output when a default domain suffix is in use via PowerShell: ``` PS C:\Users> Get-DnsClient InterfaceAlias Interface ConnectionSpecificSuffix ConnectionSpecificSuffix RegisterThisConn UseSuffixWhen Index SearchList ectionsAddress Registering -------------- --------- ------------------------ ------------------------ ---------------- ------------- Local Area Connection 4 openvpn.net {} True False ``` ## Additional troubleshooting Below are additional troubleshooting tips for DNS server issues. ### Ping request could not find domain (…). Please check the name and try again You may encounter this if the client DNS server doesn't know the domain you are trying to resolve, can't be reached, or isn't correctly configured. **If the DNS server doesn't know the domain** A local DNS server in your network may only resolve local names or be limited to a particular DNS zone. - Here's an example of an output showing a domain the DNS server can't resolve: ``` 18:07:10.082330 In ethertype IPv4 (0x0800), length 94: 203.0.113.2.54519 > 8.8.8.8.53: 50281+ A? thisdomainreallydoesnotexist.com. (50) 18:07:10.082356 Out 00:0c:29:c7:60:e9 ethertype IPv4 (0x0800), length 94: 192.0.2.133.54519 > 8.8.8.8.53: 50281+ A? thisdomainreallydoesnotexist.com. (50) 18:07:10.082507 In ethertype IPv4 (0x0800), length 94: 203.0.113.2.57858 > 8.8.8.8.53: 65054+ AAAA? thisdomainreallydoesnotexist.com. (50) 18:07:10.082521 Out 00:0c:29:c7:60:e9 ethertype IPv4 (0x0800), length 94: 192.0.2.133.57858 > 8.8.8.8.53: 65054+ AAAA? thisdomainreallydoesnotexist.com. (50) 18:07:10.103610 In 34:31:c4:8e:b5:67 ethertype IPv4 (0x0800), length 167: 8.8.8.8.53 > 192.0.2.133.54519: 50281 NXDomain 0/1/0 (123) 18:07:10.103641 Out ethertype IPv4 (0x0800), length 167: 8.8.8.8.53 > 203.0.113.2.54519: 50281 NXDomain 0/1/0 (123) ``` The **NXDomain** output is like saying, "We can't find the answer to your question." We purposefully selected a name for our example that didn't exist, so we got this error. - You could resolve the issue by configuring the DNS server to forward DNS queries to a public DNS server. That way, the DNS server can respond to both queries for local names and public names. Then, you can run **tcpdump** as described above. **If the DNS server can't be reached** If a query arrives at the VPN client, passes through Access Server, and out to the internet, but there's no reply, the DNS server is unreachable or not a DNS server. - Here's an example of an output showing that situation: ``` 18:19:29.935439 Out 00:0c:29:c7:60:e9 ethertype IPv4 (0x0800), length 76: 192.0.2.133.60180 > 1.2.3.4.53: 16427+ AAAA? www.google.com. (32) 18:19:29.935479 In ethertype IPv4 (0x0800), length 76: 203.0.113.3.51334 > 1.2.3.4.53: 37513+ A? www.google.com. (32) ``` For our example, we used the IP address 1.2.3.4, which isn't a real DNS server. The query repeats a few times but ultimately fails. - To resolve this issue, you may need to do one of the following, depending on what's causing the unreachable server: 1. Choose a DNS server that works. 2. Ensure no firewall is blocking traffic between the VPN client and the DNS server. 3. Check for missing routes (if you're using routing instead of NAT for Access Server) and [implement static routes for direct VPN client communication](https://openvpn.net/as-docs/tutorials/tutorial--reach-openvpn-clients-private-network.md) or switch to NAT. 4. Check if the built-in Windows firewall is blocking queries from a subnet outside the local network on Windows Server platforms. 5. If you use private IP addresses for a DNS server, ensure that it doesn't belong to one of the VPN subnets. --- Prev: [VPN Destination](https://openvpn.net/as-docs/vpn-destination-issues.md) Next: [SSL Certificates](https://openvpn.net/as-docs/ssl-certificates-130917.md) Index: https://openvpn.net/as-docs/llms.txt