11 solutions to troubleshooting DNS Resolution

1. Check the network connection

In many cases when you open the Web browser and enter a URL into it, the URL fails to access the Web. This case causes you to think first because of a DNS error. But in fact, in this case the cause may be due to your network connection.

This is even more true if you use a laptop and connect to the network using Wi-Fi. With the wireless security protocol, the key will be "negotiated" or the signal strength of the radio waves will be weakened, resulting in a lost network connection.

The cause of network loss may occur on any type of network.

In other words, before blaming DNS, start troubleshooting by checking "OSU Layer 1 - Physical" first and then checking your network connection.

11 solutions to troubleshooting DNS Resolution Picture 1
Figure 1: Wireless network connection is still in good condition

Notice how Access is Local and Internet . If Access is displayed as Local , it means that your network address is invalid (in this case, you have only one APIPA starting with address 169.xxx).

Next you need to make sure you have a valid IP address on the network. You can check your IP address by going to the View Status then selecting Details , checking the IP address and confirming the DNS Server's IP address. If your IP address is 169.xxx , you cannot connect to the Internet.

11 solutions to troubleshooting DNS Resolution Picture 2
Figure 2: Verifying your IP address and DNS Server IP addresses

2. Confirm the IP address of the DNS Server is "standard" and in the correct order

After you have a valid IP address and can connect to the Internet, you can now drill down into the internal DNS problems by confirming whether the DNS server's IP address is correct and correct. .

If you look at Figure 2 above, you can see the IP address of IPv4 DNS Server. Note that the IP address of IPv4 DNS Server IP includes Local LAN / Subnet so you can access it, even if the default port is broken.

This is how it works on most enterprise networks. However, your DNS servers are not always on the subnet. In fact, for most ISPs, the IPs of the DNS Server do not even reside on the same subnet as the default gateway.

In most home or small and medium-sized router (home / SMB) configurations, there are no separate DNS servers and SMB routers that will proxy DNS to real DNS servers. In that case, the DNS Server's IP address can be associated with your Router IP address.

Finally, make sure your DNS Server is in the correct order. In the case shown in Figure 2, the internal DNS Server is 10.0.1.20. It is configured to 'forward' all domains that cannot be resolved to 10.0.1.1, the internal router address. That router will proxy the DNS to the ISP's DNS Server. We can look up those DNS Servers on our router, as shown in Figure 3.

11 solutions to troubleshooting DNS Resolution Picture 3
Figure 3: DNS servers received from ISP via DHCP

First, make sure your DNS Server is in the correct order. If you have a local DNS Server, like this and are looking up the local DNS name, want the PC client to look up that local DNS name in the local DNS Server first, before the Internet DNS Server. Your local DNS server must first be in the DNS settings.

Second, you can ping the ISP's DNS Server IP address. In this way, as long as the listed DNS servers are on your router, you can verify that you can ping them even from your local computer:

Notice the response time when pinging to ISP's DNS Server. This process may slow down DNS lookups or may even fail if it takes too long for the DNS server to respond.

11 solutions to troubleshooting DNS Resolution Picture 4
Figure 4: Ping the ISP's DNS Server

Notice the response time from your ping action to the ISP's DNS Server. This may slow down DNS lookups or may even fail if it takes too long for the DNS server to respond.

3. Ping the IP address of the host you want (if you know it)

A quick way to prove that the error is due to DNS, not because of a network connection problem, is to ping the Host's IP address you want to access. If the connection to the domain fails, the connection to the IP address successfully means that your problem is in DNS.

However, if your DNS Server is not working, it is difficult to specify what IP address you are connecting to. To perform this test, you must have a diagram (diagram) of the network or like many Administrators still perform, just remember the IP address of the host.

If you work, wait until the DNS server is available again, you can place an entry in your hosts file to map the IP to the hostname.

4. Find the DNS server that is being used by nslookup

You can use the nslookup command to find information about your DNS resolution. One of the simplest ways is to use this command to see which DNS server is providing you with an answer and a DNS server.

11 solutions to troubleshooting DNS Resolution Picture 5
Figure 5: Output of nslookup command

Note in Figure 5, the ISP's DNS server provides us with 'non-authoritative answer' information, meaning that it does not configure the domain but can still provide a response.

You can also use this command to compare responses from different DNS servers by providing which DNS server to use.

5. Check DNS suffix

If you are looking up a local host on a DNS server where your computer is a member in it, then you can connect to a host, without using FQDN (fully qualified DNS name) and hopefully The suffix of DNS can help you find the problem.

For example, if we connect to 'server1', the DNS server may have multiple entries for that domain. Your Network Adapter will then be configured with a DNS connection suffix.

For example, the example in Figure 2, the DNS is wiredbraincoffee.com. So whenever you enter a domain name like server1, the DNS suffix will be added to its end to form server1.wiredbraincoffee.com.

You should confirm your DNS suffix is ​​correct.

