Firefox and Chrome have recently begun supporting external DNS resolvers in the cloud. The use of these DNS services bypasses controls that enterprise IT organizations put in place to prevent end users from visiting unauthorized Internet destinations.
Compounding the issue is that certain operating systems and browsers use new encryption technologies – DNS over TLS (DoT) and DNS over HTTPS (DoH) – in the query response handshake with these unauthorized DNS services that make them harder to block.
Here’s a transcript of the podcast for your convenience.
Hello, I’m Srikrupa Srivatsan, Director of Product Marketing at Infoblox. Today I’m going to talk about DNS over HTTPS misuse or abuse. You might’ve heard or it’s been in the news recently about the use of DNS over HTTPS, or DNS over TLS to improve privacy of DNS communications.
DNS, if you look back when it was first invented, it was not created or built with security or privacy in mind. It’s an open protocol, it’s a very trusting protocol, and it’s fundamental to the internet. We use it to access websites, we use it for email, you name it, anything that happens online uses DNS. But because it wasn’t built with security or privacy, what happens is the actual communication between your device, let’s say a laptop or an iPad or whatever it is, to the DNS server is open. If anybody is snooping, they’ll know exactly which websites you’re accessing.
What that means is there’s a little bit of user privacy issue when somebody does that. To counter that, what’s happened is there are two new developments in the market, DNS over HTTPS and DNS over TLS. These are meant to encrypt communication between the endpoint and your recursive DNS server. While the intention is good and it’s a perfect use case for consumers – at home, accessing websites from Starbucks, you don’t want random guys knowing where you’re going to, things like that. It could be attackers, things like that.
But in an enterprise setting, when you use DNS over TLS or DNS over HTTPS, it causes security issues. When I say security, what I mean is, because in DNS over HTTPS or DoH, as it’s called, the DNS queries are encrypted and sent over the HTTPS protocol, which means the enterprise DNS server does not see that request at all. It’s completely bypassed.
When your enterprise DNS server is completely bypassed, your IT admin has an issue. He no longer controls your access to the outside world, to the internet. He no longer knows whether you are in compliance with the company’s security policies, whether your device is secure enough.
Let’s say your security admin has put in some controls on the DNS server to detect things like data exfiltration or malware, C&C communications. Now, when the internal DNS server is bypassed, that security is lost for the user. It’s fine to use though in a kind of consumer setting, but when you think about an enterprise, you want to make sure that you are in control of where the users are going, you have visibility into where users are going, and you’re able to secure where your users are going, those connections.
For that, what we suggest or what we recommend as a best practice, is to make sure that, number one, is avoid using DoH resolvers, because these resolvers are sitting somewhere in the internet. They are not authorized by your company or the enterprise’s security admin or the IT admin. So, you’re kind of connecting to things that they are not approving or they’re not authorizing.
It’s becoming an issue these days because browser companies like Mozilla, just today, they announced a press release saying that they are by default making sure that all Firefox browsers have DoH enabled. If you use Firefox, automatically DoH is enabled. That’s the default setting. Your device, your laptop can send its DNS queries to a DoH resolver somewhere on the internet.
We see this trend by certain companies to default to DoH. It is a little bit dangerous because you’re bypassing your internal DNS and you’re bypassing security controls. What we suggest is to make sure that you’re using an internal DNS solution that can detect DoH and prevent these browsers from using DoH.
And you guys may already know, Infoblox is in the DNS security space. We have a solution called BloxOne Threat Defense that provides foundational security for things like detecting malware, C&C communications, from your laptops or any devices. It detects data exfiltration over DNS. DNS is constantly used to send out data because your DLP solutions or next-gen firewalls do not inspect DNS. It’s a great backdoor to exfiltrate data. We can detect and block that.
BloxOne Threat Defense Business On-Premises integrates with the entire cybersecurity ecosystem
And then we also have now added capability to prevent use of DoH in an enterprise setting, and make these browsers fall back gracefully to your internal DNS, so that the IT admins and security admins are retaining control. Even if you bring in a device within your enterprise network and you are using Firefox, it’ll fall back to the internal DNS. It will not connect to the DoH because we have certain feeds in our solution that enables that. We have DoH feeds that enable that.
Definitely that’s the best practice that we recommend to all our customers, and in general enterprise companies. It could be education, financial services, government, retail. It doesn’t matter what type of company you are. If you are an enterprise that has a lot of users and you want to make sure that you retain control and retain visibility of where they’re going, and you want to make sure your company’s policies are enforced, we highly recommend blocking these type of DNS implementations.
With that, I hope I gave you a little bit of an idea of the downsides or downfall of using things like DoH, and making sure that you are enabling your DNS server to be as secure as it can be, with solutions like BloxOne Threat Defense from Infoblox.
If you need more information on our DNS security solutions, you can visit www.infoblox.com. We do have a solution, like I mentioned, called BloxOne Threat Defense that provides robust foundational security at the DNS layer. Thank you.