Problems With Dnscrypt’s Package From EPEL
Hi all,
I have installed dnscrypt’s rpm package from EPEL repo under a CentOS 7.4 and using unbound as a resolver. But, I see constant timeouts and responses are very slow … Using same config in a Debian 9 virtual machine, all works ok.
I think the problem is with dnscrypt’s rpm package provided by EPEL. Anyone have seen similar problems?
Thanks.
6 thoughts on - Problems With Dnscrypt’s Package From EPEL
Can you give some more information on what you are seeing and how you have it set up? I can try to duplicate it in EPEL and/or put in bugs on the package.
Of course and thanks in advance Stephen. My dnscrypt startup scripts use the following options:
[Service]
Type=forking PIDFile=/var/run/dnscrypt-cs.pid ExecStart=/usr/sbin/dnscrypt-proxy \
–daemonize \
–user=nobody \
–pidfile=/var/run/dnscrypt-cs.pid \
–ephemeral-keys \
–resolver-name=cs-fi \
–logfile=/tmp/cs.log \
–local-address7.0.0.1:6354
Restart=on-abort
[Service]
Type=forking PIDFile=/var/run/dnscrypt-ipredator.pid ExecStart=/usr/sbin/dnscrypt-proxy \
–daemonize \
–user=nobody \
–pidfile=/var/run/dnscrypt-ipredator.pid \
–ephemeral-keys \
–resolver-name=ipredator \
–logfile=/tmp/ipredator.log \
–local-address7.0.0.1:6353
Restart=on-abort
And unbound.conf is:
server:
interface: 127.0.0.1
interface: 172.22.54.4
interface: ::1
port: 53
do-ip6: no do-udp: yes do-tcp: yes num-threads: 1
access-control: 0.0.0.0/0 refuse access-control: 127.0.0.0/8 allow access-control: ::0/0 refuse access-control: ::1 allow access-control: 172.22.54.0/29 allow access-control: 172.22.55.1 allow
hide-identity: yes hide-version: yes
do-not-query-localhost: no val-permissive-mode: yes val-clean-additional: yes module-config: “validator iterator”
Oops .. sorry. There are more options in unbound.conf’s file:
remote-control:
control-enable: yes control-use-cert: yes control-interface: 127.0.0.1
forward-zone:
name: “.”
forward-addr: 127.0.0.1@6353
forward-addr: 127.0.0.1@6354
forward-addr: 127.0.0.1@6355
Sorry.
Not sure if this is a factor yet, but your forwardzone is looking for
3 ports but only 2 ports are configured in the systemd startup.. so are 1/3 of all lookups going to fail? Or is the 6355 a ‘given’ (aka it will be set up whether 6353 and 6354 are setup?)
Sorry Stephen. I have enabled another dnscrypt process in port 6355 to test … But no luck.
Can you give more information on the unbound setup? We use unbound in Fedora Infrastructure on RHEL-7 servers. I know there is an selinux dance we have to do to start it properly without a special policy… but I don’t know exactly the details on why.