msturgill's comments

The Docker images are an option as well: https://hub.docker.com/r/certbot/certbot/

Windows Phone is not that bad.

Google has done a good job trying to starve WP users of their services, but I think we can all survive without Hangouts (Telegram, etc) and Google Voice (who cares anymore) at this point.

The DNS traffic doesn't need to be secret ("encrypted"), it just needs to be authenticated (i.e. the payload has not been modified and there is a chain of trust).

If a client is pre-seeded with trusted root keys, DNSSEC protected payload can be validated to the apex.

Broadly? General MITM, Kaminsky, etc.

DANE as an application of DNSSEC is interesting (and based on the recent string of editorials, contentious as well). Using DANE to constrain CAs could add an additional layer of protection against a rogue CA. Using it as an additional CA could help facilitate moving towards "HTTPS-everywhere".

The takeaway of course in implementing it in any manner is that it is just another layer, not a panacea.

Outside of DANE, there are other applications such as IPSECKEY and SSHFP that have utility.

There are a lot of real problems that DNSSEC can help solve.

However, it is important to note that DNSSEC and DANE are two different things. Much of the recent discussion here has lumped them together.

The author of this is missing the point of DNSSEC.

They seem to be confusing DNSSEC and functionality that is possible with DNSSEC (DANE/TLSA). Not only that, they don't seem to fully understand DANE (there are modes that complement the traditional CA model, not replace it).

DNSSEC is just another tool. It isn't a panacea.

I definitely urge readers to objectively research the technical aspects of DNSSEC and draw conclusions for themselves.

I think that description is pitching it as a tool for small businesses or development teams (that don't already know about ZNC, HexChat, irssi, weechat, freenode, etc).

You can find them even cheaper (~$30).

Hackability is just icing on the cake.