For the vast majority of its existence, DNS has been public by default, but renewed concerns about privacy have forced changes. Apple is now pushing DoH and DoT, which both allow devices to make DNS inquiries encrypted and to choose a trusted DNS server for most queries. Microsoft is pursuing a similar approach.
The privacy concerns go beyond strict compliance issues—although EU’s GDPR considers IP addresses PII and it’s far from alone among regulators—and deal with the most core elements of privacy. Anyone, from cyberthieves to government bureaucrats and nosey neighbors, can track every domain inquiry and user posts, which is a roadmap to every Web site visited. Of far greater concern is that such individuals could, in theory, interfere with DNS searches and send users elsewhere, potentially to malware-laden sites or even just to ad-supported sites that pay for traffic. For some geographies, this will enable easy government censorship.
In the United States, most businesses and consumers take it for granted that the major carriers have comprehensive browsing history for all who use their services. Given the reality that many companies try and gather sensitive information to sell—or to precisely target users with ads that pay more for fine-tuned focus on desired segments—enterprises need to rethink their DNS strategies immediately.
Even aside from the need to protect customer information, DNS history can reveal what companies are being evaluated for acquisition, imminent terminations, future product plans, and other highly sensitive matters.
That said, protecting DNS data is complicated and is riddled with exceptions. And DNS data privacy compliance issues go beyond the typical regulatory concerns. The U.S. FTC, for example, requires enterprises to strictly adhere to their own published privacy policies and terms of use. If those documents promise confidential browsing activity, those enterprises better have a secure means of conducting DNS inquiries.
Even worse, both Apple’s and Microsoft’s encrypted DNS approaches are implemented at the application level. What happens in an enterprise if 140 applications start trying to resolve DNS in 140 different ways? Alternatively, what if an enterprise is using policies to control how devices attach into the network? Imagine the conflicts from having an OS that can bypass functions and an application that is doing exfiltration over the VPN? What about employees accessing hotel or airport WiFis and trying to surf the Web? What can the enterprise do to possibly protect the DNS activity records in those scenarios?
As for complexity, in Apple’s approaches, enterprise MDMs require profiles to explicitly permit encrypted DNS activity on an enterprise network. From a consumer perspective, what if a parent wants to make sure that parental controls are working properly? Today’s hodgepodge of different controls means that parents likely have no meaningful insight into how well the app is working.
There is an inherent sadness to the fact that we must protect DNS in this way, given that it’s initial openness was noble and trusting. It was well known that there was this gaping security hole in DNS, where it could be spoofed, hijacked and tracked/monitored. Today, alas, enterprises have an obligation to protect all sensitive data, and DNS records absolutely qualify.
It is critical today to manage DNS encryption centrally—or via a trusted third-party—so one set of rules manages all DNS inquiries from anywhere to anywhere. That is just as true for enterprises as it is for carriers.
