Introduction
In Whalebone, we envision the world where #ConnectedMeansProtected, which is why we warmly welcome and embrace any initiatives that make the Internet a more secure and privacy-aware space.
In the last few years, one of the “trending” topics that aim to contribute towards that goal, is the introduction of two new protocols: DNS over TLS and DNS over HTTPS.
As it happens with every new protocol, there is an initial period of ad-hoc implementations and experimentation before the Internet Engineering Task Force (IETF) adjourns a Working Group and releases a new Standard, in the form of an RFC (Request for Comments) to be followed.
Read further to find out what has happened so far and what lies ahead in the near future.
Glossary:
Do53: Traditional DNS over UDP/TCP
DoH: DNS over HTTPS
DoT: DNS over TLS
A new old story
Before delving into the main topic, let’s take a short trip down to the memory lane of the “History of the Internet.”
In the beginning, there was HTTP.
The year is 2008 – the Internet is a vast ocean of unencrypted websites serving their content over plaintext HTTP.
Banks and payment institutions with an online presence are the first ones to adopt HTTP-level encryption via securing the connections with Transport Layer Security (TLS), which is more widely known as HTTPS.
The first widespread efforts to introduce HTTPS are led by Gmail, which introduces a secure version. The major breakthrough came in 2016 when Let’s Encrypt started issuing free TLS certificates to anyone.
In 2021, almost 13 years after these first attempts, according to Google Chrome statistics over 99% of the browsing time the users are using the encrypted protocol - HTTPS. Browser features (i.e. marking websites as not secure, HSTS) are the main driving factors that have contributed to this transformation.
The important thing to notice is that this transition happened without affecting any service’s operation. If you were using http://my-favorite.bank.com in 2008, you can use the very same e-banking platform in 2021 in a (more) secure manner (i.e. over HTTPS) https://my-favorite.bank.com.
No one is forcing Internet users to change a banking services provider due to the underlying technological evolution.
This change is similar to when the unencrypted Web transitioned to HTTPS – your bank credentials are no longer transported unencrypted, but the bank is still able to provide you their services.
Following this great success of encrypting the HTTP-level traffic, the ball was on another cornerstone of the Internet: The Domain Name System (DNS).
DNS over TLS (DoT)
In 2016 the first encryption standard for DNS, DNS over TLS (DoT), was released.
The main idea that DNS over TLS introduced was the wrapping of DNS requests and responses via the Transport Layer Security (TLS) protocol.
This approach ensures that some observer between the end-user and the DNS resolver will not be able to tamper or track the content of the DNS requests.
Shortly afterward, Android introduced DoT as “Private DNS” on Android 9.
The operating system followed an Automatic (Opportunistic) approach:
if the DNS server that is configured on the system supports DNS over TLS then it would be preferred over the unencrypted version and would be used instead.
In case there is no equivalent DoT endpoint, then the traditional Do53 would be used.
DNS over HTTPS
Briefly after DoT was released, a new standard was introduced: DNS over HTTPS.
DNS over HTTPS built on all the accumulated experience of working with the HTTP protocol and modern browsers and operating systems quickly caught on its adoption.
Standards are important, but how to use them? The challenge of Discovery
Although everyone wanted to get up to speed and implement the new encrypted version of DNS, one challenge was still not resolved – discovery. To outline the problem of discovery in simple terms, we could define it as: “ given a device that connects to a network, how can it start using the encrypted DNS endpoints”.
Several novel implementations were followed. In the following paragraphs we are going to analyze two very different approaches from Mozilla Firefox and Google Chrome.
Mozilla Firefox - Trusted Recursive Resolvers
The first browser to introduce DoH was Mozilla Firefox, which followed a unique approach.
For users in the USA, DNS over HTTPS was enabled as a default option using a set of Trusted Recursive Resolvers.
These Trusted Recursive Resolvers (Cloudflare and NextDNS at the time) would receive all the DNS traffic of users that would not explicitly opt out.
In this approach, a network operator that would like to disable DNS over HTTPS could set up the canary domain (use-application-dns.net) to return a negative response e.g., NXDOMAIN
This approach was met with strong opposition as it essentially centralized the DNS resolution to few selected 3rd parties.
A characteristic manifestation of the backlash that Mozilla caused, is the UK’s ISPA (Internet Service Providers Alliance) who nominated Mozilla as the Internet Villain of 2020, (they later withdrew this decision).
In late 2020, Mozilla opened a public comment period about this approach and the initial results can be found here.
Google Chrome – Same Provider Auto-Upgrade
Few months later, Google Chrome introduced DoH functionality in version 83. The key idea behind Chrome’s approach was to ensure that the Do53 and the DoH endpoint would be operated by the same provider.
To achieve this, a dedicated registration process was launched where each provider could correlate a set of IP addresses with a DoH endpoint.
The final result could be understood as the following mapping:
- Upon start-up, Google Chrome checks if the user’s current DNS provider has provided an equivalent DoH endpoint.
- In case the DoH endpoint is available, then Chrome will perform the resolution via DoH and the designated equivalent endpoint.
- In case the DoH endpoint is not available, then Chrome will use the Do53 resolver that has been configured.
What’s next?
In early 2020, as the problem of “Discovery” remained a vast and complex topic involving multiple stakeholders, IETF formed a working group Adaptive DNS Discovery (ADD) to standardize the approaches.
In the very recent IETF 111, several sessions were dedicated to the matter in hand, to smoothly allow for the discovery of the Encrypted DNS resolvers while making sure that the end-users will be able to enjoy the same level of service.
The Standard that is mainly addressing this scenario is “Discovery of Designated Resolvers” (DDR) which suggests to utilize specifically crafted DNS records. The newly defined Service Binding records (SVCB) will be served from the existing DNS resolvers and will designate the equivalent encrypted DoH and DoT endpoints.
When an unencrypted DNS resolver’s IP address (Do53) is assigned in the network, e.g. via DHCP, the client device is able to query for the SVCB record and automatically discover the respective encrypted resolver (DoT or DoH).
A resolver can craft a response to an SVCB request like the following, where the domain(_doh.example.net), query paths(/dns-query{?dns}) and preferred protocol ( alpn=h2) are defined (optionally port and priority can be also included). Upon receiving the response the client can verify and initiate the connection to the newly discovered endpoints.
Conclusion
Provided that DNS is a crucial service for any online communication, it is of paramount importance to create support for robust protocols that improve its confidentiality and integrity. As the first paragraphs of the post have outlined, these requirements can be fulfilled by the introduction and establishment of DoH and DoT.
At the same time, it becomes evident that DNS is not only serving as the data plane, but also as the control plane enabling operators to offer security and content filtering services. The way that new technologies will be adopted, needs to provision equivalent options and ensure that network-wide policies can be adopted. For this very reason, the ongoing efforts for standardization of the way that end users can begin to utilize the described benefits of encrypted DNS creates a very promising landscape towards a more secure and privacy-preserving Internet.
At Whalebone we can help you adopt Encrypted DNS in your networks. Get in touch and find out how.
