I was the lead architect and backend engineer for a migration from my company's legacy two-server Tiny(DJB) DNS implementation to a 4-server geo-redundant DNS based on PowerDNS that uses a multi-master (using Tungsten) replicated MySQL backend in about a weeks work including testing the migrated data off the public access. We intended to use it for generating and provisioning new records for our mass email application, but it was a feature that never got priority during the development lifecycle of that app. We use the poweradmin web code (https://github.com/poweradmin/poweradmin) to provide a management front-end and dictate ACLs. While we have internally created and assigned tenant relationships to most of the parent zones, we don't actually give our customers direct access to edit their zone (we're an MSP and a lot of our customers would break things because they don't understand DNS). There are some zones that did not have adequate notes and documentation during migration similar in practice to half the 41431 records you mentioned not having a discernible owner, and we assigned those records directly to our "support staff" tenant -- in our practice on AMPRNet this could potentially be delegated to all of the coordinators.
Moving to something like this would enable portal code to speak directly to the DNS database backend (potentially eliminating the need to modify the robot to handle the newer type requests) adding redundancy (and self-healing) to DNS. PowerDNS also supports mrtg/rrd output so reporting could be established on some kind of status monitoring page as part of the portal. I wouldn't mind helping with a deployment of a similar model for the ARDC related zones, if there is interest and available development support.
I just mind-vomited everything I typed above and I'm not sure how much of what pieces of a solution in my head actually transcribed to an actionable RFC that could be understood by the mailing list. I'll check back in on this thread later this evening.