6. Make sure your DNS settings are configured to 'pull' the DNS's IP from the DHCP server

Just like when you want your Network Adapter to 'capture the DNS Server IP addresses from the DHCP Server. If you look at the image above, you can see that this adapter has been specified with the DNS Server IP addresses.

11 solutions to troubleshooting DNS Resolution Picture 6
Figure 6: Verifying the settings of the DNS Server

You must change 'Obtain DNS server address automatically' in order to get the new DNS server DNS. To do so, simply open the Network Adapter's Properties tab , then click Internet Protocol Version 4 (TCP / IPv4).

7. Free and 'refresh' the IP address of the DHCP Server (and also DNS information)

Although your Adapter has been set up to pull DNS information from DHCP, in some cases it may result in IP address conflicts or old DNS server information. So after choosing to 'acquire' your IP address and DNS automatically, you should 'free' your IP address and renew it.

You can do this with Windows Diagnosis in your Network configuration. However, the fastest way is to use the Command prompt. If you have enabled UAC, run the Windows cmd command under Amin:

IPCONFIG / RELEASE

IPCONFIG / RENEW

Then, do it with the IPCONFIG / ALL command to see how new IP and DNS information is.

8. Check the DNS Server and restart the service or reboot if necessary

Obviously, if the DNS server crashes or is corrupted, or configured incorrectly, you will not be able to fix that at the Client side. However, you can bypass the server with that error and cannot fix the error.

That way, Admin - who is responsible for the DNS server, must check the status and configuration of the DNS server to resolve DNS issues.

9. Restart the DNS router for small office or home

As mentioned above in the second way and shown in the third illustration, on home and small office routers, DNS server settings are usually done via DHCP with the DNS server setting up a The router and router's IP address will proxy DNS to the ISP's DNS server.

However, your local computer may have network information (including DNS server IP addresses), but there are cases where your router has incorrect information. To ensure that your router has the latest DNS server information, you can perform a 'release' of a DHCP and 'renew - refresh' the router's WAN interface with the ISP. Or an easier way might be to reboot the router so that it gets the latest information.

10. Contact ISP

We all know how tired it is to contact an ISP to fix a network problem. However, if your computer still has DNS resolution problems from ISP's DNS servers, you need to contact them, and that's the final solution.

11. Check DNS Resolution from a client system

Companies often run their own DNS servers and use it to resolve DNS names to private IP addresses, to make it easier for users to access the system. A simple example to imagine is to ask a user to start their Remote Desktop client program and connect to server1 instead of connecting to 192.168.70.243.

The OpenVPN Access Server supports pushing a command to an connected OpenVPN client to use a specific DNS server. In fact it supports pushing 2 DNS servers, in case the first server is not responding. This can be configured in Admin UI (administrative user interface) under the VPN Settings section . Access Server also supports sending additional instructions to the DNS Resolution Zones , which functions like a DNS split, but only queries for a specific DNS zone sent to the VPN server and DNS Default Suffix (Late). DNS element), provide suggestions for Windows to 'auto-complete' the server name into Fully Qualified Domain Name or FQDN.

Unfortunately, not all operating systems work the same, in terms of DNS. Some systems will try all DNS servers at the same time and accept the first response server. Other servers will be able to do DNS division, and others will not. This may lead to certain problems. The instructions below provide a way to check whether the DNS query you are executing from an OpenVPN client is running through VPN tunnel to the OpenVPN Access Server. And from there, of course, will reach the destination DNS server. This information is valuable in determining whether the client side has a problem, or a server error.

The article assumes that you have a DNS server configured in the Admin Server of the Access Server, under the VPN Settings section. Assume that you do not use DNS Resolution Zones or DNS Default Suffix fields. With this setting, all DNS requests will be transferred from the OpenVPN client, via the OpenVPN Access Server, and then to the designated DNS server. In the example in this article, we are pushing the Google Public DNS server 8.8.8.8 and the test results will also reflect this in the sample outputs.

Please install the OpenVPN program on the selected guest system. In the example in this article, we will use a Windows 10 Professional client system with the OpenVPN Connect Client installed and connected to the OpenVPN Access Server. Next, open a console session or SSH session to the OpenVPN Access Server and receive root privileges. We will use the tcpdump tool to monitor activity on port 53 TCP and UDP, the default port where DNS queries are processed. We will clear the local DNS resolver cache on the client side, then resolve some domain names simply by pinging them by name.

In this test situation, only a handful of clients are connected and the performance of DNS queries is very low, so that readers can follow it easily. If you are testing on a production system and the tcpdump command for too many outputs, you can append a filter to grep by IP address, to filter queries only from the IP address of a specific VPN client, to read and locate DNS query results more easily.

On the Access Server, run the following commands:

 apt-get update apt-get install tcpdump 

With TCPdump installed, run it with the following parameters:

 tcpdump -eni any port 53 

