Thanks to Edward Snowden and others, the way governments deal with cybersecurity monitoring has become more top-of-mind in the industry than ever before. The question is: how – and whether – governments should monitor data transmissions. This raises the thorny issue of encryption – an issue that is now extending to the Domain Name System (DNS).
Government agencies are moving toward conducting what’s called pervasive monitoring of computer communications. Reaction to that comes from the Internet Engineering Task Force (IETF), which – believing that information should be protected from snooping – has developed the DNS PRIVate Exchange (DPRIVE) Working Group to provide data privacy to DNS transactions. As part of DPRIVE, the IETF is proposing running DNS over the Transport Layer Security (TLS) cryptographic protocol, the follow-on to Secure Sockets Layer (SSL), both widely used to secure communications between web browsers and web servers. (For more on this issue, see these recent articles in TechTarget and The Register.)
The ramifications for Infoblox customers are clear: they will have to consider how deeper levels of DNS encryption affect their security and network capacity. What it all means is still being ironed out, but it’s a conversation to be aware of. Given the level of passions that encryption enflames, it’s perhaps not surprising the topic has provoked some disagreement among Infoblox executives themselves. Here, then, is a point/counterpoint discussion between Cricket Liu (generally pro), chief DNS architect at Infoblox, and Rod Rasmussen (generally con), vice president of cybersecurity, giving their personal views on DNS encryption.
Cricket Liu: The IETF bristles at what it calls state-sponsored, pervasive surveillance of internet traffic. If everything is snooped on, we should encrypt everything. If this were to happen, communication between your DNS servers and those on the internet would be encrypted. It would still be subject to certain types of analysis, so that a hacker might be able to do traffic tracking, but they would only see that it’s a .com server your DNS server is querying, not which particular domain name your DNS server is asking about. The reason for doing this is that your DNS traffic can give away quite a bit about what you are doing on the internet: what websites you’re visiting, what e-mail systems you interact with, what software you’re running, and any other devices you need to look up a name to communicate with. For instance, a repressive regime could monitor their citizens, searching for those who look up the name of a VPN server run by an outside organization that helps dissidents communicate with the outside world.
Rod Rasmussen: You have to ask yourself if protecting the rather limited amount of telltale information that DNS encryption provides is worth the impact it has on your network and users. In the case of HTTP traffic or email, the trade-off to encrypt makes sense since so much sensitive information travels directly over them. DNS, not so much. First and foremost, for DNS, I’m concerned about performance implications. It’s a question of complexity, and more complexity slows things down and makes them more fragile. It’s more costly to send queries over TLS than to send them over the User Datagram Protocol (UDP). The capacity of DNS servers to serve queries will go down and latency will go up throughout the ecosystem. Networking will be more expensive because you’re going to have to throw more horsepower at the problem.
Liu: I think performance issues will be more noticeable to the admins. If this takes off, we’re going to live in a world where TLS is the norm for DNS queries. Admins will do whatever it takes to deliver performance. The end-user might not actually notice much if the admins have done a good job.
Rasmussen: That may well happen; however, the price you pay is too high for the incremental benefits you get. TLS adds overhead, and people don’t like overhead. This is a problem with encryption in general. Beyond performance hits, encryption often impedes other security efforts that you should be making for your network. If you are encrypting traffic and communicating with outside entities, you lose the ability to examine traffic as it enters or leaves your network perimeter. You can’t see exfiltration or insiders moving data files. Next-generation firewalls do a lot deep inspection of traffic to look for malicious behavior, and encryption typically thwarts that. If the traffic is encrypted, you can’t do data loss prevention (DLP), because you may not know what’s being moved. DNS is good for looking at tunneling and signaling patterns, but encrypting it makes such analysis almost impossible.
Liu: But there are substantial benefits. Encryption provides integrity checking and authentication. You can avoid cache poisoning attacks. When traffic is encrypted, intermediate devices such as firewalls and intrusion detection systems won’t be able to see traffic, but the DNS server still sees everything in the clear.
Rasmussen: DNSSEC is probably a better mechanism for integrity checking and authentication, but of course, that assumes people actually deploy it and utilize its power. If you want to use your own DNS resolvers to look for malicious activities, and at scale, you’re going to need to empower those servers and add even more resolvers. You’re going to have to do more management at the enterprise level. You’re going to have to tune the heck out of the network if you don’t have control over the clients and fully understand how clients are interacting with DNS servers. For example, what do you do when the server doesn’t provide encrypted connections or stops providing them for reasons you don’t know? Do you let it fail and tell users they can’t talk to the internet?
Liu: We’ve had situations like this before and we’ve worked through them. We moved from unencrypted HTTP to HTTP over SSL to TLS. Google now allows you to use TLS by default, even if it’s just to search. That’s a big change. We’ve dealt with this kind of complexity in DNS, too, as we deployed EDNS0 and as we’ve rolled out DNSSEC (the DNS Security Extensions).
Rasmussen: What’s a government’s response going to be if we start encrypting DNS? They’ll just find the weak point and exploit it. They’ll get court orders and tap into ISP’s resolvers to see what the traffic is. The data has to get decrypted somewhere. That does make it harder for a government, because they can’t just tap the backbone with a legal process, but it doesn’t “solve” the problem. They’ll have to work with more downstream with ISPs and people doing DNS resolution.
Liu: That may be, but the DPRIVE effort has more momentum than most things I’ve tracked. The bottom line is, if this becomes an internet standard, Infoblox will make it possible for customers to deploy it.
Rasmussen: Yep, and the silver lining is that if you aren’t using DNS firewalling or DNS analytics to protect your network, which you should be doing already, then dealing with encrypted DNS traffic will get you there.
