Merge request

[demarcush]

Is it possible to merge these two domain-list-community categories into their respective equivalents in this project?

category-ir -> ir category-porn -> nsfw

[Chocolate4U]

Hi, category-ir is completely merged in ir category and there is no need for it if using ir category.

nsfw is also more comprehensive than category-porn and there is no need for category-porn if using nsfw category.

Both category-ir and category-porn are only there for compatibility with domain-list-community rules, and are not needed if using their similar category from this repo.

[demarcush]

I wasn't sure about the category-ir, but now I see it.

As for category-porn, there are domains in category-porn that do not exist in nsfw. I personally believe domain-list-community has become a huge mess these days (false-positives, https://github.com/v2fly/domain-list-community/issues/1657 and also their MIT license), so I'm just looking for the most comprehensive list with the least of false-positives. And if you say there's no need for merging it or using both category-porn and nsfw in a config file, I'll trust you.

Regards.

[Chocolate4U]

Yes, that's why I didn't use their domain list for ads either. Many false-positives and poor maintenance. Also, I recommend to use Cloudflare's family DNS (1.1.1.3) for blocking adult websites whenever possible. They tend to have a more complete database, and it will also reduce over head on sing-box.

[demarcush]

I recommend to use Cloudflare's family DNS (1.1.1.3) for blocking adult websites whenever possible.

Problem is when using Cloudflare as a remote DNS resolver (with the format https://1.1.1.1/dns-query) in sing-box, I often encounter the connection exceeded or no IP SANs with many of the gathered nodes (and I suspect the problem is server-side, as still some servers are able to resolve user's queries this way). Using their other addresses (https://dns.cloudflare.com/dns-query, https://cloudflare-dns.com/dns-query and https://one.one.one.one/dns-query) did not help either.

I have yet to find a good DNS configuration for sing-box, yet the current one I've deployed seems to have no problems: https://github.com/demarcush/breakfree/blob/991ee3645b7ceaf3fe38aee5ebf5a7567ab9806c/templates/template-ir.json#L2-L39

Your feedback is much appreciated.

[Chocolate4U]

A few things come to mind after seeing your config:

1. In DNS rule section, it's better to use domain_suffix to handle .ir TLD domains. Although I have included .ir in geosite-ir, using domain_suffix is a bit faster.

   "rules": [
   {
   "domain_suffix": [
     ".ir"
   ],
   "rule_set": [
     "geosite-private",
     "geosite-ir"
   ],
   "server": "direct"
   },
   {
   "outbound": "any",
   "server": "direct"
   }
   ]

2. In DNS Server section, try to simplify it like this, and test if it works with those servers:

   "servers": [
   {
   "address": "https://8.8.8.8/dns-query",
   "address_resolver": "direct",
   "tag": "remote",
   "detour": "default"
   },
   {
   "address": "local", //or 8.8.8.8
   "tag": "direct",
   "detour": "direct"
   }
   ]

   In this configuration, proxy server's address gets resolved using local DNS server of the client. Which is specified in this rule:

   {
   "outbound": "any",
   "server": "direct"
   }

   So no loop condition will occur. After that, all DNS queries (except domestic addresses, which get resolved using local) will go through default proxy server and get resolved using the specified DOH address. I use this configuration myself, and it works fine, but I'm not sure if it works for other servers with different settings. You can test it and verify. Nice job on the configurations BTW.

[demarcush]

In DNS rule section, it's better to use domain_suffix to handle .ir TLD domains. Although I have included .ir in geosite-ir, using domain_suffix is a bit faster.

Agreed. Come to think of it, if I put it higher than geosite-ir rule, it'll pass .ir domains faster than looking in geosite-ir.

In DNS Server section, try to simplify it like this, and test if it works with those servers:

I believe that's an oversimplification. You see, a good portion of the nodes are addressed by domains which sometimes are getting actively probed and blocked, but because they are behind some giant CDN the collateral damage for blocking the actual IPs are high. Having a DoH (that is still accessible) as a intermediary step between the local (plaintext DNS) and remote, to resolve internal domains needed for bootstrapping, is something I'm willing to hold as long as there's still a way for encrypted DNS connections inside the country.

Oh, and the problem with Cloudflare and Quad9 DoH servers was rate limitation. 🤡
Google is more loose.

Nice job on the configurations BTW.

Thank you, sir.

[Chocolate4U]

Ok, in the case that you want to also resolve proxy addresses through DoH, I don't think there's an easy solution for this (or any solution FWIW). I suspect eventually every single DoH endpoint will get blocked inside the country, even the unknown ones. There should be an entry point for proxy servers, either an IP address or a Domain address that's not blocked inside the country. In this case, the entry point is the DoH address, but I don't think trying to get the IP address from a blocked domain address by leveraging DoH, is sustainable in the long run, specially in the current level of censorship.

[demarcush]

Let's just force them to bring on everything they've got.