I just tested pdnsd on Debian 7.1 and can confirm that at least the comination pdnsd + resolvconf does not work out of the box (even after setting START_DAEMON=yes in /etc/default/pdnsd).
I found two apparent bugs. First, "resolvconf -a" is not called in the initscript on start. With "set -x" the initscript output is: + start_resolvconf + test -x /sbin/resolvconf + seq 1 60 + sleep 0.1 + pdnsd-ctl status + break + grep+ -q resolvconf pdnsd-ctl status + sed -ne /^Global:$/,/^Server.*:$/s/.*Server ip.*: \(.*\)$/\1/p + pdnsd-ctl status + server= + exit 0 Something seems to be wrong with the processing of the output from "pdnsd-ctl status". The variable "server" has as value the null string and consequently "resolvconf -a" doesn't get run. If I subsequently run "echo 'nameserver 127.0.0.1' | resolvconf -a lo.pdnsd" on the command line then pdnsd starts working. The second bug is in pdnsd's resolvconf update hook script. After running "echo 'nameserver 127.0.0.1' | resolvconf -a lo.pdnsd" the output of "pdnsd-ctl status" is: [...] Server 0: ------ label: resolvconf ip: 127.0.0.1 server assumed available: yes ip: 192.168.1.254 server assumed available: yes [...] It appears that 127.0.0.1 is now included as a forwarding address. Turning on "set -x" I can see that /etc/resolvconf/update.d/pdnsd passes both the real forwarding address and 127.0.0.1 as arguments to "pdnsd-ctl server resolvconf up". The address 127.0.0.1 should of course be filtered out if it's an address that pdnsd itself is listening on. -- Thomas Hood
