DNS resolving frequently failing

[syphernl]

Describe the bug
I noticed that the DNS resolving using dnsmasq is frequently failing. Our monitoring shows that at least once a day the DNS isn't working for 2 - 15 minutes after which it self-recovers.
The logs show the following frequently coming by:

dnsmasq: reducing DNS packet size for nameserver 1.1.1.1 to 1280

Configured nameservers:

SUBSPACE_NAMESERVERS=9.9.9.9,1.1.1.1,8.8.8.8

It always happens on the 1.1.1.1 nameserver, not on the other specific one's.

Perhaps we should the following to the dnsmasq config to mitigate that:

edns-packet-max=1280

I'm on "v.1.5.0" (which is actually v1.3 due to a bug in the Docker build process).

[syphernl]

Note that the config (SUBSPACE_NAMESERVERS) is currently not being used and therefore defaults to SUBSPACE_NAMESERVER=1.1.1.1.
It has changed in 1.4.0, but due to packaging issues I'm still on 1.3.x

[kmskrishna]

For me, DNS is failing for internal domains as well that are listed in /etc/hosts. So don't know what the problem is.

[unquietwiki]

@syphernl I was just looking up DNS issues, since I did a fresh installation of this today (Aug 6), and noticed that SUBSPACE_NAMESERVERS had been ignored. Are we able to safely set SUBSPACE_NAMESERVER without wiping out our existing installs, or is that going to be working again in a new version?

Edit: I didn't realize since /data was persistent, the user & SAML configs were surviving version changes (easy mistake). But also noticed #193 mention using amd64-v1.5.0 instead of latest corrects the DNS behavior.

[syphernl]

A few days ago I've switched it to the tag amd64-v1.5.0 and haven't had any monitoring warnings anymore that the DNS resolving is failing. So ISTM this indeed fixes it.
Will keep an eye on this for a few more days but thus far it looks good!

[syphernl]

According to our monitoring the DNS is still failing. Not as often as before, but still at least once a day.