5 ms·

You can't have DNSSEC outages if no-one is validating DNSSEC. So either there are outages, but a little extra security, or no extra security, but no outages, ei

• tptacek 8y ago
  Sure you can. Virtually no part of the web PKI takes advantage (or ever will take advantage) of DNSSEC. Having DNSSEC enabled on your domain will accomplish nothing for you. But: if you misconfigure DNSSEC, or fail to maintain it, your site will vanish from the Internet for the users that make the mistake of using DNSSEC-validating resolvers. You've gained no security, but you have gained additional outages.
  • colde 8y ago
    Of course you gain security, but not in the HTTPS PKI sense. Not that long ago, somebody BGP hijacked Route 53 in order to serve up different IP's for specific domains. Had that domain been using DNSSEC, that attack would have failed for everyone using a validating resolver. That might not be a common attack, but it certainly grants security. This could also help with "rogue" free wifi setups, that try to do something like that as well.
    • the_clarence 8y ago
      Were the domains using TLS?
      • nybble41 8y ago
        Does it matter? If the attackers can redirect the domain names to their own IP addresses then they can obtain DV certificates for those domains. The security of TLS depends on secure domain name resolution.
        • tptacek 8y ago
          1. Virtually nobody signs zones today, so this is a moot point. 2. Not all DV-issuing CAs reliably verify DNSSEC, so it's even mooter. 3. Even if everyone signed their zones today, the Five Eyes intelligence agencies (NSA, ASD, GCHQ, GCSB, and CSE) have de facto (and, in some cases, de jure) control over the most important TLD zones. 4. The Web PKI already has countermeasures in place to detect misissuances, and those countermeasures have already resulted in the deaths of several of the largest CAs; there is ample evidence that current Web PKI surveillance is up to the task. 5. Even with secure DNS resolution, DV cert verification processes don't have a secure channel, and remain vulnerable to traffic interception attacks; for instance, even with DNSSEC, BGP attacks can straightforwardly trick CAs. 6. There are countermeasures to DNS spoofing that are simpler to deploy than DNSSEC, especially in the limited settings needed for DV cert verification; for instance: multi-perspective DNS and DNS over HTTPS. 7. There is already work happening to link CAs directly to registrars using RDAP to bypass DNS entirely for domain validation. In addition to being more reliable than DNSSEC, RDAP is also drastically simpler to deploy, and doesn't require anyone to sign their zones. DV certificate issuance and SMTP-TLS were the last two mainstream drivers for DNSSEC adoption. The Web PKI has worked around the problem, and, with SMTP-STS (a standard whose specific, stated rationale is to work around DNSSEC), so have the largest email providers. In fact: nothing depends on secure domain resolution, all meaningful Internet protocol security work over the last two decades has been premised on DNS being insecure, and DNSSEC is done. Stick a fork in it.
          • tialaramex 8y ago
            > Even with secure DNS resolution, DV cert verification processes don't have a secure channel, and remain vulnerable to traffic interception attacks; for instance, even with DNSSEC, BGP attacks can straightforwardly trick CAs. 3.2.2.4.7 just does DNS, so DNSSEC can secure it regardless of "traffic interception" or other shenanigans. Tightening up the Web PKI happens gradually. In 2017 we required the Ten Blessed Methods (3.2.2.4.x) to replace a previous free-for-all, and then we've whittled away those ten so that today there are only eight left, of which one is secured by DNSSEC and several are out-of-band, so shenanigans on the Internet won't help you there. I won't be surprised if it's six by late next year.
• Godel_unicode 8y ago
  Security includes availability and integrity, not just confidentiality. DNSSEC is a literal textbook case of the trade-off between C and A.