Dimitri Herzog

Thank you for your suggestions. I saw some articles regarding "DNS-over-QUIC", and as far as I know, there only one public DNS server available at the moment (adguard). Do you...

Client can have multiple names, in this case only the first should be used

Similar to #7 . There are some challenges: - what should happen if new configuration is not valid? - what should happen if new configuration is valid but reload fails...

It validates if YAML has correct syntax and if some custom types (like upstreams) have correct format. It would probably also make sense only reload a part of configuration attributes...

I think, it is very frustrating for the user if a simple "docker run" fails due to missing config file. It would be better if blocky would start with minimal...

It would be the "safest" way. But when system dns resolver is crappy or misconfigured, it would still not work.

I think, this is something which should be created and maintained in a separate repository. There are already packages for several linux distributions and kubernetes, maintained by other people, see...

As mentioned by @ThinkChaos "docs/config.yml" is the reference config file with all parameters (https://0xerr0r.github.io/blocky/configuration/) I think you want a minimal configuration file, just to be able to run blocky, right?...

Blocky uses currently only the DNS question name and the DNS type as a key for caching. I think the correct behaviour would be to cache the entry, but to...

Current implementation was designed to combine privacy with performance: * blocky peeks random (weighted, upstream resolvers with errors become "penalty") 2 resolvers and returns answer from the fastest * If...