4 ms·

> because nobody really depends on DNSSEC That's not true. A lot of people use DNSSEC validating public resolvers like 1.1.1.1 and 8.8.8.8, especially on Andro

by rossy 8y ago

> because nobody really depends on DNSSEC That's not true. A lot of people use DNSSEC validating public resolvers like 1.1.1.1 and 8.8.8.8, especially on Android devices. I use DNSSEC on my personal domain, and when my zone-resigning cronjob fails, I notice pretty quickly, because the page really does fail to load in my browser.

dagenix 8y ago
Is that a good thing? That sounds like a pretty solid reason not to deploy DNSSEC.
- tptacek 8y ago
  It's not a good thing. To a first approximation 0% of the mainstream public Internet relies on DNSSEC, so using a DNSSEC-validating resolver will on net get you only new outages; not any additional security, even at the margin. It's a failed protocol that a subset of Linux nerds cheerlead because any classic Internet protocol + "SEC" must be cool, that companies like Cloudflare cheerlead because it's complicated and drives lock-in for them, and that governments cheerlead because it in theory grants control over all web crypto to them.
  - codebje 8y ago
    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, either.
    - 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.
    - 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.

by rossy 8y ago

dagenix 8y ago

Is that a good thing? That sounds like a pretty solid reason not to deploy DNSSEC.

tptacek 8y ago
It's not a good thing. To a first approximation 0% of the mainstream public Internet relies on DNSSEC, so using a DNSSEC-validating resolver will on net get you only new outages; not any additional security, even at the margin. It's a failed protocol that a subset of Linux nerds cheerlead because any classic Internet protocol + "SEC" must be cool, that companies like Cloudflare cheerlead because it's complicated and drives lock-in for them, and that governments cheerlead because it in theory grants control over all web crypto to them.
- codebje 8y ago
  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, either.
  - 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.
  - 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.