UI: Identify upstream blocklist rules that blocked a given query

[codebymikey]

Currently if you end up enabling multiple DNS filters in the app, it's a bit hard to determine why a particular domain or IP was blocked.

It currently just shows something a bit vague like:

blocked 0 min ago by 1-4apwiasjaebbcaafabqaaaiaiaqaa.max.rethinkdns.com:853

We can implement UI element or button that lets them search for the rule using an API such as: https://max.rethinkdns.com/dntolist?dn=secureir.ebaystatic.com to display the relevant blocklist in an alert or lazy loaded text element.

Having this option will make it a lot easier for users to choose how to loosen their rules (e.g. removing the specific blocklist if it's too aggressive, or add overrides if it's just a specific rule)

[ignoramous]

We can implement UI element or button that lets them search for the rule using an API such as: https://max.rethinkdns.com/dntolist?dn=secureir.ebaystatic.com to display the relevant blocklist in an alert or lazy loaded text element.

This already happens if you use On-device blocklists.

If you want the same behaviour when using Max, then switch to DoH (but you'll have to do so manually, as the built-in behaviour switches Max to DoT, with no way to change it).

Also, it'd be very expensive to lookup blocklists for a given domain over the network for every DNS query.

[codebymikey]

This already happens if you use On-device blocklists.

Oh okay, thanks for the pointer! Wasn't aware of that distinction in behaviour, and seems like a good enough workaround to debug the RDNS blocklists locally.

Also, it'd be very expensive to lookup blocklists for a given domain over the network for every DNS query.

That's why I initially wanted to implement it as a button/link that power users could manually click upon investigating a specific blocked DNS query in the logs - which in turn does the lookup to compare against their local active block list IDs.

But given that the feature already somewhat exists in a different mode, I'm curious why "RDNS plus" mode doesn't currently support something similar (assuming it's also running over HTTPS), and is there a performance difference in both modes?

I'm guessing even if there's some kind of limitation with the RDNS implementation stopping it from fetching the same block list IDs, the manual block list lookup functionality I propose is not a pull request you'd be willing to add to the project?

[ignoramous]

But given that the feature already somewhat exists in a different mode, I'm curious why "RDNS plus" mode doesn't currently support something similar (assuming it's also running over HTTPS), and is there a performance difference in both modes?

Max will support this if it is setup as DoH (the app right now sets up Max as DoT with no way for users to change that). Sky doesn't because it is running in "restricted" mode (as the costs went out-of-control: $8000+ per mo) and does bare minimum. We intend to get back to working on the resolvers (rewriting serverless-dns to bring Sky out of this "restricted" mode, for example) once we get #946 out of the door.

That's why I initially wanted to implement it as a button/link that power users could manually click ... a pull request you'd be willing to add to the project?

Yes, makes sense as an interim solution.