undefined | Better HN

0 pointsteddyh2y ago0 comments

Chrome has no business “supporting” DNSSEC in the first place; it should all be handled by the operating system and the resolver. So I don’t think this is a point against DNSSEC.

My guess is that people are against DNSSEC because it’s difficult. You know how people are saying “It’s always DNS”? People hate dealing with DNS, because they don’t understand it. And DNSSEC is then another dimension of difficulty on top of that. But DANE is clearly the technically better solution. I mean, MTA-STS requires a file to be served from an HTTP server to even work. So now you need an HTTP server in addition to your SMTP server!

In any case, you should not, probably, deal with DNSSEC yourself! Note how the article does not cover running your own DNS server, but instead vaguely talks about editing DNS records. And if you have your DNS hosted by somebody else, DNSSEC is their problem. And once you have DNSSEC provided for you, you can use DANE and TLSA records without issue, without having to host an HTTP server for MTA-STS.

0 comments

mjl-2y ago

To protect my email with DANE, I ended up running DNS myself. I used to be at AWS Route53. It supports DNSSEC (but quite user-unfriendly). But it does not support TLSA records (!). I'm still curious why, though Route53 is giving off a vibe of being frozen in time (a long time ago).

Anyway, modern bind or knot take care of the keying part pretty much automatically (this made DNSSEC harder in the past). Just add records to the zone file, reload zone. DNSSEC signing is automatic and changes propagated to secondaries.

I agree with you that DANE is a better solution. MTA-STS adding a webserver and HTTP libraries to email as requirement is a bit much. Also, where DANE is per MX host, MTA-STS is per recipient domain, requiring a TLS certificate for each (operationally not great when you're hosting many domains). MTA-STS also relies on mail servers keeping track of historically retrieved policies, which must be refreshed in the background. And if a first connection attempt is intercepted (falsely getting told no _mta-sts DNS record exists), there is no protection. This isn't possible with DANE.

teddyhOP2y ago

Route53 infamously used to have a bug in their DNSSEC signing of wildcard records, which was the thing which made Slack try to back out of their DNSSEC rollout. (And then Slack badly botched the backing out, essentially locking themselves out of the internet for an entire day. Discussed here: <https://news.ycombinator.com/item?id=29378633>)