i consider it inconvenient to change a host file on a large qty of hosts, but not a genuine issue. i would consider it a real issue that a critical layer 3 service can fail and latch itself into an unrecoverable scenario because, there was a cyclic dns dependency. hosts files have their place, particulary in layer 3 network operation where we might not be able to assume a dns service works yet.
i am searching for genuine rationale to prohibit by policy the use of reserved private ip network segment addresses.
i see no technical issue with using public dns names to resolve ip address for internal-to-internal use. often in this rare scenario, it's maybe equivalent or less work to use a split dns zone. (using a hosts fine is logically equivalent to a separate dnz zone imo). so i think if you are considering public dns private address, consider if you have a greater topology issue and make sure you're changes work towards resolving that topology.
i do see a vanity problem, that being, there will be countless other networks where the public name in question will accidentally (to the advantage of an attacker) route to resources an attacker controls.
the vanity problem being, my dns name can be shown a user while the communication goes to a server i don't control. in this circumstance, protocol dependant things can happen. in http land, the use of hsts and keeping a tls private key secret should provide sufficient vanity, but until browsers decide to consider all webpages served from private networks to be "insecure", there will be the vanity question in http. other protocols, particularly where there is no proof of authenticity like public trust tls (like https), private trust tls (like ssh), or mutual tls (like openvpn), use of public dns that resolves to private dns may bear vanity issues.
some hardware vendors intentionally operate addresses like this, or at least i thought so "routerlogin dot net" may have previously but doesn't now, at least not from where I'm located, or the manufacturer might park that as a black hole address and rely on mitm for either your routing or dns (eg split dns)resolution to implement a user friendly router setup page.
I've had a security firm complain about private dns records for being in spam db's, which kind of makes sense if the spam list is for lazy email operators, but we should also universally agree to not deliver or accept email from a private ip address, especially without proof of authenticity and authentication-- which makes that complaint not make sense to me in the vanity sense.
when i say split dns, I'm specifically referring to operating 2 or more dns zones that claim to be the authority for a name but serve different addresses, eg. a public and private zone for example dot com that resolve as a public or private address respectively.
i think there are technical problems with the use of split zone dns (aka private dns). particularly when any os, or later 3 technology (like a vpn) vendor is involved because at the end of the day, the os's network stack programmer or later 3 operator has more control over your bare dns resolution than you do. in particular, some operating systems use multi cast dns where the fastest dns response is considered authoritative, and i bet you, your private dns server over a vpn will be slower than the isp'a dns cache or resolver, it's simply closer to the end user in hops. this means that is you have a dns name resolve to a public or a private ip address -by circumstance of what network- -in theory- it's supposed to be resolving dns via-- i think you're likely to be a painful situation.
because of this, i prefer to never have one dns record have more than one authoritative answer no matter what it's network topology is.
for me, that means, end users (read as "developers i support") tend to have to deliberately choose if they want to resolve a private address or a public address by choosing between two distinct dns names to use.
for their services/applications, but also for their webapps when and where their webapps may be accessible over both private and public networks because of a vpn.
i dislike selectively choosing the routing via dns. ip is meant to be resilient to network failures and this won't be. what would be? to be more "ip" like, would be: to have a canonical ip address (which to be canonical cannot be a private network address), and inject a (/32) route for these addresses that sends packes to a router i control that will repeat this process until the communication reaches my host over a private network such an a vpn+lan without having routed over a public network unless the vpn was off. --for people whom consider managing a few hosts file too burdensome, i suspect managing a route table like this would be much farther from ease. unless you happen to be on ipv6 or are one of the old guard who own class A or class B sized public ip block.
side note, i totally disagree with the use of nat as a defacto "part of the defensive network topology". i e this used where normally there is a handful of public address and a lot of port address translation (especially in docker heavy systems).
accidentally configuring a firewall to be "default reject" via of an implementation detail of the isp that accidentally means your isp happens to not currently route any traffic destine to the lan of the firewall-- i think everyone would agree that is a very poor defense strategy, however it is the default one i see everywhere. it's so pervasive that as part of the ipv6 adoption curve, network operators have been confused and demanded technical support for NAT on ipv6 where there is almost zero region other than cargo culting to imminent it, and if you do imminent it, there is a good chance you literally don't have enough ram to build the network mask tables that NAT requires to function, meaning ipv6 nat incurs some strange dynamic characteristics that, i think 20 years ago, would have been seen as a completely irresponsible and risky kind of software to put on a firewall where every assertion needs to be correct the first time and hardened against abuse.
in general, i think the assertion that all public dns records that you own should resolve to hosts you control is a good baseline. and also made perfect sense when you could realistically own more ip addresses than you had cause to need. even now if you have to use private dns i encourage you to host split public dns with a known safe black hole address to resolve such that no network change by friendly or other operators can substantially change your deployment.
i think the fear to disclose private networks addresses and segments is silly any baseless. any attacker already knows which private networks segments you own and operate, the list is small enough to be memorized. it would be more surprising to find out that an operator doesn't use a private network, akin to finding out an operator doesn't use tcp/ip or doesn't use osi.
i don't see any issue with obscure dns names that are publicly resolvable to private network addresses. obscure dns names that, have no chance of brute force discovery, have no chance that a user could devine to intentionally type manually into an address bar. virtually ever dns zone is operated with zone transfers disabled, meaning they are opaque unless you happen to know the exact dns name before resolving. (with zone transfer enabled, anyone can list all your dns records rather than guessing and check)
is because there is a shortage of public ipv4 IP addresses and there are economic factors that force me to occasionally work with less than i need. prolific adoption and use of ipv6 would eliminate by needs for ever using private dns, but ipv6 is very often not deployed because there is cost in the hardware, software, and operational staffing.
final note, sometimes I'm forced to use dns names by middleware, like certain cloud provider's load balancers only work of you can forever use public dns resolution to a resolver controlled by the cloud provider, even when using private address space.
i don't have a dictatorial answer here, just some ideas that i didn't see else where in this thread.
"certainly don't if the audience is people, people will make mistakes", "probably don't if you have any other realistic options", "if you have to, it's fine , be careful, and be informed, like anything we do online".