As a man of faith, I am often confronted with one sorry truth: my desires often exceed my patience. So it was with my extended DNS security project. I have written three out of four articles about DNS security. But I have taken a detour from my original plan.
The first article that I wrote outlined the merits of using the Trusted Recursive Resolver that showed up in Firefox 61. I concluded that the merits of encrypting DNS payloads were obvious and the investment was a necessary one – if you want to ensure privacy. The second article outlined the merits (and methods) of using DNS -Over-HTTPS (DoH) to secure references to external referrers/resolvers. In the third article, I outlined how I altered my DNS/DHCP infrastructure to exploit DNSMasqd.
That left me with the final installment. And the original plan was to outline how I had implemented Unbound as a final means of meeting all of my DNS security requirements. Basically, I had to outline why I would want something other than a simple DNS referral agent. That is a great question. But to answer that question, I need to provide a little background.
DNS Background
The basic DNS infrastructure is a hierarchical data structure that is traversed from top to bottom (or right to left when reading a domain name). When a customer wants to know the IP address of a particular device, the top-level domain (TLD) is queried first. So if looking for www.lobostrategies.com, one must first search the registry for all ‘.com’ domains. The authoritative server for ‘.com’ domains contains a reference to the authoritative DNS server for lobostrategies.com (i.e., GoDaddy).
The next step is to search the authoritative domain server for the address of the specific server. In my case, GoDaddy would be queried to determine the address for www.lobostrategies.com. GoDaddy would either answer the question or send it to a DNS server supporting the next lower level of the domain hierarchy. Since there are no subdomains (for lobostrategies.com), GoDaddy returns the IP address.
The ISP Advantage
The process of searching from the root to the proper branch (that answers the query) is called recursive searching. And it is the heart of how DNS works. But this burden is not carried by every user. Can you imagine if every user queried the top-level domain servers? It would be an incredible volume of queries. Instead, the results of most queries are stored (i.e., cached) at lower levels of the tree. For example, companies like your cable ISP (or Google, or Cloudflare, or OpenDNS) will be your ‘proxy’ for all requests between you and the host name that you want to resolve into an IP address.
Your ISP has almost every result of top-level domain queries already stored in its cache. So your answer would be delivered with at least one fewer step than it would have required for you to ask the question yourself. And since most public DNS resolvers have massive results already cached, you would never have to go to GoDaddy to get the IP address for my website. So rather than issuing a query to the root and a query to GoDaddy, your ISP can just provide the address directly to you – reducing your name search activity in half. Therefore, most users consult a DNS service that does the searching for them.
Hidden Costs
But think about what it is costing you to do the search yourself. The first time you query a domain, it takes time (and cache memory). But after the one-time ‘charges’ are paid, isn’t running my own recursive DNS a low-cost investment? Yes it is, and no it isn’t. The real cost of DNS is the hidden cost of privacy. If you run your own recursive DNS server, then you have to pay the entry costs (in hardware and in slower initial resolve times).
If you ‘trust’ someone else to do this for you, then they have access to all of your DNS queries. They know who you are and what you are trying to see. They won’t know what you saw in your query to a specific site. But they will know that you wanted to know where a particular site could be found.
Bottom line: To use a DNS resolver/referrer, you are necessarily letting that service provider know about your probably website destinations.
By using a recursive DNS, you are only letting the domain owner for a site know that you are looking for their address. Google would only get query data when you were intending to connect to Google services. So Google would only see a subset of your DNS queries – thereby improving DNS security.
On the flip side, you really do want a service that will encrypt the DNS payload. Recursive DNS tools (like the Unbound tool in DD-WRT and Pi-hole) do not yet support robust encryption for their recursive queries. Indeed, only two DNS providers currently support DOH (i.e., Google and Cloudflare). By selecting to use a recursive DNS that you manage yourself, you are limiting the ability to mask DNS search requests as they move across the Internet. In practice, this means that you will have a higher risk of being exploited by a man-in-the-middle (MIM) DNS attack. And this includes things like DNS spoofing.
The Choice
So I was faced with a simple choice: 1) I could implement a solution with encryption to a trusted recursive DNS provider, or 2) I could pay the upfront price of running my own recursive DNS. When I started to write this series of articles, I was feeling very distrustful of all DNS providers. So I was leaning towards running my own recursive DNS and limiting the search data that my selected provider could exploit. But the more that I thought about it, the more that I questioned that decision. Yes, I don’t trust companies to place me above their bottom line. And I don’t want the ‘gubmint’ to have a choke point that they could exploit. After all, didn’t the 2016 presidential campaign demonstrate that both parties want to weaponize the information technology?
But the fear of all companies and all politicians is a paranoid conceit. And I don’t want to be the paranoid old man who is always watching over his shoulder. More importantly, the real challenge / threat is the proven risk that script-kiddies, hackers, and criminals might target my data while it is in transit. So as I compared a paranoid fear versus a real fear, I started moving towards desiring encrypted DNS queries more than limiting third-party knowledge of my queries.
The Choice Deferred
Just as I was about to implement changes based upon a re-assessment, I inadvertently shot myself in the foot. I was listening to a podcast about information security (i.e., Security Now by Steve Gibson) and I heard about a resurgence of router-based password exploits. I had long ago switched to a password manager. So I wanted more entropy in my randomized password. I checked online to see if there were any password standards for DD-WRT. I found nothing. So I figured that if the software didn’t like a password, then it would stop me before implementing the change.
I plunged ahead and created a 64-character randomized password. The software took the change – even validating the password against a second-entry of the password. But when I went to log back in to the router, my shiny new password was rejected.
Wash, Rinse, Repeat
I was getting frustrated. I looked to see if there was any way to revert back to an older password. But there was no such capability. And the only way to log back into my router would be to factory-reset the device – which I did. But it took a very long-time to recover (~2.5 hours). So after a few hours, I was back to where I started.
Before I tried again, I backed up the non-volatile memory (nvram). Then I decided to try a shorter password. After failing with the 64-character password, I tried a 32-character password. Unfortunately, it resulted in an inaccessible router. So I restored my router and then I was back to the starting line, again.
After researching the issue for forty-five minutes, I found someone that had run into the same problem. They had solved it by using a twenty-two (22) character password. So I earnestly tried to change the password to an eighteen (18) character password. I was hopeful; my hopes were crushed. But I was getting good at doing the factory reset. So after three attempts and almost five (5) hours of effort, I went back to the old password format that I had used before. Lo and behold, it worked.
Overall DNS Security Improvements
After spending the bulk of an evening on this effort, I was glad to be back on track. But I had a fresh appreciation for doing as little as possible to my router and my DNS infrastructure. I already has a working DNS that used DOH to communicate with Cloudflare. And I had done enough research to be less skeptical of the Cloudflare DNS (when compared to ISP DNS and Google DNS).
I now have a DNS service separated from my router. And the DNS and DHCP systems are running on a unified system – thus making reverse-lookups and local queries far more effective. Finally, I have a DNS request facility that should be more secure against man-in-the-middle attacks. So without much more fanfare, I will call this DNS security battle a victory – for now. And I will keep my eyes wide open – both against corporate/government exploitation and against self-inflicted computing wounds!