Re-add use-application-dns.net - explicit signal for DNS filtering #1419
Conversation
This domain is meant to be used as a signal that overt DNS filtering is in effect. Applications can try to resolve the name as a test for the presence of DNS filtering. DNS filters that wish to announce their presence can respond with NXDOMAIN rather than an IP address, to cause some applications to disable DNS over HTTP support. https://support.mozilla.org/en-US/kb/canary-domain-use-application-dnsnet https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https
|
The canary domain only applies to users who have DoH enabled as the default option. It does not apply for users who have made the choice to turn on DoH by themselves. dnscrypt-proxy also blocks |
There was a problem hiding this comment.
I think we should merge to collect data about which networks seem to block use-application-dns.net. For the analysis, I think we should limit ourselves with analyzing queries generated by getaddrinfo, which should be the automatically configured resolver. But we should also keep in mind that, under specific setups, (e.g., dnscrypt-proxy and possibly others), we could get false positives (i.e., the block depends on the local user's configuration and not on the network).
🐳
With the news that Firefox plans to start enabling ECH in the next releases, I wanted to suggest people check censorship measurements for use-application-dns.net, because that canary domain is meant to disable DoH, and ECH depends on DoH.
use-application-dns.net had originally been added in #504 2019-09-19, but then it was deleted in #727 (a dead-domain check) on 2021-02-23.
Maybe prune-dead-urls.py was run on a network that reported NXDOMAIN for use-application-dns.net, since that is the signal that is supposed to signal DNS filtering is in place?