Measuring Encrypted-DNS Censorship Using OONI Probe

OONI is a non-profit free software project that aims to empower decentralised efforts in documenting Internet censorship around the world. We at OONI develop the free software, OONI Probe app, with which you can measure website blocking, instant messaging apps (such as Telegram), and circumvention tools.

As soon as you run OONI probe, your test results are automatically published as open data in real-time. OONI Explorer (and the OONI API) enable the public to track censorship events around the world based on openly available measurement data.

In collaboration with our partners, we publish research reports and research papers documenting cases of Internet censorship around the world. These reports and papers share relevant OONI measurements and aim to enable human rights defenders, journalists, activists, and lawyers to use these censorship findings as part of their work.

Thanks to our global community, more than 800 million network measurements have been published from more than 200 countries since 2012, shedding light on Internet censorship worldwide.

What is encrypted DNS?

When you enter a URL such as https://example.com/, under the hood, your web browser resolves the example.com domain to one or more IP addresses using the Domain Name System (DNS), a set of federated servers and protocols providing this name-to-IP-address mapping.

For example, as of 16 June 2022, example.com resolves to the 93.184.216.34 (IPv4) and 2606:2800:220:1:248:1893:25c8:1946 (IPv6) addresses. Once the browser knows the IP addresses for the domain, it uses them to fetch the requested webpage. Conceptually, the browser tries the IP addresses in sequence until it finds one that works. If no returned IP address works, the request fails. Therefore, domain name lookups are key to browsing and, incidentally, are also key to website censorship and surveillance.

Historically, browsers and tools have always performed DNS resolution with an unencrypted protocol using UDP on port 53. Because such a protocol is not encrypted, censors could tamper with domain name resolution or observe and log the domain names you resolve.

The Internet community has been working to secure domain name resolution for a few years by proposing and implementing encrypted DNS protocols. The DNS over TLS (DoT) protocol uses Transport Layer Security (TLS) to encrypt and authenticate domain name lookups. In a similar vein, the DNS over HTTPS (DoH) protocol proposes to use encrypted HTTP (HTTPS) to keep your domain name lookups safe from tampering and prying eyes.

In other words, these two new protocols increase user privacy and provide a mechanism to bypass ordinary domain name resolution censorship. Yet, censors could block attempts to use DoT or DoH services, thus preventing users from reaping their benefits in terms of extra privacy and censorship circumvention.

The dnscheck experiment

The OONI Probe App allows users to select which Internet censorship experiments they want to run. As previously mentioned, we include checks for the blocking of websites and instant messaging apps among other tests.

To investigate the blocking of DoT and DoH, last year we designed a new experiment called dnscheck and conducted a one-month-long dnscheck measurement campaign in Kazakhstan, Iran, and China using our research-oriented tool miniooni. We documented this work in the Measuring DoT/DoH Blocking Using OONI Probe: a Preliminary Study research paper, presented at the Network and Distributed System Security Symposium (NDSS’21) in the context of the DNS Privacy Workshop.

Because we are incrementally rolling out dnscheck to all OONI Probe users, this seems to be a good moment in time to refer to the research paper, explain how dnscheck works, and summarise the main findings of our measurement campaign. To learn more about this topic, continue reading this blog post, refer to the research paper, or scroll down to the end of the article to watch OONI’s Simone present the paper at the DNS Privacy Workshop.

How dnscheck works

Because we are measuring the blocking of encrypted DNS services, what matters to dnscheck is not the name we would like to resolve (example.com in the example above). Instead, what matters is the specific DoT or DoH service measured.

Because DoH is DNS over HTTPS, users access DoH services by URL. For example, https://1.1.1.1/dns-query is the URL identifying Cloudflare’s public DoH resolver. While this specific URL contains an IP address (1.1.1.1), DoH URLs have domain names in other cases. For example, an alternative URL for Cloudflare’s public DoH resolver is https://dns.cloudflare.com/dns-query.

DoT is similar to DoH in that a service endpoint could contain an IP address or a domain name. However, unlike DoH, you generally identify DoT service endpoints by their IP address and port (e.g., 8.8.4.4:853) or by their domain name and port (for example, dns.google:853).

In short, regardless of whether we want to measure DoT or DoH, there are two cases:

1. The service endpoint contains a domain name
2. The service endpoint contains an IP address

The first case — when the service endpoint contains a domain name — is more complex to measure. We need to use the ordinary unencrypted DNS to map the domain name into a list of IP addresses. Once that step is complete, we can measure each IP address using either DoT or DoH. I’ll use an example to clarify the process.

Suppose you ask dnscheck to measure https://dns.google/dns-query. Then, dnscheck would notice that dns.google is a domain name and would use the unencrypted DNS to obtain IP addresses for dns.google. Suppose this operation is successful and yields 8.8.8.8 and 8.8.4.4. Then dnscheck will measure both https://8.8.8.8/dns-query and https://8.8.4.4/dns-query.

