are there any advantages why one of those packages should be used over the other one?
I am aware of the differences between DoT and DoH so let's please focus on the tools itself.
stubby:
-ability to specify the TLS version that should be used
-doesn't open a new encrypted connection for every single dns query
-dnssec validation not completely dependent on dnsmasq-full
-round robin for all resolvers
https-dns-proxy:
-luci integration
Is there anything more to consider?
Stubby seems to be more flexible, but what do you think about the performance of those two?
I'd like to thank you for making me aware of stubby. I had tried using https-dns-proxy a couple of months ago on a 19.07 snapshot but ran into an issue where it would randomly peg the CPU on my router (50% each for the Cloudflare and Google instances) and eventually get killed by the OOM reaper. I gave it a try again after 19.07 since it was a more recent version but the problem is still there.
@stangri
Do you know if https-dns-proxy supports encrypted SNI?
Stubby doesn't seem to support it (yet).
@Barrakketh
If you don't mind using DoT instead of DoH then I guess stubby is a nice solution.
@AndrewZ
Do you also use DNSSEC?
Performance of stubby is good so far, but I enabled dnsmasq to do the DNSSEC validation and it got much slower - still nothing to worry about.
Neither will, because ESNI operates independently of DNS proxies/resolvers. It is established between the requesting client and the web server. See here for more information.
My last information was that there were plans to integrate it into stubby, but as I just found out now this is all at early stage and far from finished: https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
So from my understanding it is just not possible (yet) because there is no support in OpenSSL?
My https-dns-proxy would randomly freeze up to, I think it had something to do with libcurl, but I got it to work with no more errors by adding option use_http1 '1' to /etc/config/https-dns-proxy
I used both both DoH (https-dns-proxy) and DoT (stubby) on my openwrt instances and in general performance wise was about the same (tested again Cloudflare). On my router with limited RAM, https-dns-proxy took up smaller memory footprint however, I settled on stubby because to me it appears to be less over-the-wire overhead: DoH: is dns payload wrapped in http wrapped in tls whereas DoT is dns payload wrapped in TLS. There is one less layer to deal with and logically seems more optimal.
Assuming you are saying stubby requires openssl instead of wolfssl.... are you sure about that?
I am currently using stubby and I have wpad-wolfssl installed. I am pretty sure stubby is working properly as I have port 53 to the outside world blocked.
I have both libopenssl and libwolfssl installed along with stubby so I'm not sure if libopenssl was installed by stubby or some other package
Edit: Just verified that libopenssl was not installed by stubby. I have python3 installed as well on my router (overlayed on an external usb) which installed libopenssl. Stubby probably is using wolfssl.
Edit 2: I stand corrected. Looks like stubby is using package called getdns which requires libopenssl.