A few weeks ago, I transitioned away from using Hurricane Electric’s free DNS offering. My overall experience with them was great; I can’t find a fault in anything they provided. The web interface was straight forward and I never had a problem adding or removing records. Updates were fast, and there was a straight-forward DDNS interface. There was no DNSSEC support though. I know that seems like a small gripe, but having some control over the validation of my own domain does have some value to me. I’m utilizing a wildcard certificate from Startcom and have so far been OK with it. OCSP validation support has been spotty at times. I’m intrigued by the Let’s Encrypt project, too, even if that places a bit of a burden up front in automating certificate deployment due to their 90 day certificate lifetime. If it turns out to be a better deal than Startcom, I may just end up switching to it. My only caveat is that I have a lot of subdomains, and the subdomains change on a regular basis. But as a general rule, anything that’s doing IO on the internet I want secured with a certificate that can be validated, so a wildcard certificate is what I think I’m going to need unless I can figure out some more elaborate automation with Let’s Encrypt.

–UPDATE: I took a quick glance at the installation method for the Let’s Encrypt certificates, and I think this could be completely automated - with each host responsible for a subdomain set handling certificate generation as necessary. This would require a little bit more automation on my end, since I would then need to update my DANE records once certs are generated.

What is DNSSEC and why is it important? Well, DNSSEC appears to be the leading effort in applying validation security to DNS records. For one, it provides a mechanism for signing the DNS zonefile, which defines the correlation of host names to ip addresses for the broader internet. It provides assurance to clients making a name resolution request that the host they end up going to is actually who it appears to be and is serving the certificate that is expected. So not only can the final resolved host employ TLS with the client, but the certificate can be validated back to the DNS server in addition to the root CA.

It probably sounds like a lot of work for not a lot of gain. You might be right. The last figure I read was that only about 30% of the web leverages DNSSEC, which is a shame. But, there’s a huge effort to get operators to shift to HTTPS only and with that will come broader support of TLS certificate validation. Once the DNS server is setup, though, editing the zonefile and signing the zone is extremely straight forward. I also have a script which handles zone signing - it increments the serial number, copies the signed zonefile and bounces the service. Also, it is a good idea to re-sign the zonefile every three days to prevent the possibility of cracking the signature. This is achieved with a cronjob executing the zonesigning script in a regular interval.

Additionally, employing the DANE protocol is a way to tie your (x509) certs to domains and subdomains. This gives you a more granular level of validation when it comes to the subdomains recorded within the zonefile itself. In addition to the zone record being signed, this gives you the expected fingerprint of the web server certificate. The browser can then validate the received certificate against the fingerprint given by the DNS query. If they don’t match, you know there’s a problem. It’s still not employed on most websites or DNS servers, but if you’re running your own DNS solution, it’s very easy to implement.

Yet another server-side solution is DNSCurve. I have not spent much time researching the feature - I’ll update when I add the tutorials for configuring the aforementioned DNS configuration on CentOS 7.

Another effort is encrypting the DNS traffic itself, via DNSCrypt and DNSCrypt-Proxy. This is a way to make sure that your ISP isn’t collecting your internet traffic data - because if you don’t already know, your DNS requests (pretty much anytime you type in www.googe.com you are asking a server somewhere, probably Google, to give you the IP address that’s associated with that subdomain) are not encrypted. This is a bit more difficult to setup and I have not yet employed a DNS server at home in a final state utilizing the software - I’ll have another post specifically about DNSCrypt, it’s deployment and usage. But the basic gist is that you will run a DNSCrypt client, which will listen for requests on your localhost adapter. You’ll reconfigure your DNS configuration to only query localhost, and you will configure the client to communicate with your chosen DNSCrypt-capable DNS server on port 54 (usually) or whatever else they have. You configure some additional validation to ensure that the client is properly authenticated with the server and the server is who it says it is, then it handles the handshake and encrypted communication. Convoluted, yes, but it’s one more level of abstraction from your ISP if you’re doing anything you do not want another person knowing about. And if you’re like me - that’s pretty much everything except the stuff I consciously choose to share.