I just came back and tried the loopback interface method. For Unbound the interface method allowed it to start; For dnsmasq it's the same effect as Virtual IP. Both methods share the same caveat.
When either Dnsmasq or Unbound is enabled, dnscrypt-proxy config page says "Dnsmasq / Unbound is currently using one of these ports." no matter what Listen Address is. And the reason for the error message is that dnscrypt-proxy plugin only checks port not interface.
Source
I noticed that the programs don't actually crash if I managed to get pass the error*, so I was using it in the past few months. However, anecdotally my family says opening web pages is slow. I have moved dnscrypt-proxy off the router to a separate device, and we'll see... (my bet is it's not related)
* I got passed the error by disabling dnsmasq DNS first, enable dnscrypt-proxy, then enable dnsmasq DNS. In the backend dnsmasq is binding to 0.0.0.0:53, which in theory allows a more specific binding e.g. 192.168.1.53:53.
P.S.
dnsmasq with "Strict interface binding" doesn't work. dnsmasq won't start with dnscrypt-proxy running:
P.S.
The no RRSIG issue however, turned out to be a bug on Linux's systemd resolver.
When either Dnsmasq or Unbound is enabled, dnscrypt-proxy config page says "Dnsmasq / Unbound is currently using one of these ports." no matter what Listen Address is. And the reason for the error message is that dnscrypt-proxy plugin only checks port not interface.
Source
Code Select
if ($service['name'] != 'dnscrypt-proxy' && count(array_intersect(array_keys($ports), $service['dns_ports']))) {
$messages->appendMessage(new Message(
sprintf(gettext('%s is currently using one of these ports.'), $service['description']),
$this->listen_addresses->getInternalXMLTagName()
));
break;
}
I noticed that the programs don't actually crash if I managed to get pass the error*, so I was using it in the past few months. However, anecdotally my family says opening web pages is slow. I have moved dnscrypt-proxy off the router to a separate device, and we'll see... (my bet is it's not related)
* I got passed the error by disabling dnsmasq DNS first, enable dnscrypt-proxy, then enable dnsmasq DNS. In the backend dnsmasq is binding to 0.0.0.0:53, which in theory allows a more specific binding e.g. 192.168.1.53:53.
P.S.
dnsmasq with "Strict interface binding" doesn't work. dnsmasq won't start with dnscrypt-proxy running:
Quotefailed to create listening socket for 192.168.0.53: Address already in useEven though I specified LAN interface not the loopback interface, it's still trying to bind to it. Not sure what that's about...
P.S.
The no RRSIG issue however, turned out to be a bug on Linux's systemd resolver.
"