u/berahi

Try opening an issue in the serverless-dns repo, supporting DDR should be in scope for them

Encrypted DNS is generally annoying for system admins dealing with networks allowing unmanaged devices because they require extra effort to enforce blocks and log traffic. DoT is an acceptable compromise because, as long as there's no UI to change from the standard port 853, it's trivial for the firewall to just block it entirely. ChromeOS is mostly intended for managed devices, so it's less attractive to implement if IT will just block it.

In case IT wants encrypted DNS to their own server, DoH doesn't require a dedicated setup if they already have a webpage. DoH will also still work when users are away on networks that block DoT entirely (which also makes it more attractive for browser makers), and adding an identifier with a unique path is much easier than having the resolver and server accept an arbitrary subdomain like in DoT. DoT's selling point was that it's simple to do opportunistic encryption (just have the device attempt DoT and accept any cert), until DDR provides a better, more organized solution.

The initial native DoH3 support in Android was hardcoded to only upgrade on two hardcoded domain names, Cloudflare's and Google's own, possibly because DDR was still in draft, and likely also because Private DNS becomes much more popular for ad-blocking, cutting directly to Google's income.

Try the flags from https://github.com/eyalm2000/loophole#enable-the-flags by OP, the previous flags don't work on the Android 16 emulator, while OP flags work

https://developers.cloudflare.com/workers-ai/platform/data-usage/

For third-party providers https://developers.cloudflare.com/ai/models/?providers=third-party, each model will have a link to the provider's policy

OP use case is when they're in regular guest Wi-Fi network, there it's trivial to block DoT because they all share the same port, but it's not feasible to block all DoH because, without deep inspection, they're indistinguishable from regular TLS traffic from websites and apps.

OC boasts about managed Wi-Fi networks, like in offices & schools with provisioned devices, so traffic can be inspected regardless of DoT and DoH.

Private DNS through DoT and DoT merely hide your DNS queries; most of the time the destination domain is still visible anyway unless the site, browser and/or app use ECH. A VPN will hide the traffic entirely, though a firewall can still recognize common VPN protocols and attempt to block them.

For Cloudflare to be an ECH proxy, they would have to handle all TLS traffic. Which they already do for sites using their service, but for arbitrary service, just use their Warp app.

The free tier gives you 100k queries each day if they're served by scripts like in this case.

