[xz53]

> 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.

[tptacek]

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. Either way: you don't have the NXDOMAIN problem. I really don't think there's a way to get around this. It's not dispositive of DNSSEC (other things are!), it's just not a real use case?

[xz53]

> 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.

[tptacek]

Yeah, yah. Watch the WWDC video on how the validating stub resolver in iOS works. They even call it a recursive resolver.

[xz53]

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.

[tptacek]

They literally have an animation of the client resolver making repeated requests up the tree. While saying they're making multiple requests. And calling it recursive.

[xz53]

> ...requests up the tree

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

[bingo-bongo]

Bare in mind systemd’s resolved has dnssec validation disabled by default and it’s (afaik) still marked as experimental.