Or, if you want to filter it by the VPN client's IP address (adjust as needed):

 tcpdump -eni any port 53 | grep "172.27.10.22" 

After running this command in the background, go to your VPN client operating system, and open a command prompt. On Windows, for example, you can run cmd to open an old-style DOS prompt . When open, use the following commands to clear the local DNS resolver cache, so it will not retrieve the results from its own local memory, then execute the actual query.

Delete local DNS resolver cache on Windows:

 ipconfig /flushdns 

Resolution some domain names:

 ping www.google.com ping www.openvpn.net ping www.facebook.com 

Each of these domain names will yield results that look 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 

On the OpenVPN Access Server, you will see the results look like this:

 18:03:07.976553 In ethertype IPv4 (0x0800), length 76: 172.27.232.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.168.47.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.168.47.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 > 172.27.232.2.49531: 53268 1/0/0 A 216.58.211.100 (48) 

The above result from tcpdump shows that a DNS request was received from the VPN client at 172.27.232.2, and it was redirected to the DNS server at 8.8.8.8. The request is to find the A record (IP address) for the DNS name www.google.com. The first line shows that this request is going to the OpenVPN Access Server, from the VPN client. The second line shows the request to leave the server through the network interface, with MAC address 00: 0c: 29: c7: 60: e9. In the test setup in this article, this is the network interface of the Access Server going to the Internet. This means that the 8.8.8.8 DNS server is available on the Internet. The third line shows the DNS results that have been received and the fourth line shows that the result has been forwarded back to the VPN client. In this case, DNS resolution is working.

Common errors and causes

Here are some common issues and where you can find a solution to handle.

Ping request không tìm thấy Domain (.).

Solution : Please check the name and try again.

This can happen when the DNS server your client system is using is poorly configured, inaccessible, or if the DNS server you are using does not know what domain you are trying to resolve. For example, with local DNS servers in your network, chances are they only know local computer systems and have no knowledge of online names like openvpn.net or something like that. Usually in this case, you can configure the DNS server to forward DNS queries to a public DNS server without knowing the answers to those queries, so that it can answer both queries. for local name and public name. A useful step in this situation might be to re-run tcpdump as described in the DNS resolution test section from the client system section above, and check what tcpdump 's output is.

If you see the following result:

 18:07:10.082330 In ethertype IPv4 (0x0800), length 94: 172.27.232.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.168.47.133.54519 > 8.8.8.8.53: 50281+ A? thisdomainreallydoesnotexist.com. (50) 18:07:10.082507 In ethertype IPv4 (0x0800), length 94: 172.27.232.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.168.47.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.168.47.133.54519: 50281 NXDomain 0/1/0 (123) 18:07:10.103641 Out ethertype IPv4 (0x0800), length 167: 8.8.8.8.53 > 172.27.232.2.54519: 50281 NXDomain 0/1/0 (123) 

Specifically, NXDomain section here is very important. It means that this DNS server does not know the domain name we are trying to resolve. Another DNS can still know the domain name, but this DNS is not. However, in the above example, we have chosen a name that does not exist (or at least not when we run the test - of course, maybe someone will register this name in the future) intentionally to make sure error will occur. If you encounter this problem, you can try using the nslookup program on a computer that has direct access to the DNS server, and use it to query directly to a specific DNS server to confirm that He knows that domain.

If you see results like this, repeat a few times:

 18:19:29.935439 Out 00:0c:29:c7:60:e9 ethertype IPv4 (0x0800), length 76: 192.168.47.133.60180 > 1.2.3.4.53: 16427+ AAAA? www.google.com. (32) 18:19:29.935479 In ethertype IPv4 (0x0800), length 76: 172.27.232.3.51334 > 1.2.3.4.53: 37513+ A? www.google.com. (32) 

Then, what you can see here is a query coming from the VPN client, going through the Access Server, then going out to the Internet, but there is no response. Usually, this means that this DNS server is not accessible, or that it is not a DNS server. In the example, the author chose the IP address 1.2.3.4, which is definitely not a DNS server. Obviously the query will be repeated several times but will eventually fail.

The obvious solution here is to choose an active DNS server, or, to ensure that no firewall is blocking queries from VPN clients to the DNS server. In some cases, when routing is used to give VPN clients access to the server on a private network connected to the Access Server, the reason is that the router is missing. In this case, packages from VPN clients make it a very reliable destination DNS server. However, it cannot respond, because it receives packets from a subnet that itself does not know how to respond. That can be solved by implementing static routes for direct guest VPN communication, or switching to allow access with alternative NAT. In other cases, especially on Windows Server platforms, Windows Firewall integration can block queries coming from subnets outside the local network. In this case, adjusting the firewall is necessary to allow the DNS server to receive queries and respond to it.

Refer to some of the following articles:

1. Check Internet speed without software

1. 3 "legitimate" reasons to change DNS Server

1. Instructions for setting up individual FTP Server with FileZilla

Good luck!