xz53

PowerDNS got caught out too: https://blog.powerdns.com/2024/02/13/powerdns-recursor-4-8-6...

...requests up the tree

That's right, it's not recursively working its way down from the root because it's a stub resolver.

RFC 8499:

   Stub resolver:  A resolver that cannot perform all resolution itself.
      Stub resolvers generally depend on a recursive resolver to
      undertake the actual resolution function.

DNSSEC evaluates answers as being one of secure, insecure, or bogus. Secure means there's proof the answer is correct going all the way back to the root. Insecure means at some point there was a delegation that either opts out, or requires use of an unknown signature algorithm or unsupported NSEC3 parameters (unknown/unsupported by the validating software). Bogus means there was no proofs or the proofs didn't check out.

Of course there's not much point to that evaluation if you're only looking up IP addresses and then relying on WebPKI to see that the other end is what you expected it to be.

EDIT:

I'm not allowed to reply for some reason, so in answer to tptacek:

Right, which leaves open the question of what the point is.

No, I don't think it does. I think my summary reasonably conveys the functionality DNSSEC offers and how it is practically useful. (This is not a flippant response, the spade is a spade.)

A validating stub resolver is effectively a recursive resolver proxying through another recursor. At the point where you're going to do that, you might as well just run a recursive server.

Every iPhone on the planet might as well be a recursive resolver? Yeah, nah.

In a nutshell, the vulnerability is stuffing a lot of broken signatures from different keys in a response so the validator wastes a bunch of time retrieving keys and then validating signatures that'll never validate. The fixes just limit the amount of time before validators yield to another task and/or give up. It's a big deal if you run a public resolver but otherwise you can probably fix it at your leisure.

The core problem with DNSSEC adoption has always been what happens when your ZSK/KSK expires, which it ought to for the same reason SSL certs expire.

For most users there's really no reason for a ZSK/KSK split or rolling keys, much the same as there's no need for rolling SSH keys for most users.

If you're not recursing, you're not really validating DNSSEC records.

Nope, validating in stubs is a thing. systemd's resolved does it. Apple's high-level network frameworks do it if you ask as of a couple of years ago (they've been back and forth on DNSSEC in their lower level API for longer than that). I'm not sure how well they work but they're there.

Ever since enabling DNSSEC validation on my system, YouTube and every other Google product except basic searching is broken for me.

Enabling DNSSEC wouldn't change resolution of those properties unless you somehow set your system to treat insecure delegations as bogus. Is that what you've done?