Guidance on multi-level subdomain handles? #1697
Replies: 5 comments 9 replies
-
|
I guess another partial option could be a wildcard multi-domain cert, where I'd include the top 100 fediverse instance TLDs, eg:
This would only support full domain instances though, not subdomains like |
Beta Was this translation helpful? Give feedback.
-
|
Looking at Route 53 and Google Cloud DNS, they charge primarily by zones and queries, which seems reasonable, since I wouldn't need a zone per user or instance. Both have initial quotas of 10k records per zone. Pricing is pretty similar across at least Route 53 and GCP. So this approach should cost < $1/mo, at least up to the first 10k users. After that, I guess I'd split into per-TLD zones? |
Beta Was this translation helpful? Give feedback.
-
|
To close the loop here, I implemented this with GCP DNS, and it's working fine. It's now serving the whole Not ideal, I'll absolutely hit the 10k records limit soon enoough. Dunno what I'll do then. |
Beta Was this translation helpful? Give feedback.
-
|
A side note even if likely moot now: |
Beta Was this translation helpful? Give feedback.
-
|
This does seem annoyingly difficult. If I was doing this myself, i'd probably try to put together a dynamic DNS resolver service and do handle resolution that way. Would be backed by a database, probably would not even put a cache in front of it as that would make changes slower and harder to debug. At a very small scale, you could try using auto-certs, eg with Caddy. This will attempt to do the Let's Encrypt validation on the first HTTPS request. You might hit Let's Encrypt rate limits pretty quickly though. |
Beta Was this translation helpful? Give feedback.
-
|
Did something similar recently with Caddy: https://github.com/bluesky-social/indigo/blob/e84671a714d9c33fa19d724674843974fe894698/cmd/athome/README.md |
Beta Was this translation helpful? Give feedback.
-
|
Coming back to this now that Bridgy Fed is getting more attention. Already at >400 DNS records for handles, and it's just getting started. 😳 @bnewbold here's a maybe radical idea: would you all ever consider extending HTTPS-based handle validation to serve on a higher level domain than the exact handle? For example, if the handle a.b.c.com has no CNAME or A or AAAA records, but c.com does, you could fetch https://c.com/.well-known/atproto-did with maybe a custom HTTP request header - say, Adds complexity, I know, and maybe scaling questions, and would require the |
Beta Was this translation helpful? Give feedback.
-
|
My initial reaction is that we really don't want to add additional handle resolution variations, which result in additional required network round-trips for non-existent handles. There are a a lot of handles in the network, and it feels important that handle resolution remain fast/efficient/reliable in the long-run (eg, we care a lot about the p99 of handle resolution at scale). That being said, handle resolution isn't currently a burning problem for us, and we do want to be flexible and ensure that things like bridgy fed are relatively easy to set up and operate. What if we built a quick little DNS TXT handle microservice: golang daemon, sqlite datastore, HTTP API with Basic auth (for adding/removing handle/DID mappings), and you delegate DNS for the *.b.c.com space to that microservice? |
Beta Was this translation helpful? Give feedback.
-
|
Understood, makes sense. (Thinking through it, this method would probably mostly be used by pay-level domains with many handles under them, so if the cost here is one additional DNS request for the pay-level domain when the handle itself has no A/AAAA/CNAME, it would hopefully be amortized across many requests within the pay-level domain's DNS TTL, so even p99 hopefully wouldn't be hit much. Regardless, more complexity and variability, definitely understood.) |
Beta Was this translation helpful? Give feedback.
-
Wow, quite an offer. Big if true! I'd never turn down free labor. Hard to believe you all would build and run that just for this, but if so, I'd gladly take you up on it. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, I did something a bit different and simpler: The README has more depth, but basically a little DNS server which response to TXT handle resolution requests by calling I have a live example on my self-hosted PDS here: https://bsky.app/profile/demo.handlr.robocracy.org I think this probably doesn't work with our reference implementation PDS for new account creation (I did a custom handle change for the above demo). |
Beta Was this translation helpful? Give feedback.
-
|
Whoa, awesome! This is amazing. Thank you!!! Not sure how soon I'll set it up and start using it, but it sounds perfect. Psyched to try it. Thank you again! |
Beta Was this translation helpful? Give feedback.
-
|
@bnewbold QDCOUNT can be expected to be no greater than 1 - https://datatracker.ietf.org/doc/draft-ietf-dnsop-qdcount-is-one/
|
Beta Was this translation helpful? Give feedback.
-
|
thanks @andrewtj! I incorporated some of this, though not yet returning any SOA or NS sections in responses. |
Beta Was this translation helpful? Give feedback.
-
Hi all! I'm implementing fediverse => Bluesky handle translation in my bridge, and I'm at the point where I need to serve handle resolution for fediverse users. My current approach, translating
@user@instance.tldto something likeuser.instance.tld.brid.gy, has decent UX, but resolution is proving to be difficult.The HTTPS method requires SSL, but afaik SSL certs only support at most one level of wildcard, eg
*.brid.gybut not*.*.brid.gyor*.*.*.brid.gy. OK. I could try to provision wildcard certs per fediverse instance on the fly, eg with LE, and also install them on the fly. Doable, but not easy, and most web servers only seem to support moderate scale of installed SSL certs.The DNS method is similar. Many DNS services do offer APIs, including hosted ones like eg Route 53 and Google Cloud DNS, but they similarly seem to only scale to a medium number of zones, eg GCP DNS has a 10k zone limit per project.
Existing third party services like https://handles.domi.zip/ and https://bsky.london/ happily give out single-level subdomains, but I haven't seen services for multi-level subdomains yet, probably due to these kinds of difficulties. Any thoughts?
(A third alternative would be to translate handles separately, eg use
-as the separator instead of., which results inuser-instance-tld.brid.gy. Promising, but-is allowed in domain segments, so I'd end up with collisions. I could come up with a more complicated encoding, but that would probably kill usability for the average person who needs to translate handles in their head to use the bridge.)Beta Was this translation helpful? Give feedback.
All reactions