Before we go further, can you walk me through the reasons (if you had thought of it of course) why you didn't use something like libunbound?
There are side effects of adding DNSSEC client support (with our own implementation) that we, people maintaining tor, have to become DNSSEC expert in some ways just to be able to understand what is happening in that code, fix issues but also possibly implement new features if any. That is where a third part library like unbound becomes very nice because they are the experts at providing such features.
Of course, everytime we have to link to an external library we do it carefully and with considerations because of the "yet another attack" vector problem. But adding that much code to support a well known feature like DNSSEC also has huge implications for tor maintainability and security.
Finally, something I noticed and made me itch a bit. You hardcoded a lot of .onions where one appears to be Cloudflare (?) resolver. What are the other addresses? I worry here because default options are always the one used the most so I'm concerned here about shipping hardcoded addresses _within_ our C code.
+1 for "don't roll your own DNS(SEC) implementation". There are people that do DNS(SEC) for years, should the torproject really implement and maintain its own custom DNS stub resolver and DNSSEC validator?
Also consider that DNS is moving towards DNS encryption protocols (DoT and DoH) and firefox has DoH support that could be made stream isolation aware. Using open protocols will increase the availability of multiple public resolvers speaking that protocol.