Dnscrypt-proxy: any solution/workaround if yesterday's invalid-signature error will repeat again?

[admzzz]

wonna suggest additional parameter in dnscrypt-proxy.toml - "use previous public-resolvers.md in emergency case", which had to be set to NO with explanation (in capital letters too ;-) ), that setting this to YES would lead into an unbreakable vicious circle.

[Gedsh]

Maybe better, in my opinion, slightly change “public-resolvers.md” download sequence. First – download new file as temporal, then check signature. If download and signature checks pass – replace old file with new one, otherwise leave old and print warning in log. This can prevent non-working dns-crypt condition in case of wrong file “public-resolvers.md”.

[welwood08]

Maybe better, in my opinion, slightly change “public-resolvers.md” download sequence. First – download new file as temporal, then check signature. If download and signature checks pass – replace old file with new one, otherwise leave old and print warning in log. This can prevent non-working dns-crypt condition in case of wrong file “public-resolvers.md”.

I was analysing how the source lists are downloaded to debug a failure in my setup, and found my expectations were wrong in a way that could be related to Gedsh's comment:

• At startup, if the cached copy is expired or non-existant then both files are downloaded to memory and the signature is verified before writing anything to disk. Since this already does what you suggest above, I was intrigued as to how it could be failing.
• Periodically the service checks for updates and when these updates are downloaded they're immediately written to disk without signature verification. This isn't an obvious problem because the running configuration is unaffected, but it does mean that at next startup the cached copy could fail signature verification and there be no working fallback.

I'm not sure what the reasoning is to have this different behaviour between startup and long-running. I had incorrectly assumed that updates to the source lists during runtime would be picked up within the refresh delay and the running configuration appropriately adjusted. Instead, it seems the occasional checks for updated source lists is just so they're on disk for the next time the service is started, which on a router could be months away.

@jedisct1 Is there a security or other important reason it's done this way instead of adjusting the running configuration using the latest available source lists? I'm teaching myself Go and this issue seems like something I could exercise myself on, but I'd like to get an idea of how much room for change there is in the way the periodic updates are done before I dig in.

[jedisct1]

The lists are periodically kept fresh while everything is working (the network is up and DNS can be used), so that a new download will not be required if the device is restarted within the next few days.

Adjusting the running configuration would be quite complicated. Resolvers being used can disappear, be renamed, have different properties, switch to a different protocol, move from one list to another and match different filters. That doesn't sound trivial to implement safely, especially in a multithreaded environment.

But the signatures could indeed be checked before the files are written to disk.