not well documented yet. may try to do a ".well-known", but don't want a sprawling set of options with complex priority levels and caching behaviors.
But then again so does a whole lot of Bluesky. That is, a whole lot of Bluesky could have been designed to interoperate with the fediverse without sacrificing functionality. The choice to instead privately design something entirely different to me speaks strongly to an attitude to openness and community building that makes it a non-starter for me.
Fediverse doesn't really seem to scale at the individual server level, which is a sort of weird UX.
Creating a domain name is both cheaper and easier than running your own fediverse server.
Even if we postulate that what you say is true (I don't agree it doesn't scale, and there are increasingly commercial offerings if you don't want to run your own and there will be more, but let's put that aside), none of that stops people from using webfinger. If you want more than one user on the domain, it requires at a minimum the ability to dynamically rewrite a URL to redirect to a static URL (or you can of course have a fully dynamic endpoint), otherwise it just requires the ability to serve up a single static file.
While I kind of like using DNS myself, and might have gone that way if starting from scratch without an alternative existing, the existence of webfinger and the fact it is in use for multiple things would have made me stop and think twice and just use webfinger.
I actually serve up content using both static files and via dynamically generated content, depending on the domain and needs.
Why does the DNS approach exist at all? Couldn't users who own a hostname but have not connected it to a webserver have achieved the same by adding a CNAME to a service like Bluesky?
Maybe it helps to clarify that the concept of a handle is totally distinct from the "Personal Data Server" or PDS. You look up the PDS for a handle by resolving the DID first (via DNS TXT or HTTP fallback), then get a DID document, which has a URL to the PDS. This is a bit confusing and multiple steps, but is what makes the handles so easy to use. It is totally fine to have a cool domain to use as a handle and just not have a webserver associated with it.
If you pointed the domain with a CNAME to a particular service, you would need to update that every time you change hosting providers. Which is maybe not often, but it would be disruptive and potentially poor experience because of DNS propagation issues.
For a hypothetical brand like google.com, look up the TXT records. There are a bunch of verifications for various services. This is a relatively standard mechanism. TTL and caching are built-in to DNS, or you can punch through with a recursive query when needed.
And wouldn't changing the name server have the same effect on the DNS solution? "Every time you change your name server provider ...". Which for many users is the same as their hosting provider.
Do I assume correctly, that you don't link to the HTTP fallback documentation because you don't want people to use it?