Towards Automated DNS Censorship Circumvention
Felix Lange, Niklas Niere, Juraj Somorovsky
https://www.petsymposium.org/foci/2026/foci-2026-0001.php
https://github.com/UPB-SysSec/DPYProxy
This paper is about DPYProxy-DNS, a feature for automatic DNS circumvention recently that was recently added to DPYProxy, a client-side-only circumvention tool. DPYProxy-DNS works as a local resolver and automatically applies a battery of known DNS circumvention techniques (with several public DNS resolvers) to find one that does not get blocked. It finds techniques that work in China and Iran, according to vantage point measurements. The paper includes a survey of support for various DNS transport protocols by public resolvers and a discussion of how web browsers’ built-in encrypted DNS support fails to be blocking-resistant.
DPYProxy-DNS supports eight circumvention modes, four unencrypted and four encrypted:
- Unencrypted
- Plaintext UDP on port 53. This is the classic way of doing DNS resolution. It works only in the absence of DNS censorship, basically.
- Plaintext UDP and waiting for the last response. (Like “Hold-On”.) DNS injection attacks work by sending a false DNS reponse that arrives sooner than the real one. Under such an attack, simply waiting and honoring the last response, rather than the first, recovers the real response.
- Plaintext TCP on port 53. Some systems may treat TCP-based DNS differently from UDP-based DNS.
- Plaintext TCP with segmentation. One DNS query is sent as multiple TCP segments.
- Encrypted
- DNS over TLS (DoT).
- DNS over HTTPS (DoH).
- DNS over HTTP/3 (DoH3).
- DNS over QUIC (DoQ).
The authors surveyed public DNS resolvers from the DNS Privacy Project, Wikipedia, and from the preconfigured resolvers of Chromium and Firefox, to test them for support for the various modes of DNS. For the encrypted modes, they tested the servers with and without SNI. (As it happens, none of the resolvers requires SNI, and some even respond with an IP address certificate, meaning the server’s identity can be verified in the normal way.) Then, from vantage points in China and Iran, they tried all the mode–resolver combinations that had been tested to work. In China, the UDP+wait and TCP segmentation modes were successful (except with Cloudflare’s 1.1.1.1 resolver, which is blocked by IP address), and encrypted modes worked with certain resolvers (sometimes requiring the omission of SNI). In Iran, UDP+wait does not work, because the firewall there is in-path and drops the query, so there is no real response to wait for. TCP segmentation worked inconsistently. DoQ worked with any resolver, and other encrypted modes worked with certain resolvers (more often when SNI was omitted).
Web browsers these days support encrypted DNS, but the way they use it is more easily blocked than it could be. For one thing, browsers do an initial plaintext UDP query for the domain name of the encrypted resolver itself (e.g. mozilla.cloudflare-dns.com), and these domain names are often censored even if access to resolver would be allowed. For another, browsers send SNI, which makes the connection easier to filter, and which this paper’s survey finds is unnecessary with common public resolvers.
Thanks to the authors for reviewing a draft of this summary.