I can see how this would work on a technical level but what's the intended use case?
replies(13):
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.
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...
I've been doing that for years on onprem (~60% old "enterprise/legacy" ~40% modern stuff) and never seen anything that doesn't support it. YMMV, but if all I work with supports it, I won't complain in vain.
> those parts are going to choke if you just blindly go and stick IP addresses in https:// URLs.
I did many times, seems that legacy heavens were always kind to me in this regard.
> something you're going to want to change all the time, like an IP address
That's a personal assumption as well. If your architectures change IPs all the time, OK. Ones I worked with didn't. Always had plenty of components with IPs that didn't changed in a decade or two. Even my two previous local ISPs I had gave me "dynamic public IP" and kept them for many years. For some companies changing an ip of their main firewalls/load balancers or VPN servers is unthinkable.
Even on my last project on Public Cloud, the first thing I did was to make sure public IPs won't be dynamic (will survive recreation of services) so I don't have to deal with consequences of my corporate client endpoints and proxies flushing DNS caches randomly. (don't ask me why, but even huge companies still use proxies on a large scale. Good luck with figuring out when such proxy invalidates your DNS record).
> in the IPv4 space
IPv6 is here. Your printer and light bulb will want a cert as well.
Its a mesh routing network where your identity is your public key and your ipv6 address is derived from the hash of your public key.
Works perfectly