Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

DNS auth 401 "no MCP public key found" despite correct, globally-propagated base64 TXT record

オープン
  • 何か問題がありますか？
#1,694 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
48/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
go
領域
authentication, networking

調査の方向性

Start with the registry's DNS authentication path, using the mcp-publisher login dns flow and the reported 401 as the reproduction. Compare the TXT lookup result used by the registry with the public and authoritative resolver results listed here, and investigate whether stale negative caching is involved. Done means the registry recognizes the published base64 proof and DNS login succeeds, or the resolver/cache behavior is identified.

索引モデルが issue の本文から書いたものです。

説明

Summary

DNS authentication (mcp-publisher login dns) fails with 401 no MCP public key found in DNS TXT records, even though the required MCP proof TXT record is correctly published, well-formed, and globally propagated. The registry's resolver appears to be serving/caching a stale negative result: every public resolver and the authoritative nameserver return the correct base64 Ed25519 key, but the registry still cannot see it after ~3 hours.

Environment
  • mcp-publisher version: 1.8.1
  • Domain: solides.com.br (apex TXT record, authoritative = AWS Route 53, TTL 60s)
  • Auth method: login dns
What the publisher expects (from login dns output)
Expected proof record:
v=MCPv1; k=ed25519; p=SKhuBvoz+KAh+PdxO6WHDunygJ03s6ahwSbR6FR3wtw=
What is actually published (and globally propagated)

The TXT record on the solides.com.br apex is identical to the expected proof, is a single value (no 255-char chunking, no duplicate v=MCPv1), with TTL 60s. Verified just now against 5 resolvers plus the authoritative NS:

Resolver Returns
8.8.8.8 (Google) v=MCPv1; k=ed25519; p=SKhuBvoz+KAh+PdxO6WHDunygJ03s6ahwSbR6FR3wtw=
1.1.1.1 (Cloudflare) identical
9.9.9.9 (Quad9) identical
208.67.222.222 (OpenDNS) identical
ns-1666.awsdns-16.co.uk (authoritative Route 53) identical

Reproduce:

dig +short TXT solides.com.br @8.8.8.8 | grep MCPv1
Actual error
Error: failed to get token: failed to exchange dns signature: token exchange failed with status 401:
{"title":"Unauthorized","status":401,"detail":"DNS authentication failed",
 "errors":[{"message":"no MCP public key found in DNS TXT records"}]}
Likely cause

The record was previously published for a few days in hex encoding (p=48a8..., 64 chars) before being corrected to the spec-required base64 encoding. We suspect the registry's internal DNS resolver has a stale cache / negative-cache entry for solides.com.br TXT that is outliving the record's 60s TTL (3h+ and counting), so it never re-fetches the corrected base64 key. The public internet has fully converged on the correct value.

Ask

Could you confirm which resolver the registry backend uses for DNS auth, and whether its cache for solides.com.br TXT can be flushed / its TTL honored? Happy to provide any further diagnostics.

(Note: the p= value above is an Ed25519 public key — safe to share for reproduction.)

主要言語
Go
スター
7.3k
フォーク
1k
平均マージ
3日 14時間
マージ済み PR（30日）
12

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

modelcontextprotocol/registry のほかの issue

modelcontextprotocol/registry の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。