"But BIND isn't just failing because "it's written in C", it's failing because it's written in terrible C. "
It's because it's written in C. Writing it in average Java, Go, or Ada would've prevented most of those problems because they're not allowed to do the damage by default. That's because the C language, by design and default, adds risk into common operations that doesn't have to be there. Especially today where PDP-11's no longer dominate hardware constraints. That you had to cite the DNS of an elite cryptographer and programmer to make the point supports ours that writing security-critical software in C is the first mistake. Not spending years of practice, significant time, and using available QA tools in the individual project to correctly write the C is the second.
Contrast the situation to IRONSIDES DNS where a decent, but not elite, coder wrote his DNS in SPARK Ada. It can prove absence of most errors that lead to code injection if you can express the app within its limitations. So, just by avoiding C in favor of SPARK, he gets to say it's immune to single packet DOS plus a number of code injections. Similarly, one would at least have memory-safety (50% less errors than BIND) if they used a Wirth language. Still fast & easy to code, too. BlueJekyll, who I assume is average to above average, used Rust to similarly knock out plenty of memory-safety problems.
As in Orange Book days, the language choice should be considered one of the assurance activities (or lack of assurance). Its ability to securely express the problem, be easily analyzed by verification tools, safely optimized, and securely compiled to ASM are important. The fewer risks in each the better. That C poses anywhere from a high to grand challenge across the board argues against it being a default & for its use being an explicit, security risk.