I recommend building one of your own rather than sharing one.
You can run a non-logging DNS service (a recursive caching resolver) on the same system as the Tor node, or on another system netwise nearby. This can provide good safety and performance.
As you note, other DNS services can and often will log DNS queries, engage in typo-squating/hijacking, or be forced to censor and redirect names. Further than that, any central service used by many Tor nodes (and/or other users) allows an adversary to catch many users with a single operation to require/inject censorship or redirection.
In contrast, I can better ensure that a local DNS service will provide rational "straight up" DNS. I can make it start from the roots, avoid logging of any queries, and skip implementing any hint of typo-squatting on NXDOMAIN responses.
Further, controlling the upstream net or using courts to force many such local services to censor or redirect a name scales poorly, and is thus a greater work factor for an adversary, than is doing the same attack on a shared and widely used DNS service.
For my local recursive caching DNS resolver, I presently use unbound. Unbound is maintained by NLnet Labs, and is now the default system resolver in FreeBSD 10 among other OSes. BIND also works OK for this purpose; I used it previously but now prefer unbound's relative lack of complexity in code and design.
In either case, you will want to take care to not produce a promiscuous resolver and dDoS attack amplifier. Restrict the allowed DNS client list to your Tor node(s) and fellow travelers. One potential bonus: If you run IDSes that need to do their own lookups, have them use this resolver, and exempt this resolver from being watched by the IDSes (that's good citizenship for Tor). That way, the IDS' own lookups won't trigger IDS alerts which cause lookups which trigger IDS alerts which...