This whole NRPT thing sounds like a way to bring DNSSEC somewhat in line with DNSCurve, except that instead of having a single standard and spec like it is the case with DNSCurve itself, they're simply throwing up a bunch of unrelated ones together into a big administration and configuration mess.
Deploying DNSSEC for recursive and authoritative servers are two completely different tasks.
What exactly are you trying to accomplish? In the Linux and BSD world, if you simply want to ensure that DNSSEC verification/validation is taking place, best way to go about it is to run your own local recursive or caching resolver. For some details of how it's done, take a look at the recent changes that were made to the upcoming FreeBSD 10, where they've introduced unbound to base tree, which, when used correctly (e.g. if it's set as the only available resolver), is not supposed to resolve any domain names which have DNSSEC enabled, but have records that are not signed correctly, but which were supposed to have been signed.
As far as authoritative servers go, if you want some extra security and privacy, your best bet is to run DNSCurve as a front-end, and possibly still have DNSSEC in the backend, if needed.
I guess for recursive DNS, you'd be doing exactly the same thing, but the other way around: maybe configure a local unbound to be a caching/verification resolver, which would issue all of its queries through a local DNSCurve-aware recursive resolver, but never otherwise.
However, in both of the above examples, I think you're pretty much stepping into an uncharted territory.
