* allow ptr queries for cloaked domains
* multi ips per PTR returned + cleanup
* some string tidy up
* enable config file switch
* add cloaked ptr test
* enable cloak ptrs in test scenario
* fix reverse ipv6 ptr lookup
* added ipv6 cloaked ptr test
* 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
* impose maximum delay and document
* live update of servers
* update for source prefixes
* fixup test
* stop registerServers being called twice at startup
* prevent double registration at startup
* tidy function signature for loadSource
Co-authored-by: Ian Bashford <ianbashford@gmail.com>
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.
* 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>