Hacker News Reader

Hacker News

Comment by ancarda | Hacker News Reader

Full thread

ancarda

I have a DNSSEC signed zone, do I need to do anything? Like generate a new key using this new root key?

View on HN

No, this only impacts configuration on the validation side, not signing.

Clients need to update their root keystore, but zones need no change.

No, because nobody really depends on DNSSEC, so nothing will break:

- https://ianix.com/pub/dnssec-outages.html

- https://twitter.com/tqbf/status/772103926258671618

> 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.

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

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.

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.

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.

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.

Were the domains using TLS?

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.

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.

> 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.

Security includes availability and integrity, not just confidentiality.

DNSSEC is a literal textbook case of the trade-off between C and A.

Reply on news.ycombinator.com