MacOS (and probably Windows and other systems) tries to fetch a URL
before marking a network interface as available.
During this time, applications cannot use the interface at all, not
even bind their address.
When DNS queries are sent to dnscrypt-proxy, this causes the system
to wait for a response that can't come from the network, since we
hit a dead lock here.
The only option is to return hard-coded responses directly until
te interface is available.
The same captive portal configuration file can also serve a different
purpose.
Once the network is available, captive portal detection may not
work as expected if the answer is cached for too long. In fact, it
probably can't work at all since routers can't hijack DNS queries.
Once thing we can do is redirect the list of names used for captive
portal detection to the fallback resolvers. This may allow detection
to work as expected while still using a secure channel for all
other queries.
* ConfigFile change to allowlist and blocklist
* revised names and warnings
* consistent file naming in kebab case, and generic use of blocklist and allowlist in cmoments for clarity
* update ci files
* further allow/blocklist updates
* improve language in comments
Co-authored-by: Ian Bashford <ianbashford@gmail.com>
* Add option to go direct for failed certificate retrieval via relay
* add direct_cert_fallback to example config file
Co-authored-by: yofiji <you@example.com>
* ConfigFile change to allowlist and blocklist
* revised names and warnings
* consistent file naming in kebab case, and generic use of blocklist and allowlist in cmoments for clarity
* update ci files
Co-authored-by: Ian Bashford <ianbashford@gmail.com>
* Disable Sysctl list, Introduce GameIndustry.eu
* The host file from http://sysctl.org/cameleon/ is no longer updated, therefore it should be disabled.
* Introduce a new rule maintained by GameIndustry.eu. I only pick the rule sets that NextDNS provides to its customers of their choice, as these rule sets are generally seen as stable and reliable.
However I don't play game so much, there is no way to perform a fully test on my side. There is no FP detected during the couple of days while I using this rule set. And I've gone through the entire contents of the host file in roughly, the entries all seem reasonable to me.
* Disable rule set from AdAway by default
~~It doesn't take long for jedisct1 add baidu.com, and 163.com into whitelist after I introduced this rule into the configuration file, so I guess that the AdAway rule set must have presented a lot of false positives.~~
~~However, these Chinese IT companies are notorious for their extensive user-tracking tactics. Whitelist their top domain may not a good idea.~~
~~My suggestion is to simply disable the ruleset present FP, and let software like ABP or AdGuard do the most elaborate work. - Blocking on the DNS level has its limitations.~~
Frank Denis
dependabot-preview[bot]
Alison Winters
Frank Denis
Ian Bashford
hugepants
yofiji
Krish De Souza
IceCodeNew
Prabhu Subramanian
Frank Denis