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.

	▲	tptacek 2 hours ago \| parent [-]
		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.

▲

messh 2 hours ago | parent | prev | next [-]

I have it enabled for an ssh interface for managing linux vms: https://shellbox.dev

Even supports post quantum encryption :)

▲

moquilabs 2 hours ago | parent | prev [-]

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"?

▲

tptacek 2 hours ago | parent [-]

Virtually none of the most important sites on the Internet are signed. When's the last time one was maliciously misissued?

▲

moquilabs an hour ago | parent [-]

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.

	▲	tptacek an hour ago \| parent [-]
		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.