> What you ultimately want is to make sure you're communicating with the correct other party. And the way to achieve this is TLS with certificates, validated via the WebPKI.
That really only works well for web servers. If your service isn't the one found at the A/AAAA lookup for a given name it's much more difficult to obtain a cert for that name, and without that clients are reliant on what's in DNS alone to make the association.
I'm not entirely sure what scenario you're talking about, I can't think of one. If your issue is that you can't get a cert without an A record, well, set an A record. I don't see how that's a problem, except if you make it one.
WebPKI, while called that, is not just used for the web. It is used to secure e-mail servers (for IMAP+POP3 trivially, for SMTP it needs a bit more work -> MTA-STS). It also works for all kinds of more obscure things like IRC.
Most modern services are HTTPS under the hood anway, but there's really nothing stopping you from using TLS+WebPKI for other services, too.
I don't know how to put this in a more palatable way but you're looking at the world from the confines of a webdevs point of view. Can you really not imagine that there's any other protocol on the internet than HTTP? That there might already be a web server listening at a given name? That the person in control of that webserver isn't you?
Regardless of protocol, yes only one person/org should be in control of (and able to obtain certs for) a particular domain.
Unless you're suggesting Person A should have port 443 on www.something.com and Person B should have port 444, and each gets their own (valid) www.something.com cert? Because that some very clear problems.
Generally services not found directly at A/AAAA records for a name are found via another record that contains a hostname (HTTPS/SVCB, SRV, etc) at a leaf node below the name. So `_xmpps-server._tcp.example.net` might contain the hostname `hosted-provider.example.com` in which case `hosted-provider.example.com` will need to respond with a certificate for `example.net`, unless you trust the DNS, in which case it can respond as `hosted-provider.example.com`.
Well it looks like they are in this instance and neither they nor you have done anything to suggest otherwise. TLS and WebPKI have great usability for webservers but non-webservers cannot even approach being as smooth as for example Caddy's "Automatic HTTPS" configuration.
That really only works well for web servers. If your service isn't the one found at the A/AAAA lookup for a given name it's much more difficult to obtain a cert for that name, and without that clients are reliant on what's in DNS alone to make the association.