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.
* 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
* message about deprecation of -w
Co-authored-by: Ian Bashford <ianbashford@gmail.com>
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.
