I don't have a source, I'd have to dig through my browser history, but I looked at some of these stats just last month.

Roughly 2% of the top 1000 domains in the United States had deployed DNSSEC - which I *think* is double what it was a year ago.

Roughly 7% of ISP recursive DNS servers enforce DNSSEC.

Comcast does and Google's public DNS does. Those are the big ones that enforce DNSSEC on their recursive servers.

I do not see any statistics for DANE adoption, either on port 443 or port 25 (the two where it is most common currently)

Roughly 20% of all e-mail traffic in the United States was not encrypted.

Of the e-mail traffic that was not even encrypted, a large percentage of it was spam. What wasn't spam was often sent by scripting languages (e.g. php) running blogs or other web services.

Only a small percentage of e-mail sent by clients through a SMTP server was not encrypted in the MTA to MTA transfer.

-=-=-

What we can do as sysadmins, we can run unbound on our local machines, it defaults to DNSSEC enforcing. That way we don't have to worry if the recursive resolver our ISP uses is part of the 7%.

Linode enforced last time I checked, but I don't know about other hosting services.

Still safer to just run unbound listening only on the localhost, and configure /etc/resolv.conf to point to ::1 (or 127.0.0.1)

If at all possible, deploy DNSSEC on any zones you have control over. Even without DANE, DNSSEC greatly improves security for the 7% (and growing) recursive resolvers that enforce DNSSEC.

Before deploying DNSSEC do a lot of reading on it, because if you screw it up, those 7% enforcing recursive resolvers won't resolve your zone.

I personally use a 2048-bit KSK and a 1024-bit ZSK.

The KSK is what you have to get the DS record for uploaded to your TLS, and it should be rotated once a year.

The ZSK is just in your zone, best practice says to rotate once a month but I rotate once a week, every Sunday. It should be automated, so it doesn't hurt to do it more often than the once a month. Doing it once a week means if my zone signing server is down or under DDoS when the signing happens, it isn't a big deal, because it happens 4X the best practices recommended anyway.

With our web applications that send e-mail, don't use the SMTP services of the scripting language. Yes it is cool that you can play SMTP server with PHP etc. and yes, if PHP is built against a TLS library it can encrypt, but don't use PHP to play SMTP.

Run postfix on the web server and have your web applications connect to the SMTP on the local host.

This isn't just for the benefit of encrypting, it also lets you do things like sign the message with DKIM and if your postfix is new enough, check the DANE records of the MX record the message is being sent to.

I don't know why so many web applications try to play SMTP themselves, it is a very bad habit and usually results in mail being sent without TLS and sometimes rejected by spam filters if the domain it allegedly comes from uses DKIM but the web application doesn't.

-=-=-

Hope I didn't bore too many people, or offend anyone, these are just my opinions and this is a topic I am passionate about.

I think system administrators need to do a better job at securing Internet infrastructure.