As the title says.
The design of DNSSEC and its implementation in Bind (and things like Unbound) quite clearly allow for either use. They can optionally do DNSSEC validation, returning SERVFAIL if the validation fails. Or alternatively they can be set to "support" DNSSEC but not to do the actual validation, allowing client software to use the "DO" bit (with EDNS) to request the DNSSEC records and do validation itself.
Notably, Google's own public DNS servers seem to follow the latter, allowing DNSSEC requests to pass through them but not doing DNSSEC validation themselves.
Which of these two ways was DNSSEC envisioned to be run? If you want context, imagine you have a few small web application servers and a caching recursive DNS server for them to do DNS requests through.
I don't know about "envisioned"; probably time will tell what works best.
But if you already have a caching server, I'l let that do the verification. The main reason: you then have one place where you can log verification failures (and maybe, if necessary, configure exceptions – when a site you have to reach has broken DNSSEC records).
Doing that on a multitude of clients doesn't scale.