The second case is more immediate. If you ask dnscheck to measure https://8.8.8.8/dns-query, it will notice that 8.8.8.8 is already an IP address, and it will just measure https://8.8.8.8/dns-query.

What happens, though, if there’s DNS blocking of the dns.google domain name?

In its most simplistic configuration, dnscheck would conclude that the service endpoint’s domain name is blocked and will stop the measurement. However, it is also possible to tell dnscheck what are known-valid IP addresses for the domain. In such a case, dnscheck will continue the measurement using the known-valid IP addresses to check for additional censorship of the given service endpoint. We took advantage of this opportunity to provide a more comprehensive censorship assessment for the measurement campaign in Kazakhstan, Iran, and China.

Returning to the measurement algorithm, once dnscheck knows the IP address(es) of a service endpoint, it measures each IP address. In practice, it means that, for each IP address, dnscheck performs the following operations:

1. Establish a TCP connection to the given IP address and port (for the above https://8.8.8.8/dns-query example, that would be 8.8.8.8 on port 443)
2. Create a TLS channel over the TCP connection (DNS-over-TLS uses TLS and DNS-over-HTTPS also uses TLS because HTTPS is HTTP over TLS)
3. Create a DNS query for example.com and send the query using the rules defined by the specific protocol (DNS-over-TLS uses a straightforward algorithm for sending DNS messages while DNS-over-HTTPS encapsulates messages inside HTTP messages, so it is a bit more complex)
4. Receive from the server the corresponding DNS response

We say the experiment is successful (for a given IP address and port) if we complete all these steps. If the first step fails, we say there is TCP/IP blocking. If the second step fails, there is TLS blocking. If the third or fourth step fails, we say there is TLS interference after establishing a TLS session (aka ‘interference after the TLS handshake’).

It is important to note that a given service endpoint could be partially blocked. For example, there could be a case where https://dns.google/dns-query is blocked when using the 8.8.8.8 IP address and works as intended when using 8.8.4.4.

Summary of the main findings

The general goal of this measurement campaign was to investigate DoT/DoH service endpoint blocking in selected economies. To this end, we compiled a list of 123 public DoT/DoH services (in December 2020 and January 2021) and with help from volunteer users, we ran measurements in Kazakhstan (AS48716), Iran (AS197207), and China (AS45090).

Most endpoints failed or succeeded consistently. That is, if an endpoint failed for a given OONI Probe user, it failed all the time with the same failure. There were just a couple of exceptions to this general trend, which are documented in the research paper.

We were surprised to discover that there was no interference when mapping the service endpoint’s domain name (for example, dns.google) to IP addresses (for example, 8.8.8.8 and 8.8.4.4). The only exception to this trend was Iran, where dns.adguard.com mapped to 10.10.34.36, a well-known private IP address used for censoring.

Blocking, instead, focused on preventing TCP or TLS communication between OONI Probe and the IP address(es) used by DoT/DoH services. The following table summarises our findings in terms of blocking by protocol:

As you can see, many lookups succeeded. Blocking was the most aggressive in Iran: 50% of the DoT endpoints were not working. It seems reasonable to see more censorship in the Iranian network we tested than in the other two networks. In Iran, we ran measurements from one of the most popular mobile networks, while we used VPSs in China and Kazakhstan.

In terms of blocking by the company providing the service, Cloudflare’s was the most blocked service in the pack in several cases (and was more frequently blocked than other companies services such as Google’s and Quad9’s):

Cloudflare blocking was especially apparent in the Kazakhstan network we tested. In the other networks, especially in Iran, blocking is more spread across companies. Again, this probably happens because we measured from a consumer-facing network in Iran.

Each network implemented distinct blocking policies. The following table summarises the reason for blocking DoH lookups:

In China, there’s a prevalence of TCP/IP blocking. Iran and Kazakhstan, there’s mostly interference with the TLS sessions.

In the Kazakhstan network we tested, TLS interference seemed to depend on the name of the service we’re accessing as shown by the following table (which shows DoH measurements):

These measurements used the same IPv6 address (2606:4700::6810:f8f9). However, using cloudflare-dns.com causes a failure, while using mozilla.cloudflare-dns.com works. Because the failure happens (in most cases) when creating or using a TLS session (that is, after the TLS handshake), this seems to be a case of Server Name Indication based blocking.

Conversely, in Iran, we confirmed our previous result showing that DoT traffic is blocked during the TLS handshake regardless of the name of the service:

The first and the second row show that, with 8.8.4.4, using 8888.google as the server name or just testing without a server name yields the same result: A timeout during the TLS handshake. Yet, using another IP address (8.8.8.8) with the 8888.google server name does not cause any blocking, suggesting there was 8.8.4.4-specific blocking.

Concluding remarks

As far as we know, this research was the first account of DoT and DoH blocking. Since our initial measurement campaign in late 2020, other researchers started studying encrypted DNS blocking. As dnscheck is now integrated into OONI Probe, we can continue to collect DoT/DoH blocking information and hopefully produce more comprehensive analysis of the phenomenon in the future.