Is there any planning around the concept of baking DNSCrypt and/or DNSoverHTTPS/DNSoverTLS into OpenWRT 18.06 and beyond?
I'd love to be able to have a massive uptick in encrypted DNS traffic out of the box with the ability to switch DNSCrypt server as easily as it is to change DNS to 9.9.9.9 or 1.1.1.1 now..
The new DNSCrypt-proxy 2.0 is written in GO, and is quiet sizeable - but we should be able to package it up with a nice GUI for people with additional storage.
Is there any other options that can be offered out of the box? for passive DNS requests leaving the router to the internet.
People who think TLS (crypto) slows down the internet haven't done benchmark tests... It doesn't (massively), but does during first pass handshakes. TLS 1.3 is built to speed up connection requests and reconnections.
I'm a network engineer.. an additional few trips during the first handshake won't slow down DNS if it's cached correctly like your router VERY likely will. for the second and ongoing requests.
Anyway, it's off topic to derail over performance concerns.
I doubt that the openwrt will support encrypted DNS out of box until dnsmasq will get such features. Right now the best thing that can be done is a full support of getdns (stubby is too big?). Maybe as core package.
Net work engineer ... Im really impressed I can say, I coded device drivers already, when others were in kindergarden ... Shure, when DNS is cached no difference ... but during start-up, which can be annoying on some sites with lot of objects from lot of different sites. And what about all the many sites (doing load balancing using DNS-round-robin) with short TTLs ? Cached entries invalidated very fast.
Performance concerns are on-topic, when discussing new defaults.
I'd be strongly against it being "baked in" (which I take to mean part of a "release" build) for a variety of reasons. It's not a feature that is required for operation. It's huge, especially as compared to even 8 MB devices. There are still multiple proposals for secure DNS, and DNSCrypt is not one that is standardized or, so far as I know, being considered for standardization by the IETF. It's yet something else that I'd have to rip out of images to make them useful to me.
To me, the "right" approach is a set of packages and a LuCI "app" to manage it.
Then again, if I were to prioritize utility to the community, I'd put ease of GUI configuration of
i'm currently testing dnscrypt-proxy v2 with one of my extra router, a netgear wndr4300sw, and i like the simplicity of its one toml file for configuration. i followed the direction from https://github.com/jedisct1/dnscrypt-proxy/wiki/Installation-on-OpenWRT and compressed the binary file before including it with the imagebuilder. it's good to have adequate room to accommodate the compressed v2 binary.
This is actually a good point - DNSCrypt is one of many solutions... DNSoverHTTPS and DNSoverTLS are hopefully going to be supported quickly without the massive overhead of size.
I think supporting DNSCrypt as an optional package makes sense - but we need to investigate the other standards if they can be supported legitimately out of the box for default builds.. this might be one of those things that takes another 24 months but there are at least options now.
Progress is good.
sidenote: TLS is slow for the first connection and generally quick the next.. this is the exact same as DNS.. the first connection might be slow.. but once it's established, the overhead is almost non existent.. you don't need to complete a new socket and key exchange handshake every single DNS record? well you would hope
Besides a shitty attitude, what's your contribution here exactly? Obviously I know what a cache is and when it's being used, which is why I'm increasing the size and mentioning this in the first place. Are you even using dnscrypt? Have you measured the latency? Do you know how many of your lookups when surfing daily is cached or not?
It's probably way too early to be thinking of having encrypted DNS as a default, but as soon as a standard has been decided on it would be great to have an easy way to enable it. Hopefully dnsmasq will implement something.
I'm using DNSCrypt v2 on my LEDE 17.01 setup.
The original binary file size was around 7 MB. After compression it's around 1.7 MB so it's ~76% smaller. The configuration is super easy. I had it run beside v1 so if there was any problem I could just delete v2 and start v1 again.
Right now there are no issues. The latency is not noticeable. It supports DNSCrypt servers and DoH servers based on lowest latency. There is also a DNS Cache with default size of 512. For comparison the dnsmasq default cache is 150.
The RAM usage is higher when using one instance of v1 but with 8 configured DNS servers it's actually lower then using 8 instances of v1. The redundancy is default so I don't have to do anything more after the initial configuration.
I can say, I coded device drivers already, when others were in kindergarden ... Shure, when DNS is cached no difference ... but during start-up, which can be annoying on some sites with lot of objects from lot of different sites. And what about all the many sites (doing load balancing using DNS-round-robin) with short TTLs ? Cached entries invalidated very fast.
