3 ms·

It COULD, depending on the standard used and level of risk. If you have a product that is publicly available/accessible and the domain is not using DNSSEC or yo

It COULD, depending on the standard used and level of risk. If you have a product that is publicly available/accessible and the domain is not using DNSSEC or you're not using TLS/SSL to protect data in transit, you're probably going to get hit. Or another thing I would look like is the controls that are implemented with the domain registrar itself (e.g., is two factor authentication enabled, principle of least privilege implemented, etc.). Scoping your information system is one of the most important and difficult parts of cybersecurity. Many would not think that implementation of controls with their domain registrar would be in scope. But if you think of the reality, something like weak authentication in use by a domain registrar or lack of protection of data at rest/in transit is potentially just as risky any other service provider/your internal boundary. This is especially true if your product is quite literally dependent on the domain name resolving properly.

tptacek 5y ago
Just a quick reminder that signing zones with DNSSEC is not in fact a security best practice; while there's little practical overlap between DNSSEC and TLS (you need TLS regardless of whether you use DNSSEC), I think it's fair to draw an "or" line between the two, since in fact that's the decision industry has made: near universal adoption of TLS, which eliminates almost the entire problem DNSSEC attempts to address. As a result, almost none of the zones managed by serious security teams are signed.
- bladegash 5y ago
  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 a quick reminder that signing zones with DNSSEC is not in fact a security best practice; while there's little practical overlap between DNSSEC and TLS (you need TLS regardless of whether you use DNSSEC), I think it's fair to draw an "or" line between the two, since in fact that's the decision industry has made: near universal adoption of TLS, which eliminates almost the entire problem DNSSEC attempts to address. As a result, almost none of the zones managed by serious security teams are signed.

bladegash 5y ago
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!