It seems that to have encrypted DNS I need, dnsmasq, unbound, getdns and strubby. Of course each performs a different task and they all rely on each other. What could go wrong?
What the HELL happened to KISS (Keep It Simple, Stupid)???
For now I think I will stay with DNSCrypt. The configuration is easy, well documented and it has been working with OpenWrt for years so it's not experimental compered to his DNS-Over-TLS mess you are proposing. Also DNSCrypt v2 supports DNS-Over-HTTPS witch from what I read is far more secure, reliable and VERY HARD to block by ISP, compered to the TLS alternative.
see this section - what this section describes is an environment where the only DNS resolver being used is Stubby forwarded to Unbound - that is what the " list server " entry does in dnsmasq config file. Therefore your statement that" Also the dns resolution fails on the router if unbound is the main dns server. is incorrect and misleading. Perhaps - you meant to say that "dns resolution fails on the router if unbound is the ONLY dns server.
Parallel DNSMASQ /etc/config/dhcp
After Some Reflection and Observations - Fine Tuning Your DNS Resolver
After reading System Logs I realized that there is a need to amend DNSMASQ ( DHCP ) after implementing option noresolv ‘1’ in /etc/config/dhcp configuration file. This dawned on me from my years of running DNSCRYPT Proxy on OpenWrt. I referred to this guide:
option noresolv ‘1’ is to prevent using any upstream DNS server other than those specified in this file # this file being: /etc/config/dhcp
Solution is as follows add these four lines to /etc/config/dhcp:
nano /etc/config/dhcp - enter these lines before / option domain ‘yourdomain’
list server '127.0.0.1#5453' # Stubby/Unbound Default Address/Port
list server '/pool.ntp.org/84.200.69.80' ## DNS WATCH SECURE option noresolv ‘1’ ## Make sure to change this as indicated
option allservers '1'
I see no use for IPv6 in my small home network.
And i would need to maintain/setup everything twice. (Once for IPv4 and once for IPv6 )
When the internet will be IPv6 only one day, i think i will use NAT64/NAT46.
In some regions "the internet" is already on its limits, bad download rates, high latency in rush hours.
Now imagine when IPv6 goes mainstream and almost everything has internet access.
No wonder they are deploying CDN's all over the place to split the traffic into regions.
And removing net neutrality in some countries already, so they can charge you extra money for various services (gaming,streaming etc..), so you can enjoy your lag free experience.
Why use stubby + unbound together?
Doesn't unbound already have DNS-over-TLS support build-in?
Saying DNS-over-HTTPs is better because it uses port 443, i don't know.
Some DNS-over-TLS also run on port 443.
I think the question should be what is more "secure" DNS-over-TLS/HTTPS or DNSCrypt?
Can someone explain why using option noresolv ‘1’ gives me an empty resolv.conf file?
This breaks the reverse dns resolution on the luci connections tab.
But dns resolution seems to fine, when i test with ping for example.
Unbound can be run as a local caching forwarder, configured to use SSL upstream, however it cannot yet re-use TCP/TLS connections or send several of the privacy related options (padding, ECS privacy) etc. The 1.7.1 release of Unbound supports authentication of upstream recursive resolvers using an authentication domain name (i.e. PKIX authentication).
Some user combine Unbound (as a caching proxy with other features such as DNS Blacklisting) and Stubby (as fully featured TLS forwarder).
Setting up a TLS connection is expensive in terms of both system resources and time. Stubby can help reduce the load and increase the speed, especially on resource-constrained systems like home routers.
You are also spreading false information on my tutorial. DNSCrypt Synopsis: 1. Not completely encrypted: Even though the domain requested (question) and IP address (answer) is hidden, the complete process is not obfuscated. The total number of questions, their relative size and more remain available. Furthermore, it remains trivial to identify that you are, in fact, performing DNS resolution. DNS OVER TLS Synopsis: 2. DNS over TLS takes a completely different approach, establishing a fully encrypted tunnel between your computer and the DNS server. Rather than sending requests in the clear, with just the critical data encrypted, the whole connection is encrypted. Furthermore, since TLS is the encryption protocol used to secure almost all other internet services, the technology is well understood and constantly improved.
I was joking sort of. However - you were / are complaining. There have been over 1600 views of this tutorial here and elsewhere. Yours was the first complaint which also included some negative comments / conclusions about this process. Did you ever consider that it may be that this whole endeavor just may be beyond you and your skill level? Which there is no shame in that. But instead of trying to ask for help and clarification - you went into ( negative ) judgement mode.
READ THIS:
Directly From DNS Privacy Website: Stubby is an experimental implementation of a DNS Privacy enabled stub resolver. It is currently suitable for advanced/technical users - all feedback is welcome! Also see dnsprivacy.org for more information on DNS Privacy.
Maybe I should have cited that. I also warned folks not to give me a hard time about this guide. So if you are not here to help row the boat - well - just leave the ship alone. Forgive me - but those are my honest feelings about anyone who comes off as being hypercritical in a negative fashion - especially due to their own ignorance of certain issues. As I said - I am here to help - but please let's all act like responsible mature adults willing to engage in the free exchange of ideas and skills.
You're not wrong about that. However above concerns DNSCrypt v1 and only partially v2.
DNS over TLS takes a completely different approach, establishing a fully encrypted tunnel between your computer and the DNS server. Rather than sending requests in the clear, with just the critical data encrypted, the whole connection is encrypted. Furthermore, since TLS is the encryption protocol used to secure almost all other internet services, the technology is well understood and constantly improved.
About above. Here's the quote I based my opinion on:
There's also a certificate-management issue here. If a provider retires a certificate and starts using a new one, there's currently no clean way to update the SPKI data on clients other than cutting and pasting it into the configuration file. Before this approach becomes fully baked, some sort of key-management scheme would be helpful. And since it operates on port 853—a port that isn't frequently opened up by firewalls—DNS over TLS gets voted "most likely to be blocked."
Good it's encrypted. Too bad it will likely get blocked.
I'm glad you mentioned this:
Directly From DNS Privacy Website: Stubby is an experimental implementation of a DNS Privacy enabled stub resolver. It is currently suitable for advanced/technical users - all feedback is welcome! Also see dnsprivacy.org for more information on DNS Privacy.
The experimental part worries me. It's not because of advanced/technical skills that are somewhat required. I'm wondering if it's really the best configuration for OpenWrt/LEDE in terms of security. Regarding KISS rule, this seems overtly complicated to implement and with security in mind, the more something is complex, the bigger is the area where you could make a mistake. You are yourself warning users about outages of Internet connection while applying your guide.
However DNSCrypt v2 (not v1) does support DNS-Over-HTTPS. It also seems to work faster and it's A LOT easier to implement, which means less chance you'll make a critical mistake while deploying it. DoH is also harder to block because it passes through most firewalls like they aren't even there.
On the whole, DNSCrypt Proxy's DoH performance was virtually indistinguishable from that of the DNS-over-TLS resolver I tested. In fact, it was faster.
You should also remember about the key-management issue with DNS-Over-TLS. Something that is non-existent with DNS-Over-HTTPS.
There's no issue here with certificate management. Just as with normal HTTPS Web traffic, no authentication is required to connect over DoH, and certificate validity can be verified by a certificate authority.
However I still encourage you guys to keep working on DoT. I guess with time those problems can be resolved or at least mitigated. I'm not really trying to give you a hard time. I'm just trying to point out that your guide might not be the best solution security wise. It might be the best way to implement DNS-Over-TLS at this point but the technology might be lacking in some areas. If I'm not wrong, Google and Facebook opted in favor of DoH, instead of DoT. I understand my first response might have been a bit unclear. I hope this post helps you find it more approachable.
By the way, my OpenWrt Router has been up and running for weeks with no problems running DNS OVER TLS as described here in this tutorial. If you have not actually tried and used this method then much or all of your observations are devoid of any " real world " experience. I would say that DNS OVER TLS is very stable. I have also worked with developers of FreeBsd / Pfsense and OpnSense GETDNS and STUBBY. See here if any of you are interested: https://forum.opnsense.org/index.php?topic=8611.0
Furthermore, since TLS is the encryption protocol used to secure almost all other internet services, the technology is well understood and constantly improved.
Stubby is in the early stages of development but is suitable for technical/advanced users. A more generally user-friendly version is on the way!
As far as being blocked on port 853 goes see the post above: One advantage of unbound is it does query the root servers directly and then goes from there. So you don’t share dns query data with companies like google, opendns, cloudflare and so on. But the dns traffic can still be analyzed, since there is no encryption. @shm0 I disagree with shm0 in that Unbound resolves DNS after being forwarded to from STUBBY which is the actual DNS resolver being utilized. STUBBY encrypts all DNS queries. Therefore port 853 is not blocked as after STUBBY does DNS resolution - Unbound queries root servers directly.
Again - you have made assumptions and conclusions which do not concur with the actual real process of DNS OVER TLS using GETDNS and STUBBY (a fully featured TLS forwarder). Please stop doing so until you have a firm grasp on how this works. Thank you- Lastly, if you care to share a link to a tutorial / references which outline how to deploy DNSCrypt Proxy’s DoH I would like to take a look at it. Read this please: DOH is Experimental As Well:
DNS-over-HTTP (DOH)
The IETF created a new DOH working group in Sept 2017 to look at how DNS messages could be sent over an existing HTTP/2 connection. It is in the very early stages but one advantage of this approach would be to intermingle DNS and HTTP traffic on the same connection and make blocking of encrypted DNS harder. As of May 2018 the draft https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/ is in WGLC and there are several experimental implementations and deployments. It should be noted that this draft addresses almost purely protocol issues and a follow up document on discovery and operational usage is expected.
directnupe
I understand and I was directing that last comment to @r43k3n. I learned a lot from you and @r43k3n
I now have the setup using some resolvers with Port 443 as well as you pointed out earlier. Thanks for your feedback and input. I was talking about Port 853 being blocked but @r43k3n enlightened me about this being a potential problem. So I apologize to you both and thanks again for a forum where we can all work together and learn from one another.
I wrote this guide and I am a retired English Instructor. I suggest that you read the guide carefully along with the well referenced linked materials. Consider it homework. Lastly, do not call my work " a mess " without realizing that your lack of understanding is due to your failure to do your due diligence.
Peace,
directnupe
You really spread a great deal of false assertions about DNS OVER TLS. You also called this " work " a " mess ".
What you should do is carefully re-read this guide and learn a few things. I do not know if you are deliberately out to mislead folks. Or just the type who makes up " false " non-facts due to a need to be right. I do want to thank you though as your misguided views caused me to edit this guide so others will not read your posts and be led down a completely misguided path. I am a retired English Instructor and nothing irks me more than a " know it all " who is repeatedly wrong. Dnscrypt Servers go down - Dnscrypt was shut down for God's Sake. Why do you think I moved over to this method of DNS OVER TLS. Does DNSCRYPT allow anyone to monitor their servers in real time? The answer is no. So re-read the tutorial and please learn the errors of your earlier assertions regarding DNS OVER TLS. If you had read this link below alone you would have never made the spurious claims as you originally did:
Out of three thousand people who have used this method - there is you and one other who have lacked the basic sense in order to figure this out.
Makes me wonder what is wrong with who ? - the tutorial or you two.
@directnupe Unbound 1.7.3 on OpenWrt master and appearing in 18.06rc1 forwards compliant DOT. It should be possible to avoid most of the complexity with other packages. Cloudflare makes particularly nice example or test target. Also separate topic but useful, Unbound can serve DOT. (No DOH though).
Unfortunately, UCI and LuCI have not be formulated for this yet, but the conf exception files can be used to implement it for now. However, entering a forward: clause with port 853 is not enough (unbound_ext.conf), but appears in most of the How To in the wild. Don't forget to place this option tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt inside the server: clause (ubound_srv.conf) and be sure to check install of ca-certificates package.
