* 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
Some ODoH relays return a 200 status code even when the upstream
server returns something different. This is an issue after a key
update, where a 401 code is expected.
Handle empty responses with a 200 status code as a response with
a 401 code as a workaround until these relays are fixed.
* 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>
Blocking until all servers have been checked is safe, but significantly
increases startup times.
OTOH, we shouldn't accept connections unless we have at least one live
server.
So, a better approach may be to add the ability for `serversInfo.refresh()`
to write to a channel after a live server has been found, and block on
that channel in the main thread before accepting client connections.
Ian Bashford
Frank Denis
Frank Denis
Christopher Wood
yofiji
s-s
Kiril Angov