|Test Your DNS Servers
Devices connected to the Internet are assigned unique numbers called IP addresses. You know this site as RouterSecurity.org and its IP address is 220.127.116.11. 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 many places that DNS servers could have come from. The most recent change is that web browsers can now specify their desired DNS server.
The tests below run in a web browser. If one browser is using encrypted DNS while another, on the same computing device, is not, then expect these tests to show different results in each browser. Likewise, if you have two web browsers using different 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.
I have a list of suggested DNS providers.
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 18.104.22.168.
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, 11 and 12 allow a global DNS setting for the entire operating system. iOS is the exact opposite, it even allows each app to configure its own DNS servers.
If a specific network connection does not specify any specific 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 (at 192.168.1.99) as the DNS server.
Another option for Windows users is the ipconfig command. Its equivalent for MacOS and Linux is ifconfig.
On Windows, the command ipconfig /all shows details, including the DNS server(s) for all the defined network connections. Note that this only applies to the old insecure version of DNS. It does not know about browsers using new secure DNS. And, what the operating system specifies for old DNS can be transparently over-ridden by the router. Also, when connected to a VPN, there will be one entry for the net connection without the VPN (WiFi or Ethernet or 4G) and another entry for the VPN connection. Which DNS servers are really being used by the OS when not running a web browser? See nslookup above.
This command can also useful after closing a VPN connection. I have seen VPN software that did not reset the DNS servers correctly when shut down. This left the computer using the DNS servers from the VPN company even when the VPN software was not running.
macOS offers the scutil -dns command. Look for nameserver. The website ss64.com offers full command syntax.
Linux should offer the nmcli command. Its output contains various sections, including "DNS configuration". See its man page.
On both Linux and macOS, you can also 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
command should display the DNS server used to answer the question. Look for "SERVER:" in the output.
I am not an iOS developer, but from what I have read about DNS on iOS it is far too complicated for non-developers to understand. Perhaps the best support for this opinion, is a video for iOS developers, Enable encrypted DNS, where the description says "... enable encrypted DNS within an app using standard networking APIs..." So, if each app can have its own DNS configuration, what testing/checking could anyone do? Also, in my blog on VPNs on iOS are a scam, I noticed iOS 15.6 making normal old UDP port 53 DNS requests to the router despite its being configured to use NextDNS system-wide. iOS does not fully honor the system wide DNS setting. There is much more on this in the DNS Long Explanation (click at the top of the page).
It is commonly thought that if the Operating System specifies DNS servers (either for Ethernet or for a specific SSID) 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. Worse, if the router is doing this (at least with Peplink routers) the computer can not tell. The DNS server the computer sees is not the one really being used.
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 22.214.171.124 for DNS resolution. But, if Windows is configured to use 126.96.36.199 and the router is configured to use 188.8.131.52 (for example) and the router is imposing its will on all the attached devices, nslookup will report that it is using 184.108.40.206. It is not lying on purpose, it is being faked out by the router. The packets leaving the WAN port of the router will be sent to 220.127.116.11. 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.
That said, my experience has been that a router forcing the use of its DNS servers, only applies to old DNS. Browsers that specified DoH or DoT secure DNS servers had their requests honored because, to the router, a secure DNS request is a totally different thing than an old DNS request.
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 (10.255.255.3). The server is not unknown, just its name is.
Windows users can trace all instances of legacy DNS using two free and portable programs from Nir Sofer: DNSQuerySniffer (see a screen shot) and DNSLookupView. Each has its own pros/cons. If you run these programs before starting up a browser, you will see the browser making old (not secure) DNS requests to find the Secure DNS server. If things are working as they should, the only browser DNS requests, visible to Windows, are those for the Secure DNS server itself. Another idea is to run these programs with nothing going on, and see where Windows is phoning home to. I did this in October 2021 and found Windows 10 logging many actions in the System Settings app. And, you can use DNS to block Windows from being able to log your actions.
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.
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:
iOS added encrypted/secure DNS in version 14. As of May 2022, they don't yet seem to have all the bugs out. iOS sometimes issues a warning "This network is blocking encrypted DNS traffic." I have seen it myself on iOS 15.5, and read a number of articles about how to get rid of the error message. No one knows what causes it. No one. One suggestion to get rid of the message is to forget the current SSID and re-connect to it. To me, that points to this being a bug. More here: How to Fix 'Network Blocking Encrypted DNS Traffic' on iPhone by Tim Brookes (May 2022).
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 18.104.22.168 and 22.214.171.124. 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 126.96.36.199 or 188.8.131.52 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.