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.
They never have. Fewer than 5% of North American domains are signed, and over some of the last few years, the number has gone down.
https://dnssecmenot.fly.dev/
Almost nobody has DNSSEC enabled.
Against DNSSEC: https://sockpuppet.org/blog/2015/01/15/against-dnssec/
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.
I have it enabled for an ssh interface for managing linux vms: https://shellbox.dev
Even supports post quantum encryption :)
In the FAQ of this article it says:
> 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"?
Virtually none of the most important sites on the Internet are signed. When's the last time one was maliciously misissued?
Fair point.
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.