Part 2 now ready: https://www.orwell1984.today/dns.html Wishing Merry Xmass to all at Wilders! Don't eat too much ham
Stefan, thanks for this tutorial! I implemented it in Fedora 27 but I have to say when activating encryption it's extremely slow although I enabled TCP Fast Open. FWIW, I read a similar article in the computer magazine c't some weeks ago. Its online version is available here for a small fee, the configuration files used therein can be downloaded for free here. The article says that DNS requests can be much faster by combining unbound with dnsfwd. Have you tried that? The article also combines unbound (and dnsfwd) with stunnel. AFAIK, stunnel provides encrypted communication for clients and/or servers which do not use SSL/TLS natively. So does this mean that DNS over TLS can be used with any DNS server?
Hmmm...that is strange. TCP Fast Open should give performance boost. You sure you have either value 3 or 1027 in /proc/sys/net/ipv4/tcp_fastopen ? Also what version of unbound the fedora is using? Also, if you want, you can private me your unbound config and, if you want, your IP (if static IP) or IP range (if dynamic IP) and I can give you test access to my own DNS-over-TLS server that you can try if speed any better. I honestly don't know. I haven't tried either dnsfwd or stunnel but I will certainly take a look.
Interesting Stefan, well done. I set up a private recursive DNS server on a VPS with Unbound early last year. Now I'm going to have to go over my configuration and compare it to your recommendations. I used a modified version of Pihole to black hole ads on the VPS. It combines several hosts files and adlists into one master list and is updated daily with a crontab. I have a local caching server set up on a Raspberry Pi that is tied to my router and powered by the routers USB port. One thing I learned the hard way is that "access-control: 0.0.0.0/0 allow" leaves your DNS server open to be used for a reflective DDOS attack via DNS amplification. A brief description of that is here: https://www.incapsula.com/ddos/attack-glossary/dns-amplification.html I ended up with the VPS suspended and the port speed choked for a month after it was reactivated. I learned my lesson and set up a second DNS server on another VPS to have a backup and restricted access to my own IPs. The encryption part is the most interesting to me. That is the next step to where I'm going with my DNS servers. I'm not using domain names with my servers so Lets Encrypt is not going to work as a certificate provider but I could easily generate self signed certificates for the connection between the Pi's caching server and the VPS recursive server.
Thanks MisterB That's really nice setup you have Raspberry has no trouble handling the DNS workload? Yea that is a problem if allowing all public to use your DNS, it could be used for bad purposes. So it needs somekind of heavy duty connection ratelimiting with firewall and DDOS protection (I wonder how google does it?) Of course, it's much easier, faster and more harder to track of doing DOS attack with UDP than TCP. With UDP one simply set's the destination and source IP addresses to anything they want and start firing the packets, preferably from multible taken over machines with fast connections. With TCP and it's 3-way handshake and requirement for bi-direction connection (aka source IP must be same as connection initiating machine) I don't think DOSin would be as practical ?? EDIT: I found out that Unbound does not currently verify the sent server certificate https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=658 The author of Unbound is working on with that. In the meantime, make sure you have DNSSEC enabled
Yes (I chose 1027)! Although I was a bit surprised that that file is not editable even with root rights. The echo command has to be repeated after every reboot. But it's a breeze to automate this. It's v. 1.6.7. Here are the relevant entries in unbound.conf: Code: ssl-upstream: yes forward-zone: name: "." forward-addr: 9.9.9.9@853 #forward-addr: 145.100.185.15 #forward-addr: 145.100.185.16 #forward-addr: 8.8.8.8 #forward-addr: 8.8.4.4 # forward-addr: 192.0.2.73@5355 # forward to port 5355. # forward-first: no forward-ssl-upstream: yes This is my resolv.conf: Code: options use-vc nameserver 127.0.0.1 #search fritz.box #nameserver 192.168.178.1 As mentioned loading websites for the first time is extremely slow, particularly if they contain lots of 3rd party links. Once cached in unbound, it's okay. Using dig the query time for a domain is without encryption about 45 msec, with encryption it's several hundred msec. After modifying unbound.conf and restarting unbound several times, dig doesn't get any results anymore: always "connection timed out". This happens even after flushing the cache with unbound-control reload. EDIT: Sorry, forget the last remark. I forgot to set do-udp: yes again.
No, not as a caching server at least. The only problem I've had has been hardware--the microusb power connector was not very secure and would easily become disconnected. I ended up gluing it with silicone. It is also not the only DNS service I am using. I have two routers each with two openvpn clients running. One is for my own openvpn server running on the same VPS. That and my ISP Ip are the only connections using the DNS server. The commercial VPN services all use their own DNS services and all of them are isolated with custom IP tables forwarding rules on separate vlans. I also use a Smart DNS service that is intended for unblocking georestricted content but I find it does wonderful things to geolocation in general. The traffic from my browser can appear to come from several locations at once, none of them where I actually am. I've spent some time thinking about how it works and trying to reverse engineer it. As far as I can figure, it uses local proxy DNS servers and forwards requests to the appropriate location. The replies are forwarded to the main server and then to clients. Logically, I don't see how it could work reliably without a VPN tunnel but it does and these services are fairly common these days with the selling point that they are much faster than a VPN. Yes indeed, and I looked at the hardening options in my conf file. All are enabled. I was looking at speed, privacy and security when I set it up enabled any options that helped in those areas.
You can also use sysctl (man sysctl for more info) to tweak various kernel settings. For example, I have the following in my /etc/sysctl.conf file: net.ipv4.tcp_fastopen = 0x403 (0x403 is hex for 1027) And then in my boot init script I have just the command "sysctl". That will read and set automatically values found from /etc/sysctl.conf But of course, Fedora has to do it it's own way ..(grrrrr) https://forums.fedoraforum.org/showthread.php?285060-etc-sysctl-conf-file I checked the fedora source SPECS file and they don't seem to enable Fast TCP in their Unbound. http://pkgs.fedoraproject.org/cgit/rpms/unbound.git/tree/unbound.spec They are missing the --enable-tfo-client --enable-tfo-server switches from their build configuration. if I understanded the https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt correctly, setting 1027 (or 0x403 in hex) should enable TCP fastopen by default for all, client and server connections. So there should be no need for those --enable-tfo-client --enable-tfo-server switches when compiling Unbound but I am not 100% sure. Anyway, I made some tests and found out the following: First the baseline, using just UDP and Google DNS and overriding my own DNS settings this time: Im using mobile connection so that result is super good for me Interestingly, when doing the same with TCP I got faster results (so maybe the Fast TCP must be working...or maybe just caching ...) Okay, so using one of the fastest public DNS out there, with/without UDP and without encryption, I get around 500 ms over mobile. Now, let's use 9.9.9.9 with all the encryption and DNSSEC enabled That's just awfull! Let's try with DNSSEC disabled Much better! My own server with encryption and DNSSEC enabled And finally, my own server, with encryption enabled and DNSSEC disabled So the conclusion? The choise of server matter's (9.9.9.9 is not the most fastest out there and I got several times "connection time out" when testing) but even more bigger than choise of server is whether or not you have DNSSEC enabled. (my server, encryption+DNSSEC: 1559 vs. my server encryption -DNSSEC: 774)
Thanks - I had forgotten about that After adding above line to /etc/sysctl.d/99-sysctl.conf the 1027 was obviously persistently saved after a reboot. Okay, I'll try to investigate this issue, too. Same here - I guess it's due to caching, indeed. Yes, it seems so. I'll try to implement a solution with dnsfwd. Let's see if that improves the situation.
Something else came into my mind too: Browsers nowadays use things like dns prefetch and link prefetch. So when one visit some site the browser "guess" what links you would most likely be linking next and will "click" the links beforehand so to speed things up. Personally, I think it's an insane idea and have those always disabled. If I visit some site that has 5, 10, or 15 links to to different sites then it could mean that my browser would do the encrypted, DNSSEC enabled (very heavy operation!) namelookup for all those 5 - 15 links ! So that would certainly slow things down (and if not for encryption, also reveal information to unneccessarily to 3rd parties) So if you are using firefox, go to about:config and set network.dns.disablePrefetch to true and network.prefetch-next (even more insane feature, downloads whole pages beforehand) to false I guess there is maybe some similar setting (or extension) for Chrome/Chromium too And while you are at the FF about:config page, you could also enable HTTP pipelining too (network.http.pipelining, network.http.pipelining.ssl and network.http.proxy.pipelining)...does not speed dns lookup but does speed the actual transfer of pages. (at least FF 52 has those still, heard rumors that later Firefox removed them...********...) Oh, and enabling network.proxy.socks.remote_dns does not hurt either... you never know when you might need it....
Yeah, and just found out why https://support.mozilla.org/en-US/questions/1166780 So because HTTP/2 is supported now by about 23% (https://w3techs.com/technologies/details/ce-http2/all/all) and for other "speed enchancement", they decided to remove it. I would be really really interested to see speed benchmarks of latest FF against HTTP/2 enabled site versus old HTTP 1.1 site and also benchmarks of old non-quantum FF against HTTP 1.1 site
Stefan, FWIW I replaced 9.9.9.9 with Code: forward-addr: 145.100.185.15@853 forward-addr: 145.100.185.16@853 in unbound.conf. They are much faster. http://www.whatsmydnsserver.com/ reports: dnssec works, too: Code: dig +dnssec whitehouse.gov ; <<>> DiG 9.11.1-P3-RedHat-9.11.1-9.P3.fc27 <<>> +dnssec whitehouse.gov ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5470 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;whitehouse.gov. IN A ;; ANSWER SECTION: whitehouse.gov. 20 IN A 23.38.20.31 whitehouse.gov. 20 IN RRSIG A 7 2 20 20180113132441 20180110122441 42683 whitehouse.gov. YyMvhOkSxtczb6/W0IuMxfwSBjVzTewWc1y384UUBQS19TMoNFrIcnV/ UeTObFh66MssSHuG1qjHHOL4Slin8qXVHDCxQXanWUQMORn4FxLHnb+K zvrd9vNE0poqRVqYXWJQ8rY8pJNVXho+QMLdd5LTRbsl30EdN+bIdq5U tSs= ;; Query time: 429 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mi Jan 10 19:35:05 CET 2018 ;; MSG SIZE rcvd: 233 So everything seems to work well right now BTW: If you're interested: I sandbox unbound with Firejail (here's the profile which works well). I created the folder unbound.service.d in /etc/systemd/system and the following override.conf file therein: Code: [Service] ExecStart= ExecStart=/usr/bin/firejail /usr/sbin/unbound -d $UNBOUND_OPTIONS
