Encrypted DNS itself is not new, it’s been around for a decade. What is changing is how it’s being deployed and made available.
While some of the changes can be applauded, many of the deployments are proving to be problematic to parents, schools, and other organizations looking to create family-friendly environments for kids.
What is Encrypted DNS?
By design, DNS has traditionally been sent in what is known as “clear-text”. As the name implies, it is clear which implies it can be seen. So if your computer requests “cleanbrowsing.org” then someone on the network could see that a request was made, but more importantly what was in the request – i.e., cleanbrowsing.org.
Encryption serves to make something that is readable, not readable.
It doesn’t affect how you make the request but does change how the content of the request is transferred from one location to another. For instance, the same “cleanbrowsing.org” request on the network might look like this “Y2xlYW5icaSDfasdm93c2luZy5vcmc=” to someone monitoring the network.
This is a gross oversimplification of the process, but the point is the same. Encryption makes readable things unreadable to anyone that might be snooping on the network.
Why do we need Encrypted DNS?
The driving force for encryption has always been security and privacy. With DNS it was about combating the overreach of Internet Service Providers (ISP) and Governments.
At a micro level, seeing I requested “cleanbrowsing.org” probably isn’t horrible, but when you look at it from a macro level that would imply an organization can ascertain online behavior, interests, and in some instances intent. Those insights could then be sold to organizations, and in some instances used by governments to silence dissidents.
So at its core, encrypted DNS, similar to encrypted HTTP (i.e, HTTPS) is about ensuring that no-one can see what we’re up to on the network. It’s about ensuring the users’ privacy, their security.
At face value, we too agree with the basic premise that has driven the current strategy. But what happens in a world where the users are not the same? What happens in a world where a user is 5 years old? What happens in a world where a parent explicitly decides what should, and should not, be allowed on their home network?
What is Changing with Encrypted DNS?
While DNSCrypt has been around for a decade, adoption has been relatively low. There are several reasons for this, but for me, I’d attribute it to two simple barriers to entry – too technical and poor integration.
This, however, is changing and it’s being facilitated by its biggest sponsor – browsers. The browser’s support of encryption has brought about a massive change in the industry. From the introduction of new encryption protocols like DNS-over-HTTPS (DOH), to the renewed focus on integrations.
Their renewed interest has dramatically affected a dormant ecosystem.
It’s brought about massive adoption across all major browsers. It has introduced things like “Secure DNS” which is built on DNS-over-HTTPS (DOH). It also brought about mass adoption by Operating Systems (OS) (e.g., Apple, Windows, etc..) who have introduced new mechanisms that the OS and app developers can leverage to encrypt their app-specific DNS data.
While progress is welcome, it is based on a basic premise that all users are the same. They are not. It currently fails to into consideration explicit choice.
Why should Parents, Schools, and Organizations care?
If you are a parent, school, library, municipality, or any organization charged with creating a family-friendly network then this should matter because, for all the good it introduces, it also introduces new challenges with its current implementation.
By design, these options are relatively simple for a user – any user, of any age – to enable. When they do, they immediately circumvent any controls you might have in place. And there are few mechanisms available to non-Enterprise users to prevent, or block, this.
This is how this all manifests itself for you:
– Browsers: Almost all major browsers have introduced a “Secure DNS” option by default. This option is located in the Browser settings, and more often than not inside the “Security & Privacy”, or “Network” control panel.
– Operating Systems: OS’s have always been a bit slower to adopt technologies, but they are slowly turning the corner. Apple is leading the charge, and in doing so has extended its changes to include new encryption mechanisms for apps. This means that app developers can now build their apps with their encrypted DNS configurations that will immediately circumvent any controls you have in place (a great example of this is TikTok).
What makes things more challenging is that by default it’s extremely difficult for non-enterprise users to disable these features. Since its announcement, enterprise users have been up in arms about it and with that noise, they have been given options to disable and better control the rollout.
For non-enterprise users, the opposite is true and the general approach is – “we know what is best for you.“
The roll-out assumes that all users are the same, but does very little to account for an underrepresented audience – pre-pubescent users (i.e., kids) and their parents and school administrators that might lack the technology or knowledge to combat these new technologies.
While there is little, at the moment, that can be done at the OS and app level, there is something you can do about the browser level.
To help, we’ve prepared the following article that expands on how Encrypted DNS is being used to bypass content filtering services and gives you an option to disable it on your systems. Guide to Disable Secure DNS
Encrypted DNS is Good. Forcing it is Not.
Here at CleanBrowsing we are not against Encrypted DNS. We support all available encryption options, and our own apps leverage it when being deployed in their respective devices. Where we do draw issue is with this idea that as technology platforms we have the right to decide what should, and should not be used, and forcing that on users with little regard to choice or consent.
Here are some of my thoughts on the subject, shared at the recent SDNS://2021 conference: