|Router Security||Test Your DNS Servers||
Website by |
Devices connected to the Internet are assigned unique numbers called IP addresses. You know this site as RouterSecurity.org and its IP address is 126.96.36.199. All communication on the Internet is based on these unique numbers, website names and computer names are just a convenience. The system that translates names into the underlying numeric IP addresses is called DNS (Domain Name System) and the computers that do the translation are referred to as DNS servers.
DNS Servers are extremely important. Probably 99% of all communication between two computers on the Internet, starts with a call to a DNS Server to translate a computer name into an IP address.
Malicious DNS servers can do what any malicious translator can do - lie to you. For example, they might send you to a scam copy of a website. Like food, you should not take DNS servers from a stranger.
You can check a computer or router to see what your DNS servers should be, but the pages below show what they actually are (with the tested web browser). That is, they report the DNS servers your current browser is actually using. We need tests like these because there are four places that DNS servers could have come from: (1) the router a computing device is connected to, (2) the computing device itself, (3) VPN client software running on the computing device or (4) a web browser configured to use encrypted DNS (DoH or DoT). Then again, your computer probably supports a system-wide DNS setting and also DNS settings specific to each wireless network (SSID) and maybe DNS settings specific to Ethernet connections. Whew.
If one web browser is using encrypted DNS while another, on the same computing device, is not, then expect the tests below to show different results in each browser. Likewise, if you have two web browsers using different secure DNS providers, expect them to report different results in the tests below. For more on encrypted DNS see the Encrypted DNS topic on my Defensive Computing Checklist site.
NOTE: If you are using the Private DNS feature of Android (first introduced in version 9) there is no need for any of the testers below. Android will always use the Private DNS servers, even when a VPN is active. Thank you, Google.
To see what the Operating System is using for DNS, outside of any web browsers, we can use the nslookup command on desktop operating systems (Windows, macOS, Linux). The command syntax is very simple: "nslookup domainname". The first thing returned by the command is the name and IP address of the default DNS server. Below is a screen shot from Windows 7 showing the system is using DNS server dns9.quad9.net at IP address 188.8.131.52.
DNS configurations in the Operating System can be all over the map. There can be different DNS servers configured for Ethernet vs. Wi-Fi. And, each wireless network (SSID) can be configured to use different DNS servers. Android 9, 10 and 11 allow a global DNS setting for the entire OS.
If a specific network connection/SSID does specify its desired DNS server(s), then it gets assigned DNS servers by the router. But, again, a complication. The router may function as a DNS server itself, or it may simply pass DNS requests out to a DNS server on the Internet.
In the example above, the network connection was specifically configured to use Quad9. In the example below, a Windows 10 computer is using the router itself as the DNS server.
It is commonly thought that if the Operating System specifies DNS servers, they will get used. This is not always the case. Some routers (such as the Pepwave Surf SOHO) can force clients to use the DNS servers specified in the router. That said, my experience has been that this only applies to old DNS. Browsers that specified DoH type DNS servers had their requests honored.
This means that the DNS server reported by nslookup can not be trusted. In the first screen shot above, it looks like Windows is using 184.108.40.206 for DNS resolution. But, if Windows is configured to use 220.127.116.11 and the router is configured to use 18.104.22.168 (for example) and the router is imposing its will on all the attached devices (a feature offered by Peplink and other routers), nslookup will report that it is using 22.214.171.124. It is not lying on purpose, it is being faked out by the router. The packets leaving the WAN port will be sent to 126.96.36.199 as per the router. I learned this the hard way, by doing pcap traces of data packets leaving the WAN port. I assume the same is true with the dig command on Linux and macOS.
And, of course, a VPN complicates this further. Below is a screen shot of nslookup done while a Windows 10 computer was connected to a VPN. In this case, nslookup returns the IP address of the DNS server on the internal network of the VPN provider. The server is not unknown, just its name is.
Windows users can trace all instances of legacy DNS using the free and portable DNSQuerySniffer program by Nir Sofer (see a screen shot). Run it before using a browser to see if the browser is using old or new DNS. Shut down all browsers, run DNSQuerySniffer and wait, to see the legacy DNS requests generated by Windows itself.
Still another approach, for Windows, was suggested by Sergiu Gatlan in his August 2020 article Microsoft adds Windows 10 DNS over HTTPS settings section. He suggests using the pktmon command to trace all activity on TCP/IP port 53. The pktmon command can not display just outgoing requests, it always includes the replies too, so it generates a lot of activity in the command window. But, it will confirm the use of old DNS. The commands Gatlan suggests are:
pktmon filter remove
pktmon filter add -p 53
pktmon start --etw -l real-time
I suggest first doing a pktmon filter list just to see if any filters are active. The logging can be stopped with Ctrl+C.
On both Linux and macOS, you can use the dig command to see which DNS server is being used. On macOS, do Applications -> Utilities -> Terminal. For Linux see How to Use the dig Command on Linux by Dave McKay (April 2020). A simple dig somedomain.com command should display the DNS server used to answer the question. Look for "SERVER:" in the output.
If your DNS provider offers ad/tracking blocking, then you can see how well it is working at this tester page d3ward.github.io/toolz/adblock.html by Eduard Ursu.
A new attack on DNS servers, called SAD DNS was made public in November 2020. The attack tries to poison the DNS results, that is, pointing victims to a malicious server at the wrong IP address for a domain. The attack was created by six academics at the University of California, Riverside and at Tsinghua University. See their paper and slides.
You can test if you are using a vulnerable DNS server using the "Click to check if your DNS server is affected" link on the SAD DNS page. They warn, however, that their test is not 100% accurate.
On November 12, 2020 I ran some tests. Cloudflare, Google and Quad9 were all vulnerable. The DNS from my VPN provider was not. NextDNS initially could not resolve the SAD DNS page. The log showed that it was blocking saddns.net because it was a newly registered domain. No big deal to white list the domain. NextDNS was also reported as vulnerable.
Hacking a router and changing the DNS servers is a very popular type of attack. Some reports in the news:
Warning to Windows users: There is a caching or buffering issue involving VPNs. After connecting to a VPN, the above sites typically show both the pre-VPN DNS servers and the current DNS server from the VPN provider. On iOS 12 and Android 7.1 all the above testers work fine, only Windows is buggy. I have not tested other OSs. In the screen shot below, from the Express VPN tester page, the four OpenDNS servers were in use before the VPN connection was made and the server at Leaseweb USA is from the VPN provider. I tried the command "ipconfig /flushdns" but it did not help.
On Windows, the only tester page above that has been bullet-proof in my experience is the one for OpenDNS. It simply reports a YES/NO on whether OpenDNS is being used and it is not fooled by whatever caching issue confuses the other testers. As a side note, all the VPN services I have used assign a single DNS server. Outside of a VPN, there are normally two or more DNS servers in use.
Another issue is that different DNS testers report a different number of DNS servers. Some only report on one DNS server, others report on multiple DNS servers. I don't know why this is.
Cloudflare DNS servers are 188.8.131.52 and 184.108.40.206. In November 2018, Cloudflare released iOS and Android apps that configure those systems to use their DNS servers. It works by creating a pseudo VPN connection. The testers above do not report either 220.127.116.11 or 18.104.22.168 as the in-use DNS servers. The Cloudflare app will show that it is being used, and I am sure it is, but the above DNS testers report other IP addresses. And, you can't go by the hostname either, the servers used by Cloudflare do not have host names. The only clue from these testers is that Cloudflare is the ISP.
One feature of Cloudflare DNS is encryption. The connection between your computer and their DNS server is encrypted using one of two fairly new approaches: DNS over TLS or DNS over HTTP. This only an issue when you are not using a VPN. A VPN encrypts everything (when it is working correctly) coming and going from the computer so there is no need to pay special attention to encrypting DNS.
Warning to WIRED readers: The article You Know What? Go Ahead and Use the Hotel Wi-Fi by Brian Barrett (Nov 18, 2018) comes to a very wrong conclusion. The main point of the article is that the widespread use of HTTPS (secure websites) eliminates the old dangers of sniffing and snooping on unencrypted data. For one thing, this shows a lack of understanding of the limits of HTTPS. Secure websites do not deserve that much trust. Still, the bigger danger is that on a public wireless network you have an encrypted connection to bad guys. HTTPS does nothing to protect you from a scam website that looks real enough, displays the correct URL in the address bar, but whose sole purpose is to harvest passwords. Extended Validation could offer this protection, but in the real world it does not. For one thing, web browsers are constantly changing how they indicate EV vs. DV (Domain Validation). And, some browsers do not give any visual indication of the difference. And, I suspect no non-techies are even aware of the EV/DV concept in the first place. Even more insidious is using DNS not to fake out the main/displayed domain name, but to point the browser at a scam copy of included code from a third party. Many sites are compromised by including malicious code from hacked third parties. DNS means that the third party does not even need to be hacked. So, using trustworthy DNS servers, not those from hackers, a coffee shop or a hotel, is critical to computing safely. The article also ignores the issue of evil twin networks, an attack for which there is (as far as I know) no defense.
Anyone running a VPN on Windows 8 or 10 needs to be aware of a situation where DNS requests may be sent outside of the VPN tunnel. For more, see Guide: Prevent DNS leakage while using a VPN on Windows 10 (and Windows 8).
In May 2017, Trend Micro made a great point: "Unfortunately, website-based tests may not be reliable once a home router has been compromised." With that in mind, it makes sense to check with the router directly, be it with a web interface or an app, to double check the DNS servers.
Windows users have another excellent option, the DNS query sniffer program by Nir Sofer. The program is free, portable and from a trustworthy source. It simply traces DNS requests and responses. Before connecting to a VPN, tell it to examine either your Wi-Fi or Ethernet connection to confirm the program is working. Then connect to the VPN and you should see no further DNS activity. As further proof that the VPN is handling things, tell the program to examine your VPN connection (Options -> Capture Options) and you should see all your DNS requests.
As for whether a DNS server is actually working well, we have Steve Gibson's a DNS spoofability test. The page has no creation date and no last update date, but it has been around for a long time.