There are also potential downsides (like someone being able to enumerate your subdomains, if you care about such a thing) and it's often switched off by default on operating systems consumers use.

However, it's the only thing that validates DNS records at this moment. That alone makes it worth enabling, in my opinion. For many domain owners, you only need to tick the checkbox in your registrar's domain control pane. If you use a modern DNS server, it's also one config flag and maybe copy/pasting a handful of fields away.

I'll gladly turn off DNSSEC the moment we come up with something better. DoT/DoH doesn't solve the same problem and no real solutions seem to have been proposed. That said, modernisation efforts are still being done. Smaller keys and modern cryptography rather than the massive RSA ones for instance.

General DNSSEC rationale: <https://www.icann.org/resources/pages/dnssec-what-is-it-why-...>

DNSSEC adoption graph: <https://www.verisign.com/resources/dnssec-tools/dnssec-score...>

Out of curiosity I enabled DNSSEC checking beginning this year. I mostly noted nothing in my browsing. However, with 2 services I noted obscure problems that worked only partially. Some Jira plugins and Swedish railway SJ. I needed to excempt some of their domains from being checked to use their services. Of course you waste a couple of hours every time it happens because you don't think of DNSEC first when some web-based services behaves weirdly. There might be more requests not served to my browser, but I just never noticed or bothered to debug.

So not fit for general use. And even as an experienced developer it's not easy to understand why an exception would be needed. A bug in systemd? Incorrect data in DNS? A real attack?

Edit: I don't use standard DNS on port 53 at all. Blocked outgoing requests on that port. Everything DoH or DoT. Of course I need to trust those endpoints at least in repect to confidentiality. And most domains are unsigned. At least for those unsigned ones I need to just trust also in respect to integrity.

You can run a DNSSEC-aware resolver like unbound on your laptop if you wanted to. It comes with a bunch of Linux distros.

  As noted above, DNS forgery attacks against the ACME server can
  result in the server making incorrect decisions about domain control
  and thus mis-issuing certificates.  Servers SHOULD perform DNS
  queries over TCP, which provides better resistance to some forgery
  attacks than DNS over UDP.
    
    An ACME-based CA will often need to make DNS queries, e.g., to [1]
  validate control of DNS names.  Because the security of such
  validations ultimately depends on the authenticity of DNS data, every
  possible precaution should be taken to secure DNS queries done by the
  CA. Therefore, it is RECOMMENDED that ACME-based CAs make all DNS
  queries via DNSSEC-validating stub or recursive resolvers.  This
  provides additional protection to domains that choose to make use of
  DNSSEC.
  
  An ACME-based CA must only use a resolver if it trusts the resolver
  and every component of the network route by which it is accessed.
  Therefore, it is RECOMMENDED that ACME-based CAs operate their own
  DNSSEC-validating resolvers within their trusted network and use
  these resolvers both for CAA record lookups and all record lookups in
  furtherance of a challenge scheme (A, AAAA, TXT, etc.).
  
  

<https://www.icann.org/en/engagement-calendar/details/icann-t...>

> domain-validated certificates remain insecure

...99% of the internet runs on DV certificates; that's what ACME & Let's Encrypt are at the end of the day.

(You might also note I didn't actually speak in favor of DNSsec, I'm just arguing that running unbound locally without having DNSsec validation enabled isn't particularly useful. I am, generally, in favor of rolling out DNSsec, but it certainly has its problems. It doesn't help against ISP tampering on unsecured domains, for example. DoT and DoH are better against that, if [and only if] you have a trustworthy cache to point them at.)