That article kicks off with a politically motivated "issue" which seems pointed at the US Govt (USG) before dealing with perceived architectural issues.
The thing about trust anchors is that they are trust anchors and not a back door. DNSSEC goes well out of its way too, to not screw up things as far as possible if something is missing. OK, client implementations do that (I haven't gone into the RFCs in too much detail).
The architectural issues alluded to seem pretty handwavy too. I deployed a slack handful of PowerDNS boxes and adding DNSSEC is basically two CLI invocations per domain and passing on the DS records to upstream. The second invocation is to add an adjustment to deal with NXDOMAIN better (can't remember the exact thing at the moment)
If it doesn't work for you then fine - don't use it!
I find it useful and thanks to a decent implementation (so far) it is trivial to implement. However, I'm going to need to get my thinking cap on for some split-horizon domains.
It doesn't work for most sites, which is why so few organizations use it. It's awfully hard to make an argument about how straightforward DNSSEC is to use after DNSSEC had to be disabled by Cloudflare and Quad9 for all of Germany because of a misconfiguration. And it's more or less impossible to take seriously as a security boundary after that. Real security protocols fail closed.
1. Browsers briefly tried adopting DANE and gave up on it.
2. DNS is the wrong level of networking abstraction to do this kind of policy enforcement at, because DNS isn't plumbed for warnings and error reporting; when DNSSEC fails, whole zones simply fall of the Internet (for people who validate) as if they weren't there at all. It's the worst possible failure mode.
3. The thing you say you want can't be had with DNSSEC. You don't get "the whole chain from ICANN to your server". Any of the parent zone operators above you can decide to defect, for your zone specifically, and (particularly for state-level adversaries) for particular targets resolving your zones, without you ever knowing about it.
https://dnssecmenot.fly.dev/
Against DNSSEC: https://sockpuppet.org/blog/2015/01/15/against-dnssec/
The thing about trust anchors is that they are trust anchors and not a back door. DNSSEC goes well out of its way too, to not screw up things as far as possible if something is missing. OK, client implementations do that (I haven't gone into the RFCs in too much detail).
The architectural issues alluded to seem pretty handwavy too. I deployed a slack handful of PowerDNS boxes and adding DNSSEC is basically two CLI invocations per domain and passing on the DS records to upstream. The second invocation is to add an adjustment to deal with NXDOMAIN better (can't remember the exact thing at the moment)
If it doesn't work for you then fine - don't use it!
I find it useful and thanks to a decent implementation (so far) it is trivial to implement. However, I'm going to need to get my thinking cap on for some split-horizon domains.
Even supports post quantum encryption :)
> What’s the alternative to DNSSEC? > Do nothing. The DNS does not urgently need to be secured.
> All effective security on the Internet assumes that DNS lookups are unsafe.
This is not true, our entire infrastructure of ACME certificate authorities like let's encrypt are fundamentally dependent on DNS: https://letsencrypt.org/how-it-works/#domain-validation
Then TLS verifies the domain with the private key the certificate authority issues...
How can you trust the s (secure) in https then??
Can anyone provide an example of "effective security on the Internet"?
I'm just looking for a way to cryptographically prove that my website is from me in a way that browsers will accept.
This means the whole chain from ICANN -> Verisign -> registrar -> dns -> IP -> my server.
2. DNS is the wrong level of networking abstraction to do this kind of policy enforcement at, because DNS isn't plumbed for warnings and error reporting; when DNSSEC fails, whole zones simply fall of the Internet (for people who validate) as if they weren't there at all. It's the worst possible failure mode.
3. The thing you say you want can't be had with DNSSEC. You don't get "the whole chain from ICANN to your server". Any of the parent zone operators above you can decide to defect, for your zone specifically, and (particularly for state-level adversaries) for particular targets resolving your zones, without you ever knowing about it.