Blueskyでは、アカウントを識別するためのいわゆるhandleとして、DNSでいうところのFQDNを使う、という流儀になっており、特に何もしなければname.bsky.socialみたいにbsky.socialドメインを使えるようになっています。ただ、自身で別に設定すればこの限りではなく、極論すればなんでも付けられます。詳細は以下を参照してください。
How to set your domain as your handle
自身で制御可能なFQDNをBlueskyのhandleとして使いたい場合、設定方法が2つあります（以下「handle.domain.comをBlueskyのhandleとして使いたい」という前提で書きます）。
どっちかを実行すればよいので、やり易い方でやればいいわけですが…設定するhandleが1つだけで、https://handle.domain.com/というWebサイトがなければ、たぶん前者が楽なのはいうまでもありません。https://handle.domain.com/というWebサイトがすでにあるなら、ないし、簡単に仕立てられるなら後者も悪くありません。この辺はNostrと事情が同じ、といえばそうかなと思います（が、Nostrの話をしたいわけではないので略）。
今ここでは、上記のような格好で複数の（read: 1つじゃなくてたくさんの）handleを単一ドメインで設定する場合を想定します。同じ会社の社員だったり、同じサークルのメンバーだったりなど、サブドメインで個人を識別可能＆同じドメインを共有して同一組織であることを示す、みたいな状況です。で、前出の文書ではこういう場合を想定して、こんなことが書かれています。
Organizations like newsrooms or companies may want to verify multiple affiliated individuals' accounts via subdomains. For example, a newsroom could set its journalists' handles to be @name.newsroom.com. But managing many individual subdomains via TXT records can be cumbersome. In that case, you can use a non-DNS option by resolving multiple handles via HTTP under a .well-known route.
つまり、そんな状況ならnon-DNS option、上記でいう後者の方法でよろしく、というています。たしかにそれはそうかなと思うわけですが、これはこれで話が厄介です。
数分考えた結果、これCloudflareのinfrastructure使っていいならできるんじゃないの？と思ってやってみたらうまくいきそうだったので、記録を残しておきます。
Cloudflareおんぶにだっこを前提にします。具体的には以下の通りです。前出の前提、「handle.domain.comをBlueskyのhandleとして使いたい」はそのまま使います。
Cloudflare Pages documentation · Cloudflare Pages docs
後で考え直したらCloudflare Pagesでなければならない必要性はそんなに高くないのかもしれませんが、とりあえずこのまま。