3 ms·

Hah, that is a great point and unfortunately, there are and will likely always be security control requirements that are no longer considered best practices. F

Hah, that is a great point and unfortunately, there are and will likely always be security control requirements that are no longer considered best practices. For example, it was fairly recent that NIST updated its guidance on requiring changing of passwords at a defined frequency. In the case of DNSSEC, it is potentially a relevant and required control under, for example, NIST 800-53, revision 5.1, SC-21 [1]. That's why I mentioned that depending on the standard, it COULD be a requirement. [1] https://csrc.nist.gov/Projects/risk-management/sp800-53-controls/release-search#!/control?version=5.1&number=SC-21 https://csrc.nist.gov/Projects/risk-management/sp800-53-cont... Edit: It is also still offered as a potential (arguably secure) practice under NIST SP 800-81-2.

tptacek 5y ago
Just for additional context: until around 2016, there was a FedRAMP requirement that services be run on DNSSEC-signed zones. They rescinded that requirement --- they tried mandating DNSSEC and decided, you know what? nah. Two other big industry-wide things that happened vis a vis DNSSEC: 1. All the mail providers banded together and came up with an alternate SMTP transport security standard, MTA-STS, that says explicitly that it exists because nobody wants to deploy DNSSEC. 2. The DNSSEC people and the browser/TLS people got together and proposed a DNSSEC stapling mechanism as a TLS extension. That stapling --- which Geoff Huston once wrote was an existentially important feature for DNSSEC, since DNSSEC queries routinely fail when made behind random CPE equipment that won't forward weird-looking DNS messages --- failed and was withdrawn. There are basically no positive signals with respect to DNSSEC deployment. We're belaboring it; your comment isn't really about DNSSEC. I'm just saying: even if you're very, very diligent about security, it's unlikely that DNSSEC would be a high priority item. :)
- bladegash 5y ago
  Hah, you are definitely right and I agree with you there =). Thanks for the comment and have a great deal of respect for you!

tptacek 5y ago

Just for additional context: until around 2016, there was a FedRAMP requirement that services be run on DNSSEC-signed zones. They rescinded that requirement --- they tried mandating DNSSEC and decided, you know what? nah. Two other big industry-wide things that happened vis a vis DNSSEC: 1. All the mail providers banded together and came up with an alternate SMTP transport security standard, MTA-STS, that says explicitly that it exists because nobody wants to deploy DNSSEC. 2. The DNSSEC people and the browser/TLS people got together and proposed a DNSSEC stapling mechanism as a TLS extension. That stapling --- which Geoff Huston once wrote was an existentially important feature for DNSSEC, since DNSSEC queries routinely fail when made behind random CPE equipment that won't forward weird-looking DNS messages --- failed and was withdrawn. There are basically no positive signals with respect to DNSSEC deployment. We're belaboring it; your comment isn't really about DNSSEC. I'm just saying: even if you're very, very diligent about security, it's unlikely that DNSSEC would be a high priority item. :)

bladegash 5y ago
Hah, you are definitely right and I agree with you there =). Thanks for the comment and have a great deal of respect for you!