I've had this problem before: https://bbs.archlinux.org/viewtopic.php … 3#p1572343
Actually, I have this problem after almost every "pacman -Syu"
As usual, dnscrypt and dnsmasq are configured correctly. In fact, I've gotten into the habit of making their configuration files immutable, but it doesn't seem to help.
dnscrypt's "/usr/bin/hostip" can resolve addresses and there's nothing wrong with the socket or the service according to systemctl status; neither does it report any trouble with dnsmasq.
I found mysterious new configuration options in /etc/nsswitch.conf again, but changing them had no effect (specifically, I removed "resolve [ !UNAVAIL=return]").
I am able to ping ip addresses.
Everything is in place, yet DNS does not resolve, again. Each time I've had this problem it seems like I found a different solution and that the previous one no longer worked.
Typical things I try: different resolvers for dnscrypt (seems like a lot don't function properly), reconfigure dnsmasq and dnscrypt according to the wiki (which they already are), switch to systemd-resolved then back to dnscrypt+dnsmasq (which makes no sense), reboot dozens of times (which makes less sense), reinstall bind-tools or libc6 (by downloading the packages onto a disk in another pc; worked once each for different cases of the same problem) All of which I am in the process of doing, again, right now.
If anyone has some insight I'd greatly appreciate it.
Last edited by quequotion (2017-01-19 17:01:28)
After a couple of days poking around in the dark, making random and arbitrary changes to my setup and then going back to the wiki's recommendations, it's working again. I have absolutely no idea why it works now or why it failed in the first place.
Some things that happened:
I switched to systemd-resolved for a while, which overrides user configured DNS (in .network files, resolvconf.conf, resolv.conf.head, etc) with configuration it pulls off my router through DHCP. It should use dns in the order it finds them (local dnscrypt+dnsmasq, then two servers from the router), but in practice it seems to completely disregards local dns and uses only the configuration pulled from the router. Incendentally, systemd-resolvd be prevented from pulling the router's DNS configuration by setting "DHCP=no" in .network files.
As posted above, my configuration of dnsmasq and dnscrypt was faultless and both systemd services logged neither errors nor malfucntion. This did not change until, attempting to integrate systemd-resolved and dnscrypt+dnsmasq once again, I changed what had always been "DHCP=ipv4" in my .network file to "DHCP=no". For the first time since it stopped functioning, dnscrypt began to report an error: unable to retrieve certificates. It reported the same error for every server I tried. So I tried "DHCP=no" with systemd-resolved disabled next, and the error persisted. Then I changed it back to "DHCP=ipv4" as it had always been before and magically everything works again.
Let me reiterate:
The configuration now is precisely what it was at the time it stopped functioning and precisely as it was when it functioned before that. The only substantial things I have done are to enable and then disable systemd-resolved, edit a .network file and then reverse that edit, and try out a half dozen or so dnscrypt servers--going back to the originally configured one in the end.
For my next expermient, however, I'm going to duplicate my configuration as a native dnscrypt-proxy.conf config file because I'm tired of tinkering with systemd service files and overrides (which will involve making at least two systemd service overrides...)
Last edited by quequotion (2017-01-24 06:59:30)
I'm begining to suspect the problem is in dnsmasq.
After reconfiguring dnscrypt-proxy to be the default (127.0.0.1:53) DNS, resolution is working. Somehow dnsmasq seems to lose requests into a hole in space and time...
If you suspect a bug, do report it upstream.
Actually, I have this problem after almost every "pacman -Syu"
Surely dnscrypt and dnsmasq are not being updated *every* time you run a pacman -Syu? I find it hard to think that the *act* itself of running a pacman -Syu is causing breakages... but it might not be outside the realm of possibilities if you have a post transaction hook involved. Granted, most of this is just speculation. However it certainly can't hurt to rule this out. Do you have any hooks in /etc/pacman.d/hooks? I have my reflector-mirrorlist-fixer script here. I'm not sure if this directory would be blank otherwise. It is very odd, however, that your config files are being overwritten. I would expect that you might have a .pacnew/.pacsave file. Or at the very least, comments warning you that "contents of this file will be overwritten each upgrade" type of a message. Hopefully you can fix this, or find a fix for this though! I *hate* having unsolved/un-fixed issues that refuse to go away. *queue my pesky ralink rt3290/network troubles*
I have been diagnosed with Bipolar Disorder. Therefore, I apologize in advance if the quality/content of my posts decline sharply, at any point.
Surely dnscrypt and dnsmasq are not being updated *every* time you run a pacman -Syu?
The breakage is not necessarily limited to upgrading dnscrypt and dnsmasq. DNS resolution (particularly with dnscrypt+dnsmasq) is vulnerable breakage caused by several packages, such as bind-tools and even glibc. I have to reconfigure everything dns related from scratch just to figure out at which point the failure has occured after almost every system upgrade; I wish that were an exageration.
One problem with dnscrypt until recently is that it did not use proper config files, but instead users were told (by the archwiki) to edit systemd service files to set it up (made some changes there). Of course there were a dozen or so additional things I could have bothered to read by clicking the word "edit" on that page, but by the time I'm checking the archwiki (on a computer with working DNS or by using another resolve daemon) I've already read dozens of pages about dnscrypt, dnsmasq, bind-tools, dhcpcd, etc. It's seriously too much.
Every time I have this problem I spend about two hours reading things I've already read and learning things I already know to fix problems I've already fixed. LOL, the last time I had actually read about systemd overrides separately from the archwiki, didn't realize that's what the page "edit" linked to was talking about, and posted a recommendation to create and edit the .override file on dnscrypt's wiki page (which was quickly reverted). That's how stupidly complex this can get--I end up gathering information from so many different sources and trying so many different hacks I don't even know what information came from or goes where.
Last edited by quequotion (2017-02-17 16:03:53)