On top of schnapsidee’s already correct feedback, if the company is willing to enforce documentation deliverables (which it really should), I’ve found it important to have a minimal documentation deliverable formulated. Don’t immediately overshoot with all the different types and subjects, but find a set of documentation aspects that are agreeable by the company at large as a minimum. You can always increase this later, but it’s hard to set the bar too high immediately as that removes any willingness from the organization as well.
You also can’t just ‘reset’ the organization and suddenly do things in a different way. It will need to be evolved into a better documentation structure. Perhaps you could start with just a portal that points to the various existing documentation libraries and services. That can help you identify what types of documentation you have, and perhaps even find a good grouping. Also, try to see what information should be protected (don’t want to have passwords laying around, or other risky information) versus which information should be easily accessible.
How heavy is the DNS used for changes (records added/removed)? Do you have DNSSEC active? Does the DNS server also act as a caching DNS (given that you mention it as an external DNS, I suppose not)? These things can influence the specs of the server.
I would imagine that, for common use cases, low specs are fine, but as this is an external facing DNS server you probably cannot be certain that more interaction won’t happen. If too lightweight, a lightweight DDoS might be sufficient to bring it down, which majorly impacts your service. So I wouldn’t go below 2core, 4Gb.
But personally, I don’t recommend hosting your own DNS. DNS is a brittle service the moment you want to do more than just exposing a single zone, and the complete DNS architecture shouldn’t rest on a single service. There are dedicated DNS service providers out there that work very well, and can be programmatically configured (API).