|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 188.8.131.52. 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. They report the DNS servers your computing device is currently using. We need tests like these because there are four places that DNS servers could have come from: the router a computing device is connected to, the computing device itself, VPN client software running on the computing device or a web browser configured to use encrypted DNS (DoH or DoT). For more on encrypted DNS see the Encrypted DNS topic on my Defensive Computing Checklist site.
Note: 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.
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:
Command line fans can also 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 10.
If you are connected to a VPN, nslookup will return an IP address on the internal network of the VPN provider. This was the case in the example above. The one test I did on Windows 10 showed the OS to be buggy. After disconnecting from a VPN, nslookup still kept reporting the VPN providers DNS server. The browser based tests above, all showed expected results.
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 184.108.40.206 and 220.127.116.11. 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 18.104.22.168 or 22.214.171.124 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.