Why DNS over TLS is important even if privacy is not a concern

Giridhar Kannan
Sep 9, 2018 · 3 min read

I had opted for a new ISP in my hometown. Though the speed is not great, it does meet the basic needs of the modern day usage. Within a day I had faced the following error multiple times “server IP address could not be found”.

I initially thought the issue was with my system and checked for any DNS misconfiguration and found that things were correct. I generally use primary and secondary DNS as 1.1.1.1 and 8.8.8.8 respectively, and that was the same in my router. Upon inspecting the packets via Wireshark, I did see the DNS server 1.1.1.1 was queried for IP via port 53 over UPD, and it responded with SERVFAIL response.

SERVFAIL in action

Since the domain for which the issue was occurring is owned by us (zeetaminds.com), I felt the SERVFAIL was an odd response as I know for the fact that we didn’t change our DNS settings. After a while, I faced the same issue for other domains (console.aws.com, blog.cloudflare.com, etc…) during which I found a pattern. The issue occurs only for non-popular domains and not for the popular ones, which would be used by many (google.com, youtube.com). During this time, I had a hunch that, ISP may be spoofing the DNS request.

So to prove my hunch, I had to prove that the actual 1.1.1.1 DNS server would indeed resolve zeetaminds.com IP at the same time when the UDP request to 1.1.1.1 gives SERVFAIL. To do this, I had set up stubby as my local DNS and configured it to use 1.1.1.1 over port 853(TLS) to resolve IP and used the following dig commands.

dig @127.0.0.1 zeetaminds.com +ttlunit
dig @1.1.1.1 zeetaminds.com +ttlunit
dig @127.0.0.1 zeetaminds.com +ttlunit

As I suspected, the IP got resolved for the 1st and the last command but returned SERVFAIL response for the second command. Interestingly, I got the same result (SERVFAIL) when used TCP (dig @1.1.1.1 zeetaminds.com +ttlunit +tcp) instead of UDP.

This experiment concluded that my ISP did spoof all DNS requests over port 53 irrespective of the protocol (UDP or TCP).

After further analysis, it seems ISP gave DNS spoof response with a max TTL of 30sec for all the domains. The reason why the issue was prevalent made sense after observing the 30sec TTL (OS was forced to re-request DNS lookup for every 30 sec once).

To come up with a proper solution so that no other devices in my home doesn’t become a victim of this issue, I have to flash my router with openWrt firmware and configure TLS enabled DNS server, which I may do soon after getting a response from my ISP.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade