fix(auth): better DNS verification errors and wrong-selector hint#1202
Merged
fix(auth): better DNS verification errors and wrong-selector hint#1202
Conversation
DNS auth users repeatedly hit two failure modes that produce identical, unhelpful "Ed25519 signature verification failed" errors (#385, #1103, #1126): 1. TXT record placed under a selector (_mcp-auth./_mcp-registry.) instead of the apex — DKIM intuition, but MCP DNS auth uses SPF-style apex placement. 2. Stale TXT record left at the apex after a key rotation, silently tried first and rejected. Server changes: - When the apex has no MCPv1 record, probe common wrong selectors and return a targeted error pointing the user at the apex. - When verification fails on records that *are* present, include short fingerprints of every key the registry tried so the user can tell a stale record from a real signing problem. Structural errors (wrong signature size, etc.) still pass through unchanged via a new ErrSignatureMismatch sentinel. Docs: - Anti-pattern callout in authentication.mdx warning explicitly against selector placement and stale records. Refs #845, #385, #1103 Fixes #1126
A loose strings.Contains(r, "v=MCPv1") check at the apex would suppress the misplaced-selector probe whenever a malformed MCPv1 string was present, hiding the helpful "record is at _mcp-auth" hint from the user. Share the strict proof-record regex with the parser so presence detection and parsing agree on what counts as an MCPv1 record. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
tadasant
approved these changes
Apr 25, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
DNS auth users have repeatedly hit two failure modes that both produce the same opaque "Ed25519 signature verification failed" error, making them indistinguishable to debug. This PR makes both diagnosable end-to-end without changing the auth protocol or any successful path.
The two recurring failure modes:
_mcp-auth.<domain>or_mcp-registry.<domain>) instead of the apex. DKIM-style intuition, but MCP DNS auth uses SPF-style apex placement. See Issues authenticating with custom domain for MCP registry #385 (PR docs: fix DNS authentication to use root domain instead of _mcp-registry subdomain #388 fixed the docs but the failure recurred), Request: Reset signing key for dev.agentsim namespace #1103, DNS authentication always fails: Ed25519 signature verification failed #1126.Changes
internal/api/handlers/v0/auth/dns.go— when the apex has nov=MCPv1record, probe_mcp-auth.<domain>and_mcp-registry.<domain>in parallel (2s individual timeout). If a record is found there, return a targeted error pointing the user at the apex. Costs zero extra DNS work in the success path.internal/api/handlers/v0/auth/common.go— when verification fails against records that are present, include short fingerprints of every key the registry tried (ed25519:YJLsHFhu-style 8-char prefix). A newErrSignatureMismatchsentinel keeps structural errors (wrong signature size, unsupported algorithm) passing through unchanged viaerrors.Is, so existing assertions on those messages still hold.docs/modelcontextprotocol-io/authentication.mdx— anti-pattern<Warning>callout in the DNS section explicitly warning against selector placement and stale records.Tests — two new tests:
TestDNSAuthHandler_WrongSelectorProbe— verifies the probe surfaces records found at_mcp-auth./_mcp-registry.and falls through to the standard error when nothing is found anywhereTestDNSAuthHandler_StaleKeyFingerprintInError— verifies the fingerprint hint appears in the failure message for DNS authentication always fails: Ed25519 signature verification failed #1126's exact scenarioOne existing test assertion was updated from a generic
"signature verification failed"substring to the more specific"invalid signature size for ECDSA P-384"it should always have been asserting; the new sentinel-based logic surfaces structural errors verbatim.Test plan
make lint— cleanmake test-unit— all auth tests pass (existing + 2 new)Out of scope
The publisher-side preflight DNS check (cross-link in #845) is intentionally not in this PR — that belongs in the broader CLI UX work tracked by #845.
Refs #845, #385, #1103
Fixes #1126