Your language and line of questioning leads me to assume that you're perhaps not that familiar with Erlang.
Erlang has facilities for running native code within the VM (NIFs and linked-in drivers) and for interacting with non-Erlang processes in an Erlang like way (ports and c-nodes). Extending the VM via these mechanisms is not the default path but it's also not unusual - much of the standard lib is implemented via these mechanisms after all.
To answer your question, bitcask, ebloom, eleveldb, erlang_js and skerl all have c_src directories which suggests they're likely either all or in part implemented via NIFs or linked-in drivers.
I let it cache a record, disabled the zone the record came from and left it to expire. It did. I won't deny that it could behave differently from different addresses, but based on the evidence available I'm sure you can understand why I remain unconvinced.
Please provide further detail on these '"big" recursive resolvers' that ignore TTLs. I'm yet to see one in the wild and so I'm somewhat dubious of the claim.
(Please don't be vague - post the addresses of the resolvers in question.)
Erlang has facilities for running native code within the VM (NIFs and linked-in drivers) and for interacting with non-Erlang processes in an Erlang like way (ports and c-nodes). Extending the VM via these mechanisms is not the default path but it's also not unusual - much of the standard lib is implemented via these mechanisms after all.
To answer your question, bitcask, ebloom, eleveldb, erlang_js and skerl all have c_src directories which suggests they're likely either all or in part implemented via NIFs or linked-in drivers.
EDIT: You might also find http://vimeo.com/17078993 interesting viewing.