I provided the answer in my previous comment that you quoted: "use subdomains of globally resolving domains", or alternatively, just use global domain names, e.g. company.com for external services and companyprod.com for internal services. Google uses a combination of all of the above.
Domain names that only resolve internally are a security anti-pattern. You should have full authentication on all services, and not rely on simply being able to reach a service in order to grant access. See e.g. DNS rebinding as one attack vector that can really ruin your day if you don't do this.
There was a post a few days ago about a systemd resolv feature that resulted in (almost) permanently switching to the secondary DNS when the primary failed. The primary is an internal DNS resolving private domains. The secondary could be 8.8.8.8. It's easy to see what can go wrong if the private domain is somebody's else domain on the public internet. A kind of honeypot for any kind of web request.
Indeed. I wrote a Frequently Given Answer about it in 2003, years before systemd and years before the 2008 events mentioned elsewhere in this discussion. Because people were seeing exactly that.
I also wrote a Frequently Given Answer describing some more of the mistakes that people have made over and over in this, that one should learn from and not repeat.
I like the facts presented in your second link, but unfortunately the tone that it is written in means that it is unlikely to be received well by anyone it is linked to. Have you considered revising it?
Domain names that only resolve internally are a security anti-pattern. You should have full authentication on all services, and not rely on simply being able to reach a service in order to grant access. See e.g. DNS rebinding as one attack vector that can really ruin your day if you don't do this.