Files are locally hosted on download.dnscrypt.net. A cronjob updates the files every 3 hours, source is https://download.dnscrypt.info
download.dnscrypt.net has IPv4 and IPv6, DNSSEC, HTTPS
The ".home" TLD was proposed at one point, and while it's probably not going to actually ever get delegated it's not best practice to just start using your own TLD. The .home.arpa domain has been specifically set aside for use in home networks (RFC 8375) and is probably the better example to put here.
The issue with benchmarking DoH servers is that some responses can
be directly served by a CDN, while others require a round trip to
the origin that can be significantly more expensive.
Random padding was an attempt at mitigating this. Unfortunately,
some servers (Tencent) ignore the padding. We end up with a query
for the root zone served by the Tencent CDN very quickly, but
anything else is orders of magnitude slower.
So, measure a query within the reserved "test." zone instead.
Caching resolvers should either know that "test." is undelegated,
or have it in their negative cache already, so this is unlikely to
trigger an actual query to authoritative servers.
Take it as an opportunity to check that we don't get anything but
a NXDOMAIN response for nonexistent domains.
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.
* 'master' of github.com:jedisct1/dnscrypt-proxy:
Fallback to cache_file avoiding termination for not offline_mode (#1332)
Minor update to GH Actions workflow (#1341)
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.
Frank Denis
mibere
petercooperjr
Ian Bashford
lifenjoiner
Alison Winters
Frank Denis
hugepants
yofiji
Krish De Souza
William Elwood
Frank Denis
s-s
Kevin O'Sullivan