after experimenting with DoT using unbound I installed dnscrypt-proxy to check out DNScrypt resolvers.
The resolution pipeline on openwrt after installation is as follows for external names:
unbound@53 -> dnscrypt-proxy@5353 -> external dnscrypt resolver
For internal names it is:
unbound@53 -> dnsmasq@53535
I know that I could remove unbound, but for now I leave it as it is so that I can still switch to DoT resolvers if I wish to do so (oder does dnscrypt-proxy support DoT??)
I checked if DNS resolution will take only use the desired external resolver via the proper protocol. Both, for unbound DoT and for dnscrypt-proxy DNScrypt resolvers I can see them being used.
I also wanted to check that no regular DNS will be sent out on port 53, using tcpdump:
tcpdump -vv -x -X -s 1500 -i ethX 'dst port 53' (X being the external interface)
When using unbound only (without dnscrypt proxy, there is no traffic destined to port 53.
However! When using dnscrypt-proxy there is a lot(!) of traffic going to ns2.recursive.dnsbycomodo.com ! (this is going on in addition to the traffic going to the correct DNScrypt resolver via a different port!). tcpdump says that the outgoing dns queries to port53 have bad UDP checksums, still the resolver responds.
I cross checked whether that traffic was generated by any of the machines on the internal interfaces, but no. This traffic would only be seen on the external interface (WAN) and seems to be generated from the openwrt router.
I am not saying that dnscrypt-proxy is intentionally leaking the information, but this would be the worst case.
Has anyone seen this happening and an explanation and even solution for this?
the leakage only happens when i hand off the resolution of external names from unbound to dnscryp-proxy. It does not happen when just using unbound. From this I conjecture that it happens in dnscrypt-proxy.
tcpdump -vv -x -X -s 1500 -n -i ethX 'dst port 53'
tcpdump: listening on ethX, link-type EN10MB (Ethernet), capture size 1500 bytes
22:17:30.934324 IP (tos 0x0, ttl 64, id 23473, offset 0, flags [none], proto UDP (17), length 66)
X.X.X.X.63551 > 8.20.247.20.53: [bad udp cksum 0xfe51 -> 0x12a8!] 3936+% [1au] DS? aPPle.Com. ar: . OPT UDPsize=1280 DO (38)
and you had the right hunch, I found this in the unound config: forward-addr: 8.20.247.20@53, so unbound was resolving via dnscrypt-proxy AND the comodo dns!
-> uncommenting the forward to comodo dns solved the problem.
The problem was self-made, no problem with dnscrypt-proxy.
Thanks for the help and case closed.
If your problem is solved, feel free to mark the relevant post as the solution; and edit the title to add "[SOLVED]" to the beginning (click the pencil behind the topic).