|
|
|
|
|
|
by teddyh
941 days ago
|
|
|
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. |
|
|
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.