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>
* 'master' of github.com:jedisct1/dnscrypt-proxy:
Create shiftleft-analysis.yml
Create codeql-analysis.yml
Revert "Fix unit tests on Win10 (attempts 1 and 2)"
sources_test: set bit 16 of the port instead of adding zeros (#1358)
Fix unit tests on Win10 (attempt 2)
Thanks to @lifenjoiner for testing! Windows 10 behaves even more unexpectedly.
After it parses the "ip:port" string as a hostname, it attempts to upgrade from
http to https by appending `:443` and parsing that new URL again.
This seems to happen concurrently with the doomed DNS lookup and we see the
error from whichever fails first.
Untested attempt to fix unit tests that fail on Windows 10 build 1909.
From the test output mentioned in #1332, it looks like this version of Windows
doesn't report an "invalid port" error when asked to connect to an invalid port,
instead it treats the port as part of the host name and attempts a DNS lookup.
Naturally, this fails because the colon character is not valid in a host name.
This change simply makes this inexplicable error an expected result since the
outcome is the same and we can't fix Windows.
