Feature request: option to use custom DNS blocklists; some related questions

NymVPN Discussions
1

There are the following statements in the blog post about the NymVPN ad blocker:

Brave’s block list is one of the most comprehensive, well researched, and consistently maintained in the industry. It’s updated continuously as new ad networks, tracker domains, and malware hosts emerge. So it’s a huge honor for Nym and an opportunity for NymVPN users to have it supercharge their privacy. Huge thanks to the Brave team for helping us make it happen!

…

DNS queries with NymVPN’s ad blocker are further protected by DoH & DoT encryption protocols so all this can be done privately. The ad blocker’s DNS queries are wrapped in either TLS (DoT) or HTTPS (DoH) encryption between the NymVPN app and the Brave list.

First of all, there should be more transparency about which blocklists are used. The article states that NymVPN uses “Brave’s blocklist,” which says very little. Curious about what the actual blocklist is, I discovered in the source code that it uses EasyList and HaGeZi Light. I’m not entirely sure how that’s unique to Brave. I am not aware of Brave using HaGeZi Light, and although I know that Brave has considered optimising EasyList, as described in this blog post, it’s only about a thousand entries smaller than the official blocklist, which is almost certainly because the blocklist version hosted on the instance NymVPN uses is older than the one hosted on the EasyList GitHub.

Regarding DoH and DoT, the wording is very confusing. It’s so unclear how that’s implemented that I’d like to see a proper technical explanation.

Finally, my request: since it seems like NymVPN uses a full-blown Brave adblock implementation (and this is one of the best cases of its use, although I’d even say it’s somewhat overkill, but that’s not important), why not add an option to use custom blocklists? One might prefer using OISD, HaGeZi Pro/Pro++/Native Tracker, or even BadBlock. Also, adding an option to add custom rules (such as a blacklist and a whitelist with support for wildcards) will provide much more freedom of customisation, as well as the ability to whitelist domains whose blocking results in breakage.

2

Thanks for patiently waiting. We collected some responses from our devs in the meantime:

First of all, there should be more transparency about which blocklists are used. The article states that NymVPN uses “Brave’s blocklist,” which says very little.
Curious about what the actual blocklist is, I discovered in the source code that it uses EasyList and HaGeZi Light. I’m not entirely sure how that’s unique to Brave. I am not aware of Brave using HaGeZi Light, and although > I know that Brave has considered optimising EasyList, as described in this blog post, it’s only about a thousand entries smaller than the official blocklist, which is almost certainly because the blocklist version hosted on the instance NymVPN uses is older than the one hosted on the EasyList GitHub.

NymVPN utilizes Brave’s adblock engine with blocking lists from HaGeZi and EasyList for all platforms except iOS. On iOS we use custom solution due to memory constraints. Blocking lists suitable for DNS-based blocking are being used.

The same blocking lists shipped with the app are not the latest. Nym VPN periodically refreshes blocking lists from our CDN which mirrors GitHub.

We may revise the list of blocking rules in the future.

Regarding DoH and DoT, the wording is very confusing. It’s so unclear how that’s implemented that I’d like to see a proper technical explanation.

On-device stub resolver is used for filtering and forwarding DNS requests on all operating systems except Android. While VPN is running, all DNS requests issued by apps pass through Nym’s stub resolver.

DNS requests that pass adblock filtering are forwarded to remote DNS server using secure DNS (DoH or DoT) inside VPN tunnel. Quad9 and Cloudflare services are used by default.
DNS requests rejected by adblock filtering are resolved to localhost. No forwarding to remote DNS server happens such case.

When using custom DNS, default DNS services are replaced with custom DNS provided by user. At the moment custom DNS only supports plain TCP/UDP 53 DNS servers. That will be improved in the future.

Round-robin strategy is used for DNS server selection. In other words, stub resolver sticks to the first working pair of protocol/host for as long as it works.

On Android, in-tunnel filtering at packet level happens over plain DNS requests. Adblock will not work for DoH/DoT if Private DNS is configured on device.

Finally, my request: since it seems like NymVPN uses a full-blown Brave adblock implementation (and this is one of the base cases of its use, although I’d even say it’s somewhat overkill, but that’s not important), why not add an option to use custom blocklists? One might prefer using OISD, HaGeZi Pro/Pro++/Native Tracker, or even BadBlock. Also, adding an option to add custom rules (such as a blacklist and a whitelist with support for wildcards) will provide much more freedom of customisation, as well as the ability to whitelist domains whose blocking results in breakage.

Regarding block lists customization, it’s a good suggestion and we’ll look into introducing that in the future. Note that blocking lists are being updated periodically on our CDN.

1 Like
3

Thank you and the technical team very much for the reply, I’m happy with it.

Just a couple of points I want to clarify:

NymVPN utilizes Brave’s adblock engine with blocking lists from HaGeZi and EasyList for all platforms except iOS.

The issue was that the blog post states that Brave’s block list, not the adblock engine, is used, which led to confusion.

DNS requests that pass adblock filtering are forwarded to a remote DNS server using secure DNS (DoH or DoT) inside the VPN tunnel.

Great, that is how I understood it initially. The issue was the wording: “The ad blocker’s DNS queries are wrapped in either TLS (DoT) or HTTPS (DoH) encryption between the NymVPN app and the Brave list.” It talks about encryption between the app and the list, which makes little sense in itself and doesn’t really indicate encryption between the app and the DNS server.

I know this is pedantic, but I just wanted to make clear the reason I clarified these things. I suppose all of this was mostly the fault of PR people managing the blog misinterpreting technical stuff, and I’d advise them to be more thorough next time, because failure to properly explain your product’s features may lead to confusion, a lack of confidence, and potentially lost customers.

Sorry for being a douche :slight_smile:

1 Like