So basically, if you add a "Private DNS" in Android, this will always use DNS-over-TLS as the protocol which is easily blocked by a network admin (e.g. in a public WiFi or at work or school). So if you use for example Adguard DNS to block ads, you'll often have to disable it in a public WiFi in order to connect to the Internet and then remember to enable it again afterwards. Those of you who use the Private DNS feature with a privacy-respecting or ad-blocking provider like Adguard, NextDNS, ControlD, Mullvad, Quad9 and so on, you'll definitely have seen a notification like "Private DNS cannot be accessed" when connecting to a public WiFi.

However, Android does have the ability to connect via DNS-over-HTTPS (not easily blockable) but they have hardcoded Cloudflare and Google as the only permitted resolvers to use DNS-over-HTTPS. [inaccurate claims about this from a privacy content creator have been removed]

I am wondering if GrapheneOS would consider expanding DNS-over-HTTPS support for all DNS providers? Or add a toggle whether the user wants to use DoH or DoT? It seems that the code is already there and they have simply hardcoded the allowed servers for DoH, so to me (a non-programmer) it seems like a relatively small change to make.

    DNS seems one of the clean and effective ways to block a great deal of malicious known domains, ads and trackers, systemwide, without installing third party workarounds. Having only DoT available, susceptible to being blocked is a bit lacking here. I think this is a mechanism and field GOS could also improve on as they do in other areas, instead of waiting for AOSP. I was reading an article the other day about how advertisers use their network to reveal people's location without apps and devs even knowing it was possible. Remember that the next time someone tries to guilt you into enabling ads to support creators.

    edit: here https://archive.is/ZowJM

    GrapheneOS changed the title to Expanding DNS-over-HTTPS compatibility .

    Viewpoint0232 There's no basis for these claims you're making about the linked issue report which led to you making this post. The person making those claims consistently spreads misinformation including about GrapheneOS and has been heavily involved in harassment towards our team. You should find better sources of information. We blame them for this rather than you for being misled but we don't want this misinformation spread here. The issue was closed as obsolete because Android already has experimental support for auto-detecting DNS-over-HTTPS and they aren't going to be expanding the list or adding a way to force it rather than auto-detecting support for it.

    missing-root Both issues have been closed since it doesn't make sense anymore due to the auto-detection support already existing in AOSP behind feature flags. Enabling a bunch of experimental code for this early would be very risky especially without having resources to dedicate to reviewing it and dealing with any fallout. We don't know the timeline for it becoming a stable feature or what the consequences might be of trying to enable it early since we have no access to their internal bug tracker.

        "Attacks on GrapheneOS", again...

        Can you please not always call everything which may be partly wrong, or misunderstood, or whatever, an "attack on GrapheneOS"? @GrapheneOS

          missing-root The person they're getting this nonsense from is part of the Techlore organization and is one of the main people involved in starting and perpetuating the attacks on GrapheneOS.

            GrapheneOS

            We could enable support for automatically detecting DoH support early but it would be risky. We're planning on following along with Android's schedule for enabling these and nearly all other features.

            Do you know what the schedule is for upstream? Like did they publish any estimated date when it would be enabled in Android?

                Viewpoint0232 We don't know the timeline, but they implemented it and are regularly improving it. We don't know how many issues remain before it can be enabled. It's entirely possible for us to enable it early but that could cause major issues for people using Private DNS.