Handle->DID resolution via /.well-known/atproto-did endpoint by anna-germ · Pull Request #3 · ATProtoKit/ATResolve

anna-germ · 2025-11-18T18:53:50Z

Hi Matt! This may not be the exact way you'd want to implement this, but I wanted to propose an ATResolve update that accounts for the second way people can register handles, via .well-known path instead of DNS TXT record, as per:

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, or have multiple accounts for different verticals like @sports.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.
Instead of using DNS TXT records, you can return each account's DID from the route https://${handle}/.well-known/atproto-did. The expected payload is a DID (such as did:plc:abcdef...) with content-type text/plain. The handle resolution function explicitly expects a HTTP 200 OK status. (source)

I've found that the DNS check takes a while (~1 min) if the appropriate TXT file isn't there (it falls back appropriately to the getProfile function, it just takes a while to reach there), and in my experience the well-known check can be slow as well if that endpoint doesn't exist, so I'm suggesting racing the DNS check against the ./well-known/atproto-did and returning whenever we find a value.

mattmassicotte · 2025-11-23T22:30:04Z

Ohh this is a super good idea! Thanks so much for suggesting this.

Yeah, the DNS check is kinda awful. Unsure why exactly... I also don't know if this is the best long-term thing, however it does not change public API in any ways, and it seems reasonable to me. So let's give it a shot!

mattmassicotte · 2025-11-24T11:56:11Z

Ahh, ok so the issue here, unfortunately, is that this now has a dependency on Foundation but it is not imported. This actually is a real problem on Linux. But that's something I will address eventually if it becomes important to do so.

germ-mark · 2025-12-02T01:16:46Z

#4 should address the URLSession dependency that is failing the Linux tests (it also fixes the visionOS test issue)

We could then adopt that API here to make it work on Linux.

anna-germ · 2025-12-09T21:14:22Z

Converting to draft as I (and potentially Mark) work on a few to-do’s:

Fix the failing Linux tests
Make DNS and http requests in parallel (evidently both of them could take a while to fail, so seems better to race them)
Maybe adjust the Bluesky handling to be more generic

This reverts commit 9c360c7.

Improve handle resolution by racing DNS vs. /.well-known

anna-germ · 2025-12-12T06:08:45Z

Hellooooo! In the wake of Mark's PR, and also some work Mark did on running the DNS and well-known checks in parallel, I've replaced this PR with a new version.

One note on top of a code-specific flag I'll send:

The .bsky.social DNS check was failing because those accounts use the well-known endpoint. So you can take out Bluesky-specific handling. I did that but then put it back because Mark pointed out it's a public API. Oops. Anyways, you can consider removing the Bluesky-specific handling!

anna-germ · 2025-12-12T06:09:56Z

 }

