Infoblox's Cricket Liu explains DNS over HTTPS security issues

The domain name system is one of the fundamental technologies that has enabled the rapid growth and current stability of the internet.

However, while DNS has served as the contacts app for the internet for well over 30 years, it is one of the last of the internet's foundational application protocols to not incorporate cryptographic protections. Long after other basic internet application protocols like file transfer and terminal emulation incorporated encryption and authentication, work is ongoing to create a standard that enables privacy for DNS over HTTPS.

For the past two years, the DNS over HTTPS (DoH) working group of the Internet Engineering Task Force has been trying to solve the problem of how to enable confidentiality and integrity for DNS queries and responses by using HTTP Secure (HTTPS) to provide encryption and authentication at the application layer. Despite its name, the DoH working group is also responsible for a similar effort to enable DNS over the Transport Layer Security (TLS) protocol, which provides encryption and authentication at the transport layer.

In this Q&A, Cricket Liu, chief DNS architect at Infoblox Inc., discusses some of the benefits that DNS over HTTPS can offer, as well as some of the challenges that DoH and DNS over TLS (DoT) can introduce.

Editor's note: This interview has been lightly edited for clarity.

What should people know about DNS over HTTPS and DNS over TLS?

Cricket Liu: What I would say about DNS over TLS and DNS over HTTPS is that they certainly solve some long-standing issues with DNS. We've had what we call a last-mile problem in DNS for a long time.

A DNS stub resolver is a piece of software that's on your smartphone or your tablet or your laptop or whatever. The communications between the stub resolver and the recursive DNS server that it queries -- that's completely in the clear, and so it's subject to snooping and the responses can be spoofed.

There are lots of things that can go wrong, and so both DoT and DoH, which is what we call them for short, are attempts to solve those problems, which are legitimate problems.

Cricket Liu

One of the issues that some people in the DNS community -- and I think I'm one of them -- have with DoH in particular is that the implementations of DoH that we're seeing, like the one that's within the Firefox browser, make it very, very difficult for your own IT folks to identify this name resolution traffic. The implementation in Firefox circumvents your internal DNS infrastructure and fires your DNS queries directly off to [Cloudflare's 1.1.1.1 public DNS service] to get responses back from them.

That's what we object to: the idea that DoH makes it very easy to circumvent any kind of DNS infrastructure that we might make available to them internally [or] security mechanisms that we might make available via that DNS infrastructure, like response policies, for example. It makes it more difficult for us to troubleshoot because, all of a sudden, we have some new class of software on our networks which uses a completely different DNS configuration than the one we specify.

Does the DNS over HTTPS traffic between the requesting node and the public DNS service appear to be encrypted HTTPS content?

Liu: Yes, exactly. It's just HTTPS traffic, so it's sort of like finding that needle in the haystack -- trying to identify the DNS over HTTPS traffic that's being sent.

If you're looking at one of the new DNS services with easy to remember addresses -- like Quad9 (9.9.9.9), Cloudflare (1.1.1.1) and Google Public DNS (8.8.8.8 or 8.8.4.4) -- are those going to be the destination addresses in the DoH request header? If so, would that make it easier for IT people to identify when those DNS services are being queried?

Liu: That's certainly a very good thought. What I found, because I was writing a blog entry [about the DNS last-mile problem], was that, in general, they don't use the same addresses.

For example, Cloudflare, which notably uses 1.1.1.1 and 1.0.0.1, they use a different IP address for their DoH endpoint. I included in the blog entry what it was so people could block it, but it's not the same as their well-known IP address.

Is it accurate to say that if large organizations are blocking DNS over HTTPS, they're doing it because they already have their own DNS infrastructure in place with their own protections?

Liu: There could be a number of different reasons they could block access to, for example, Cloudflare in this particular case.

These companies that are offering these public DNS services, they're not doing it out of the goodness of their hearts.

One would be that they've gone to the trouble to set up these DNS-based security mechanisms on prem, and maybe in addition to that, they're also running analytics internally on DNS queries because they want to be able to more easily troubleshoot DNS problems. Of course, using somebody else's cloud-based DNS service makes it more difficult for you to diagnose those issues.

There might also be issues with turning over all of this DNS telemetry to a company that you don't have any kind of formal contractual relationship with.

