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

[tptacek]

I give up. You win. DNSSEC is the perfect solution for forged NXDOMAIN responses.