ECH only works if the website/app server supports it. Android apps targeting Android 17 will use the native Android ECH by default, but browser behavior on whether they decide to use their internal ECH (doesn't rely on Android version) differs, some only enable ECH if their own DoH setting is enabled.

You'll need to have a worker that forwards DoH queries, such as https://github.com/tina-hello/doh-cf-workers. Fork the project in your GitHub account, edit your index.js doh variable to point to your NextDNS DoH address (like https://dns.nextdns.io/1234), then open https://dash.cloudflare.com/, select Workers and Pages, continue with GitHub, and pick the forked repo. After deployment is finished, pick the domains tab of that workers, select add domain and use one of your domain. Enter a subdomain.

Once you set up the workers and have, say, dohforward.example.com, first test that it runs correctly either by setting it manually in your browser DoH settings (use https://dohforward.example.com/dns-query in the custom DoH provider entry) or by calling it with https://github.com/ameshkov/dnslookup (open a terminal and try dnslookup google.com https://dohforward.example.com/dns-query). You can also use curl, like curl --doh-url https://dohforward.example.com/dns-query google.com -I (if you're on Windows PowerShell, use curl.exe, the PowerShell curl alias has different syntax)

Now open https://dash.cloudflare.com/ again, this time, select your domain, go to DNS Records, add Record, change Type to SVCB, for name use _dns.[yoursubdomain].[yourdomain], eg, _dns.dohforward.example.com, set Priority to 1, the target is [yoursubdomain].[yourdomain], eg dohforward.example.com, the value is alpn="h2,h3" dohpath="/dns-query{?dns}". After you save it, verify that you have a working DDR entry with dig +short SVCB _dns.[yoursubdomain].[yourdomain]. If you're on Windows without WSL, install dig with winget install ISC.Bind and open a new terminal afterwards.

The flags to set on your phone are mentioned in /u/Drtechsavy comment https://www.reddit.com/r/nextdns/comments/1xe03ic/you_can_actually_do_systemwide_dnsoverhttps_with/19rksbymod075/, you can turn Developer Options back off after setting the flags if your e-commerce/banking apps hate it, the flags will still be set.

And then you just set your Private DNS to [yoursubdomain].[yourdomain], you should see in NextDNS dashboard traffic coming from Cloudflare since they forward it for you.

Nah, for that you'll need a VPN. It's also rather pointless to just rely on a VPN if you still have an account linked to your identity and browsing activity. For sane people, ad-blocking (through DNS and browser extensions) is already enough.

There's not much "syntax", you just write the domain on the top field, and either IP or domain on the bottom field. When you query the domain, NextDNS will answer with the replacement.

Note that due to HTTPS, HSTS, certificate pinning etc, it's unlikely to work with public sites (eg, you won't be able to redirect YouTube to one of the myriad alternatives) because the destination won't have a valid certificate. As the placeholder text imply, it's intended for home LAN

Try using just OISD or Hagezi (just one of them), then if after restarting the device and clearing the cache it works, slowly add the lists you were using before (if you're really sure you need them) while checking if the problem returns

It's not MITM because NextDNS doesn't break HTTPS; your browser won't load the page if that's the case. NextDNS can't read or modify anything; it only knows the destination domain (which they already do anyway since you're using their DNS)

In this example 4.3.2.1 is a proxy server run by NextDNS. Unlike regular proxy server, it only forward specific domains to prevent abuse, the domain is known because HTTPS packets carry destination domain through SNI in plaintext. So, the proxy server knows what domain you want to visit and just duly forward the traffic (without reading inside the packet, because it's encrypted by HTTPS)

The resolved IPs belongs to NextDNS' own proxy servers that forward your traffic, so from the visited site PoV your IP is the proxy server's. This is called smart DNS by some VPN companies.

With all the political favor from pilgrimage quota they could be the world's greatest peacemaker that no one dared to touch, but instead even their allies are laughing behind their back.

There's a benchmark in https://www.makeuseof.com/cloudflare-quad9-nextdns-adguard-malicious-domain-test/

The methodology is listed so you can replicate it yourself with other malware list.

Note that most browsers have built-in malware domain blocking too, and if you can install uBlock Origin, that will also support even more filter.

Gparted usually will just refuse to resize NTFS outright if the state isn't clean (make sure to choose restart, not shutting down/hibernating Windows then booting gparted)

That said, unless you're really starved for space, it's not really worth the time just to recover 530 MB

Above 12 are fine if they have Mar-a-Lago face.

Imagine not having to worry about anything financially, then choose to have such a face.

If you can still see something on the screen, clean install it, see https://rtech.support/installations/install-11/, if you need to recover the files first, see https://rtech.support/live-sessions/linux-live-session/, but due to Windows opt-out encryption that might be useless unless you have already backed up the key

MT-55 is a bridge layer, unless by engineering tank you meant another type of tank, but other forms won't have the lengthy parts in the photo

The two long parts are of the bridge laid by Syrian https://en.wikipedia.org/wiki/MT-55, either to cross natural formation or ditches made by the defenders to stall the assault. So after the bridge was laid and a tank was attempting to cross over, the bridge tumbled either from attack or just collapsing soil.

Sorting is simply not supported at all in GitHub code search now.

Just open the GitHub webpage, enter a string in the search box then switch the filter to code

nextstone7/dnsfilters in GitHub, only 64 entries and last updated in May. It doesn't seem that anyone is interested in maintaining these kind of list.