If you download Firefox, you're not inking a legal agreement with Cloudflare. You do have a promise from Cloudflare: They say, 'We're going to do the right thing. We're not going to keep your personally identifiable information,' and so on, but ... I don't know. If that were tested, if the Department of Justice were to go after the data, if they were to get a subpoena from a U.S. court, what would they do?

And, presumably, there's value to the DNS traffic data, as well?

Liu: Absolutely. These companies that are offering these public DNS services, they're not doing it out of the goodness of their hearts.

Google Public DNS, for example, is a free service, but what you're doing is you're giving Google access to all kinds of information about the way that you access the internet [and] the services that you use. In fact, you're giving them substantially more information than they would get if you were just using their search engine.

So, in general, will DoH and DoT be positive developments for most users, but something that most enterprises want to bypass? How should people be thinking about these things?

Liu: My thinking is that DoT and DoH certainly serve useful purposes, but using them to circumvent an organization's own internal DNS infrastructure is probably a bad thing.

On the other hand, if I'm just a user of the internet, if I'm sitting at home like I am right now and I want to use Firefox and Cloudflare's public DNS service, and I want to use DoH to encrypt that last mile, I think that's a totally legitimate choice. That doesn't really affect anybody except possibly my ISP [internet service provider]. But for an enterprise environment, it's potentially troubling.

You raise an interesting point with regard to ISPs. Does this potentially benefit ISPs because they're running their own DNS infrastructures?

Liu: It doesn't really benefit ISPs because the ISPs are losing visibility into what their customers are doing. So, to the extent that an ISP is actually interested in understanding their customers' browsing habits, how they use the internet, this impedes that.

In addition to that, it's going to mean that troubleshooting DNS-related problems becomes a little bit more difficult for those ISPs, as well.

Will there be benefits to DoH and DoT for enterprises or will organizations shy away from it as they develop their own DNS infrastructures?

Liu: Generally speaking, people don't think of the inside of their network as particularly hostile. But, for example, the folks at ISC, the Internet Systems Consortium, are going to add support for DoT to BIND [Berkeley Internet Name Domain] probably sometime this year.

When they do that, it'll be possible for folks who are running BIND-based internal DNS infrastructures to turn on DoT in between their stub resolvers and their recursive DNS servers. That's great because it helps to protect that communication.

That seems important. Does that mean that once BIND supports DNS over HTTPS, anyone can implement encryption and authentication on their DNS interactions?

Liu: That's exactly right. In fact, there are already some DNS servers that support DoT. Infoblox uses a recursive DNS server called Unbound in parts of our cloud infrastructure, and Unbound supports DoT today.

That's great because if you're running an internal DNS infrastructure and you want those same sorts of capabilities [and] you want to be able to protect communication between your stub resolvers and your recursive DNS servers, you can do that. But you don't lose the effectiveness of your DNS-based security mechanisms. You don't lose visibility into DNS traffic and who is looking up what.

We've talked about some of the drawbacks, like losing control over the data for organizations that already have their own infrastructures. Are there other drawbacks or potential catches that people should be aware of going forward?

Liu: Those are the main things, but we have more and more people who are using response policy in order to implement name resolution policy and prevent people from inadvertently going to sites that you don't want them to go to -- preventing malware from being able to connect to command-and-control servers, things like that. We don't want those mechanisms circumvented.

We also want to have visibility into what folks are doing. Sometimes, that's for forensic reasons. For example, after you've identified a breach somewhere within your network and you know that the computer at that IP address got hacked, it's nice to be able to look at your DNS logs to figure out where the bad guy went from there, which other sites he visited.

When you talk about forensics, a lot of people think of gathering evidence. Does this affect DNS providers' ability to respond to requests from law enforcement?

Liu: It'll be interesting to see how it affects it. I'm not certain.

But right now, for example, let's say you're an ISP and one of your customers was using Firefox, and through Firefox, Cloudflare. If you got a subpoena that said 'I need all of Cricket's logs, every place that he went over this period of time' -- you wouldn't have them. Cloudflare would have them.

I'm assuming, in that case, Cloudflare would get -- and be able to respond to -- the subpoena?

Liu: In that case, they might well get the subpoena. Then it raises a new question: If you're a European resident, you're guaranteed the GDPR -- that your data is private. Then the United States decides it's interested in your data [and], because Cloudflare is a United States-based entity, they go after it. Do you have any way to protect that data?