What DNS Encryption Means for Your IP TrafficWhat DNS Encryption Means for Your IP Traffic

Google recently announced that it'll be adding "DNS over TLS," an extra level of encryption, in Android. This will prevent enterprises and ISPs from being able to monitor which sites a user goes to, and has implications for WAN optimization and software-defined WAN (SD-WAN) vendors as well.

Web applications use proxies as Internet relays to identify a user's intended destination and to permit or deny the user access to that site, as well as to log each site a user visits. DNS, or domain name server, is at the core of this process, and encrypting DNS inquiries will make simple proxies useless. Users will be able to visit any sites they'd like without a third party logging their Internet journeys. The spread of YouTube cute cat videos will continue.

DNS query without TLS to a TLS-encrypted application

Encryption is changing how networks are designed and run. First came application encryption using TLS, or Transport Layer Security -- not only for transactions with money or sensitive information, but for all applications. Google amplified TLS use by putting encrypted sites higher than non-encrypted sites in search results. Google reports that 73% of pages in the U.S. are now delivered with encryption.

WAN optimization is limited on what it can do with TLS-encrypted application traffic. This factor, plus the dramatic growth in real-time voice and video over the network, has led to a decline in the WAN optimization market. Most of WAN optimization vendors are pivoting into SD-WAN in an effort to offset this decline.

But SD-WAN and other vendors will be impacted by DNS over TLS, as well. Today, many SD-WAN vendors provide automatic application identification schemas that use DNS. They look at the TCP/UDP ports to identify a service such as Web, email, voice, or video, and then turn to DNS to identify the application using the underlying service.

One potential workaround will be to use the TLS setup process for application identification, permissions, network prioritization, and logging. A session state-aware firewall or proxy can then do a reverse DNS lookup on the destination IP address. (When a device is aware of session state, it tracks and ties together all packets in a flow rather than just forwarding them as routers do.)

Another option is to use the TLS setup process to grab the DNS name. This too requires a proxy or firewall to be session state-aware. The figure below shows that the 5th packet in the "Server Hello" message in a TLS session setup identifies the application that is starting.

Application and site identification using TLS

Enterprises will definitely find a way to work around this latest encryption change, even if it means incurring the expense of replacing their simple proxies and firewalls with expensive ones that are TLS session state-aware. ISPs, on the other hand, will be hesitant to spend a lot more money without some type of government mandate or incentive.

Bottom line: Understanding and controlling what's going over an IP network will become more challenging as applications move to the public cloud and TLS, including TLS for DNS, is put into widespread use.