-public protocol ResponseProviding {
+public protocol ResponseProviding: Sendable {


Mark pointed out that you have a conditional conformance of ATResolve being Sendable if ResponseProviding is Sendable -- I'm making new problems for you by now requiring ResponseProviding to always be sendable. This is our best attempt at making the task groups work, but would defer to your expertise!

Very generally speaking, Sendable protocols making the lives of the users of the protocol (that's us here) easier, while making the conformer's lives (that's the libraries clients) harder. In this case, however, I think it is pretty reasonable. So I think it's fine, we just need to remove the conditional conformance.

anna-germ · 2025-12-13T01:31:22Z

The problem with this newer PR (with the task group) is that it now takes as long as the longest task. I'd add a guard !Task.isCancelled else return but the well-known and DNS checks are pretty atomic (unless I dig deeper into DNSSDDNSResolver) so I'm not quite sure where would be the best place to cancel the task.

@mattmassicotte do you have any good suggestions? Some discussion happening here: https://forums.swift.org/t/accept-the-first-task-to-complete/54386

mattmassicotte · 2025-12-20T20:30:16Z

Cancellation could end up being tricky to support here, because it ultimately relies on the subsystems doing that internally. That thread kind of gets into the details.

ThisIsMissEm · 2025-12-22T19:15:48Z

+			let didRecord = txtRecords.first { record in
+				record.txt.hasPrefix("did=")
+			}
+			return didRecord?.txt.components(separatedBy: "=").last


This could technically have issues, as some did methods can include query strings, so you probably want to just split on = and then drop the first component, then join the rest.

ThisIsMissEm

I suspect the cancellation issue is due to the checkDNS being an attached task, where as in this implementation, they're explicitly detaching the DNS resolution task: https://github.com/ATProtoKit/ATIdentityTools/blob/main/Sources/ATIdentityTools/Handle/HandleResolver.swift#L80 (Note: Apache 2.0 not BSD license)

ThisIsMissEm · 2025-12-22T19:17:48Z

+
+	static func checkWellKnown(handle: String, provider: Provider) async -> String? {
+		do {
+			let dataResult = try await provider.data(


I'm not sure if the Provider here would allow it, but you could set a maximum response body size to like 1kb, and stop reading the response after that, since anything larger and you know it's not a valid response (it's likely HTML)

I think it should be possible to make an appropriate provider function that does this, if the underlying request system allows it?

anna-germ · 2025-12-22T22:42:11Z

+			// Only check Cloudflare and Google DNS servers
+			var dnsOptions = CAresDNSResolver.Options.default
+			dnsOptions.servers = ["1.1.1.1", "1.0.0.1", "8.8.8.8", "8.8.4.4"]


This resolves the DNS timeout issue, but we can also adjust dnsOptions.timeoutMillis and dnsOptions.attempts

We could make this a variable on the resolver, and allow overriding it, but using these defaults — since they're major DNS server providers. We may want to provide IPv6 options here too.

Another option is to not use AsyncDNSResolver and instead just use DNS over HTTPS: https://github.com/bluesky-social/atproto/blob/9dac8b0c600520ecb0066ac104787b27668dea47/packages/internal/handle-resolver/src/atproto-doh-handle-resolver.ts#L37

which would be somewhat more secure than using standard DNS (which is cleartext). That would also then allow this to be fully cancellable.

That sounds like a really cool option. Perhaps that could be another thing in the chain of checks this system does?

Well, with a bit of reorganisation we could hsve different handle resolvers, DNS, HTTP and DNS over HTTPS, and then folks could choose the right methods for them?

i suspect DoH would be superior here even though response times might be slightly higher than DNS

Sounds great to me! What I was trying to go for was a "all discrete options public API" so you can get the behaviors you need, if you have advanced requirements. And then also something pre-configured so there's an easy (but potentially suboptimal) thing for people that aren't interested in learning how it all works.

mattmassicotte · 2025-12-23T13:19:29Z

The use of Task.detached in that linked code is very unlikely doing what the author intended. That's a commonly-misunderstood API.

mattmassicotte · 2026-05-28T13:25:34Z

Do you still have any interest in pursuing this one?

germ-mark · 2026-05-28T19:32:54Z

We aren't pursuing this, you can feel free to close.

germ-mark mentioned this pull request Dec 2, 2025

Genericize ResponseProviding to an HTTPSRequester #4

Merged

anna-germ marked this pull request as draft December 9, 2025 21:12

anna-germ added 2 commits December 11, 2025 18:00

Add mark/parallel edits

0dee7a1

Remove bluesky-specific handling

9c360c7

anna-germ mentioned this pull request Dec 12, 2025

Improve handle resolution by racing DNS vs. /.well-known germ-network/ATResolve#4

Merged

anna-germ added 2 commits December 11, 2025 21:56

Putting back bluesky-specific handling

9252b85

This reverts commit 9c360c7.

Merge pull request #4 from germ-network/anna/parallel

5d74541

Improve handle resolution by racing DNS vs. /.well-known

anna-germ force-pushed the wellknown-atproto branch from 36c50b8 to 5d74541 Compare December 12, 2025 06:02

anna-germ marked this pull request as ready for review December 12, 2025 06:03

anna-germ commented Dec 12, 2025

View reviewed changes

anna-germ marked this pull request as draft December 12, 2025 21:22

ThisIsMissEm reviewed Dec 22, 2025

View reviewed changes

Comment thread Sources/ATResolve/ATResolver.swift Outdated

ThisIsMissEm reviewed Dec 22, 2025

View reviewed changes

anna-germ added 2 commits December 22, 2025 14:27

DNS and HTTPS timeouts

28b3010

Removing attempts/timeoutMillis

2cbedc8

anna-germ commented Dec 22, 2025

View reviewed changes

Remove conditional conformance

6a01c46

mattmassicotte closed this Jun 5, 2026

Uh oh!

Uh oh!

Conversation

anna-germ commented Nov 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mattmassicotte commented Nov 23, 2025

Uh oh!

mattmassicotte commented Nov 24, 2025

Uh oh!

germ-mark commented Dec 2, 2025

Uh oh!

anna-germ commented Dec 9, 2025

Uh oh!

anna-germ commented Dec 12, 2025

Uh oh!

anna-germ Dec 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

anna-germ commented Dec 13, 2025

Uh oh!

mattmassicotte commented Dec 20, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ThisIsMissEm left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

anna-germ Dec 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mattmassicotte commented Dec 23, 2025

Uh oh!

mattmassicotte commented May 28, 2026

Uh oh!

germ-mark commented May 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

anna-germ commented Nov 18, 2025 •

edited

Loading

anna-germ Dec 12, 2025 •

edited

Loading

anna-germ Dec 22, 2025 •

edited

Loading