perf: handle resolution waits for the HTTPS well-known even when DNS has answered

Grandiras commented

2026-10-05 02:09:48 +00:00

Owner

Problem

HandleResolver.ResolveAsync waits for both the DNS TXT lookup and the HTTPS well-known to finish, so that it can fail closed when they disagree. For the many handles configured through DNS, that means every resolution waits for the handle's web host to answer (usually with a 404), even though DNS answered long before.

Measured against the live network (warm connections):

handle	DNS answer	resolution today
bsky.app	~25 ms	~125 ms
atproto.com	~25 ms	~190 ms

A web host that drops packets holds every resolution for the full HandleResolutionTimeout (5 s), although DNS has answered.

Proposal

Follow the spec's resolution best practice: run both lookups concurrently and take the first answer, with DNS TXT preferred. A DNS answer returns at once and cancels the HTTPS lookup; the HTTPS answer is used only when DNS has none. Two distinct did= values in DNS still fail with HandleConflict.

DNS control already implies control of the domain (it can obtain a certificate for it), so preferring DNS gives an attacker nothing the current policy denies them.

### Problem `HandleResolver.ResolveAsync` waits for both the DNS TXT lookup and the HTTPS well-known to finish, so that it can fail closed when they disagree. For the many handles configured through DNS, that means every resolution waits for the handle's web host to answer (usually with a 404), even though DNS answered long before. Measured against the live network (warm connections): | handle | DNS answer | resolution today | |---|---|---| | bsky.app | ~25 ms | ~125 ms | | atproto.com | ~25 ms | ~190 ms | A web host that drops packets holds every resolution for the full `HandleResolutionTimeout` (5 s), although DNS has answered. ### Proposal Follow the spec's resolution best practice: run both lookups concurrently and take the first answer, with DNS TXT preferred. A DNS answer returns at once and cancels the HTTPS lookup; the HTTPS answer is used only when DNS has none. Two distinct `did=` values in DNS still fail with `HandleConflict`. DNS control already implies control of the domain (it can obtain a certificate for it), so preferring DNS gives an attacker nothing the current policy denies them.

Grandiras commented

2026-10-05 02:19:53 +00:00

Author

Owner

Not implementing this autonomously: removing the fail-closed DNS/HTTPS conflict check is a security-relevant policy change. The spec allows it ("use the first successful result … DNS TXT should be preferred"), and it would cut DNS-configured handles from roughly 125–190 ms to ~25 ms, but it needs the owner's call. The latency work that keeps the policy is in a separate issue.

Grandiras referenced this issue

2026-10-05 02:20:37 +00:00

perf: identity lookups over HTTP/2, with a handle answer cache #198

Grandiras referenced this issue from a commit

2026-10-05 12:59:03 +00:00

perf: prefer the DNS answer in handle resolution (closes #193)

Grandiras referenced this issue from a pull request that will close it,

2026-10-05 12:59:04 +00:00

perf: prefer the DNS answer in handle resolution #209

Grandiras closed this issue

2026-10-05 13:06:50 +00:00

Grandiras referenced this issue