In other cases dns is just not needed at all. You might prefer simplicity, independence from dns propagation, so you will have your, say, Cockpit exposed instantly on a test env.
Only our imagination limits us here.
There's no reason AT ALL to bring IP addresses into the mix.
Elaborate, please.
> There's no reason AT ALL to bring IP addresses into the mix.
Not sure what scenario you are talking about, but IPs are kind of hard to avoid. DNS is trivial to avoid - you can simply not set it up.
"bringing IPs into the mix" is literally the only possible option.
> Elaborate, please.
Identify a service directly by its crypto key. When you configure something else to connect to it, treat the IP address as a hint, not the primary identifier for what it's talking to. Standard idiom.
... and before you tell me that that's infeasible because you'd have to modify software, go do a survey of all the code out there, and see how much of it supports IP address certificates. If you're moving around the parts of some big complex system, it's pretty much guaranteed that many of those parts are going to choke if you just blindly go and stick IP addresses in https:// URLs.
And if you're fixing the software anyway, then it's not sane to "fix" it to attach identity to something you're going to want to change all the time, like an IP address. Especially if they're global addresses (which are the only ones any Let's Encrypt or any other public CA is ever going to certify) in the IPv4 space (which is the only one any "enterprise" ever seems willing to use).
[1] https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1....
[2] https://cabforum.org/working-groups/server/baseline-requirem...