DNS verification uses a stale published key after key rotation (com.mambabuilt)

[mambabuilt]

Summary

DNS namespace verification for com.mambabuilt is failing against a stale published key. Our TXT record was rotated on 2026-08-22 and resolves correctly on the authoritative nameserver and on two public resolvers, but the registry still verifies signatures against the pre rotation key and rejects login.

The error

mcp-publisher login dns --domain mambabuilt.com --private-key <redacted> returns, consistently across five attempts spanning several hours:

401 Unauthorized: DNS authentication failed
signature verification failed (tried published key ed25519:DxB0DWiZ);
if this is not the key you are signing with, the published record may be stale

ed25519:DxB0DWiZ is our previous key. It is not the key currently published in DNS.

Current TXT record

Name: _mcp-registry.mambabuilt.com

v=MCPv1; k=ed25519; p=pyZaLsMmhYigY6NHLQ57bRJD3vL4mO7hNyz3yGbpizo=

Exactly one TXT record exists at that name, so there is no stale duplicate to disambiguate.

Resolver output

Authoritative, via dig +short TXT _mcp-registry.mambabuilt.com:

"v=MCPv1; k=ed25519; p=pyZaLsMmhYigY6NHLQ57bRJD3vL4mO7hNyz3yGbpizo="

Google Public DNS:

v=MCPv1; k=ed25519; p=pyZaLsMmhYigY6NHLQ57bRJD3vL4mO7hNyz3yGbpizo=

Cloudflare:

"v=MCPv1; k=ed25519; p=pyZaLsMmhYigY6NHLQ57bRJD3vL4mO7hNyz3yGbpizo="

TTL is 1800 and the record has been in place well beyond that.

What we verified before filing

• The private key we sign with derives exactly the public key published above. Verified locally by deriving the Ed25519 public key from our seed and comparing it to the TXT value.
• Only one TXT record exists at the name, on all three resolvers.
• Our previously issued registry token carried the correct permissions, publish on com.mambabuilt/*, and expired on 2026-08-18, so it cannot be reused.

The ask

Please re poll DNS verification for the com.mambabuilt namespace so the published key is refreshed from the current TXT record.

We have deliberately not regenerated a key, since DNS is not at fault and rotating again would not clear a cached value. We have also deliberately not fallen back to GitHub login, because that would publish our servers under a different namespace and permanently fragment the identity of an existing fleet.

Impact

47 MCP servers are built, published to npm and ready to publish to the registry. Publication is held until verification clears.

Environment

• mcp-publisher 1.7.9
• Namespace: com.mambabuilt
• Key rotated: 2026-08-22

[mambabuilt]

Closing this. The registry was behaving correctly and the fault was ours.

We published the rotated key at _mcp-registry.mambabuilt.com. DNS authentication reads the TXT record at the apex domain, and internal/api/handlers/v0/auth/dns.go lists _mcp-registry explicitly in commonWrongSelectors for exactly this mistake. Our apex record still carried the pre rotation key, so ed25519:DxB0DWiZ was the only key published as far as the registry was concerned, and the 401 was accurate.

Apologies for the noise. Two small notes in case they are useful to anyone else who lands here:

1. The error text "the published record may be stale" reads naturally as a registry side caching problem, which is what sent us looking in the wrong direction for two days. Naming the apex explicitly, something like "no valid key found at mambabuilt.com", would have pointed straight at the cause.
2. findMisplacedSelector already detects this case. In our run the hint did not reach us through mcp-publisher, only the generic signature failure did. Surfacing that hint in the CLI output would have caught it immediately.

Thanks for the registry, and sorry for the false report.