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.
All errors returned from NetProbe are managed as fatal later.
Decide, connection issues are not fatal but bad configuration is.
Without this configuration errors are silently ignored here.
Windows doesn't seem to like this address.
Also default to the fallback resolver IP if there is one and
no netprobe_address option in the configuration file.
Fix netprobe_timeout = -1 by the way
Frank Denis
Markus Linnala