Your Replies
-
Sadly, no. The following DoH and DoT providers are still not blocked:
- 2.dnscrypt-cert.ns1.developer.li
- 2.dnscrypt-cert.ns2.developer.li
- 2.dnscrypt-cert.ns3.ca.luggs.co
- 2.dnscrypt-cert.ns4.ca.luggs.co
- 2.dnscrypt-cert.opennic.i2pd.xyz
- 2.dnscrypt-cert.opennic.peer3.famicoman.phillymesh.net
- 2.dnscrypt-cert.oszx.co
- 2.dnscrypt.cert.jolteon.boothlabs.me
- ads-doh.securedns.eu
- bornfiber.anycast.censurfridns.dk
- deic-lgb.anycast.censurfridns.dk
- deic-ore.anycast.censurfridns.dk
- dns-tls.bitwiseshift.net
- dns.bitgeek.in
- dns.flatuslifir.is
- dns.larsdebruin.net
- dns.neutopia.org
- dns.twnic.tw
- dns2.developer.li
- dnscrypt.nl.public-dns.lchimp.com
- dnsotls.lab.nic.cl
- dnsovertls.sinodun.com
- dnsovertls1.sinodun.com
- dnsovertls2.sinodun.com
- dnsovertls3.sinodun.com
- doh-fi.blahdns.com
- doh-ipv6.crypto.sx
- doh.applied-privacy.net
- doh.blockerdns.com
- doh.dnslify.com
- doh.xfinity.com
- dohdot.coxlab.net
- dot-ch.blahdns.com
- dot-de.blahdns.com
- dot-jp.blahdns.com
- dot.securedns.eu
- dot1.appliedprivacy.net
- dot1.dnswarden.com
- dot2.dnswarden.com
- ea-dns.rubyfish.cn
- edns.233py.com
- getdnsapi.net
- iana.tenta.io
- jolteon.boothlabs.me
- jp.gridns.xyz
- kaitain.restena.lu
- kracon.anycast.censurfridns.dk
- mozilla.cloudflare-dns.com
- ndns.233py.com
- nl.public-dns.lchimp.com
- ns1.dnsprivacy.at
- ns2.dnsprivacy.at
- odvr.nic.cz
- opennic.peer3.famicoman.phillymesh.net
- opennic.tenta.io
- privacydns.go6lab.si
- private.canadianshield.cira.ca
- protected.canadianshield.cira.ca
- public.dns.iij.jp
- rgnet-iad.anycast.censurfridns.dk
- sdns.233py.com
- security.cloudflare-dns.com
- sg.gridns.xyz
- solido.anycast.censurfridns.dk
- tls-dns-u.odvr.dns-oarc.net
- unicast.censurfridns.dk
- uw-dns.rubyfish.cn
- wdns.233py.com
- <i>security-filter-dns.cleanbrowsing.org</i>
Additionally, the previously mentioned Firefox settings illustrate the fact that the DoH services offered by CleanBrowsing for basic security filtering can be used to circumvent the Family Filter DNS service offered by CleanBrowsing over the regular DNS protocol. Solving this issue would require adjustments to the domain names used to offer the DoH service and classifying them accordingly. While separate domains were correctly used for DNS over TLS, the Security Filter is not yet classified as a VPN or Proxy.
Most of the DNS over TLS domains I submitted earlier (#post-2062) do not appear to have been re-classified yet.
I suspect this is because the protocol runs over a different port. By default, the port is 853. (https://tools.ietf.org/html/rfc7858#section-3.1)
While this protocol is easily blocked via egress filtering, most home users would probably not be comfortable setting this up.
There are a few new DoH providers that should be re-classified as “Proxy & VPN”:- https://doh.xfinity.com/dns-query
- https://dohdot.coxlab.net/dns-query
- https://doh-fi.blahdns.com
- https://doh.applied-privacy.net/query
- https://dns.twnic.tw/dns-query
- https://example.doh.blockerdns.com/dns-query
I recommend monitoring the Curl project’s WIKI (https://github.com/curl/curl/wiki/DNS-over-HTTPS/) for changes using GitHub’s revision comparison feature:
Most of the DNS over TLS domains I submitted earlier do not appear to have been re-classified yet.
I suspect this is because the protocol runs over a different port. By default, the port is 853. (https://tools.ietf.org/html/rfc7858#section-3.1)There are a few new DoH providers that should be re-classified as proxy/VPNs:
- https://doh.xfinity.com/dns-query
- https://dohdot.coxlab.net/dns-query
- https://doh-fi.blahdns.com
- https://doh.applied-privacy.net/query
- https://dns.twnic.tw/dns-query
- https://example.doh.blockerdns.com/dns-query
I recommend monitoring the Curl project’s WIKI (https://github.com/curl/curl/wiki/DNS-over-HTTPS/) for changes using GitHub’s revision comparison feature:
I recently posted a reply to the following topic and the post does not display. I’ve tried twice without any luck:
I certainly share your grief. So long as you are blocking the “Proxy & VPN” category, you should be able to stop most of the DoH providers that I contributed in a separate post.
DNS-over-HTTPS (DoH) providers not classified as "Proxy & VPN" or similar
My understanding of how Firefox’s implementation of DoH works:
- FF looks at the DoH URL specified by the end user
- If the URL contains a domain name (Ex. mozilla.cloudflare-dns.com), and the setting “network.trr.mode”=2, FF sends a DNS query over port 53 to either:
The DNS forwarder IP handed out by DHCP
The DNS forwarder IP statically assigned by the user in the network settings on their device - If the URL contains a domain name (Ex. mozilla.cloudflare-dns.com), and the setting “network.trr.mode”=3, FF grabs the IP from the setting “network.trr.bootstrapAddress” (effectively, a permanent cache)
- FireFox connects to the DoH server over HTTPS and verifies that the server’s HTTPS certificate is valid for the domain OR IP that was specified
- All subsequent DNS queries are forwarded to the DoH server privately over port 443 (HTTPS)
By blocking outbound traffic to port 53 (DNS), you should be able to stop FireFox from getting the IP of the DoH server if it doesn’t already have it. That last part presents the most problems:
- Some DoH providers have already gone about creating HTTPS certificates that allow you to access the service via their IP addresses without any certificate errors. A great example of this is CloudFlare. Unless you configure your firewall to block all traffic to 1.1.1.1, users will be able to specify this IP in their FireFox settings. Quad9 is another one. I haven’t seen any others just yet, but it is just a matter of time.
- FireFox seems to cache the response back in step 2 above. This means that a mobile device could move to a network without CleanBrowsing enforced, cache the IP of the DoH provider in FF, and after the device moves back to your network, FF may be able to use the cached IP to send DoH queries without issue (bypassing the filter). I haven’t tested this, but it might work if FF expires the cache per the record’s TTL and the TTL happens to be rather lengthy.
- The “network.trr.bootstrapAddress” setting allows end users to bypass the need to send any un-encrypted DNS traffic and effectively bypass all DNS filtering provided by CleanBrowsing
The only effective means to block DoH without sacrificing privacy seems to be IP blacklisting. HTTPS filtering can help, but it will reduce user privacy and is hard to pull off in a home environment. Sadly, the CleanBrowsing app doesn’t have any IP blacklist capability to deal with this issue, so mobile users will get past the DNS filter unless you create your own VPN and “tether” them to your firewall using MDM policies.
Some other ports you may want to block are 853 (DNS over TLS), 5053 (DNS over HTTPS Alternate used by CloudFlare), and 784 (DNS over QUIC).
In order to use CleanBrowsing, you’ll have to disable Avast’s SecureDNS feature.
https://help.avast.com/en/av_free/12/etc_tools_secure_dns_overview.html
Hopefully they’ll add that link to their troubleshooting page:
https://cleanbrowsing.org/guides/common-questions-troubleshooting-cleanbrowsing
I expect that such a drastic change in service offerings is a tough move to make for CleanBrowsing. If I were them, I’d probably create custom block page to ensure users of the old DoH service (doh.cleanbrowsing.org) are informed of the pending service change. By monitoring the traffic flowing in, you can better decide whether to block/redirect more content categories (increasing the number of people who will get the message). By starting with the more technical categories, you can target the techies first. Quite frankly, all of the service offerings should be on different domains similar to what they did for the DNS over TLS service. Speaking of which…
I have since found several other sites that offer DNSCrypt, DNS over TLS, and DoH services. They should all be classified as “Proxy & VPN”
The following was sourced from: https://blog.cloudflare.com/welcome-hidden-resolver/
- tor.cloudflare-dns.com
The following were sourced from: https://download.dnscrypt.info/dnscrypt-resolvers/json/public-resolvers.json
- ads-doh.securedns.eu
- dns.twnic.tw
- dns2.developer.li
- doh-ipv6.crypto.sx
- ea-dns.rubyfish.cn
- edns.233py.com
- jp.gridns.xyz
- ndns.233py.com
- public.dns.iij.jp
- sdns.233py.com
- sg.gridns.xyz
- uw-dns.rubyfish.cn
- wdns.233py.com
The following was sourced directly from: https://blahdns.com/
- dot-ch.blahdns.com
The following was sourced from: https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers
- 2.dnscrypt-cert.oszx.co
- dns-tls.bitwiseshift.net
- dns.bitgeek.in
- dns.larsdebruin.net
- dns.neutopia.org
- dnsotls.lab.nic.cl
- dnsovertls.sinodun.com
- dnsovertls1.sinodun.com
- dnsovertls2.sinodun.com
- dnsovertls3.sinodun.com
- dot-de.blahdns.com
- dot-jp.blahdns.com
- dot.securedns.eu
- dot1.appliedprivacy.net
- dot1.dnswarden.com
- dot2.dnswarden.com
- getdnsapi.net
- iana.tenta.io
- kaitain.restena.lu
- ns1.dnsprivacy.at
- ns2.dnsprivacy.at
- opennic.tenta.io
- privacydns.go6lab.si
- tls-dns-u.odvr.dns-oarc.net
- unicast.censurfridns.dk
The following was sourced from: https://blog.uncensoreddns.org/dns-servers/
- bornfiber.anycast.censurfridns.dk
- deic-lgb.anycast.censurfridns.dk
- deic-ore.anycast.censurfridns.dk
- kracon.anycast.censurfridns.dk
- rgnet-iad.anycast.censurfridns.dk
- solido.anycast.censurfridns.dk
The following was sourced from: https://servers.opennic.org/
- 2.dnscrypt-cert.ns3.ca.luggs.co
- 2.dnscrypt-cert.ns4.ca.luggs.co
- 2.dnscrypt.cert.jolteon.boothlabs.me
- jolteon.boothlabs.me
- 2.dnscrypt-cert.ns2.developer.li
- 2.dnscrypt-cert.opennic.i2pd.xyz
- 2.dnscrypt-cert.ns1.developer.li
- 2.dnscrypt-cert.ns3.ca.luggs.co
- opennic.peer3.famicoman.phillymesh.net
- 2.dnscrypt-cert.opennic.peer3.famicoman.phillymesh.net
- nl.public-dns.lchimp.com
- dnscrypt.nl.public-dns.lchimp.com
The following are general web proxies sourced from: https://wiki.opennic.org/
- proxy.opennic.org
- proxy.dnslibre.com.mx
Thank you for getting these in there.
That being said, I noticed a couple of issues with the changes that were made:
The following was not correctly categorized as a “Proxy & VPN”. I suspect that the custom port number is causing some difficulty with the import.
You can still use the following settings in Mozilla Firefox’s about:config page to bypass the CleanBrowsing Family Filter
- “Setting”, “Value”
- “network.trr.mode”, 2
- “network.trr.uri”, “https://doh.cleanbrowsing.org/doh/security-filter/”
- “network.trr.custom_uri”, “https://doh.cleanbrowsing.org/doh/security-filter/”
- “browser.startup.homepage”, “http://www.exampleadultsite.com/|https://www.dnsleaktest.com/|https://www.google.com/”
- “browser.startup.page”, 1
You may have to refresh the page after starting up the browser, but the example adult site loads even when the host operating system has been configured to use CleanBrowsing’s Family Filter.
If CleanBrowsing were to move the DoH service for Security Filtering to a different domain, you should be able to correctly classify it as a “Proxy & VPN” without affecting the other DoH services that enforce adult-content filtering.
For Example:- From:
https://doh.cleanbrowsing.org/doh/security-filter/ - To:
https://security-filter-doh.cleanbrowsing.org/doh/security-filter/
OR
https://security-filter-doh.cleanbrowsing.org/
While you are at it, “security-filter-dns.cleanbrowsing.org” should be classified as a “Proxy & VPN” as well.
The other DNS over TLS services are also lacking categorization, but at least they are on separate domains and block adult-content:
https://cleanbrowsing.org/guides/dnsovertls