DNS-based server name verification

[tadasant]

We should allow for MCP servers to be published without requiring them to be prefixed with a io.github name prefix (which is the default fallback).

Work to be done here:

• Decide on DNS TXT-based verification or some other process
• Implement as an alternative to the io.github publication approach
• Allow for an individual user to verify a domain on behalf of a whole GitHub org
• The DNS check should happen on every publish, so that if the verification is no longer valid, the corresponding users/orgs are no longer allowed to publish

[steiza]

I think there's quite a few open questions here.

As I understand it, the current authentication mechanism for publishing to the MCP registry is to have the user get a GitHub OAuth token, and ensuring the server.json repository.url matches that user. This works for MCP servers you run locally, but not for a remote server?

I think this proposal would allow for authorization for MCP servers that run on a remote server (but not locally, because there's no domain the submitter controls for a MCP server intended to run locally). Then you need to figure out a way to provide a challenge (to be set as the DNS TXT record on that domain), what properties that challenge should cover, what to do if multiple submissions use different paths on the same domain, etc.

There's a lot here - I think it might be helpful to write up a threat model, or at least some "happy path" and malicious user examples, and how the DNS flow enables the "happy path" users while preventing attacks from malicious users.

[tadasant]

Sorry, I can tell from reading your response that we have not sufficiently documented this. Will take an action to do that better ASAP (#131).

As I understand it, the current authentication mechanism for publishing to the MCP registry is to have the user get a GitHub OAuth token, and ensuring the server.json repository.url matches that user.

This is not the case. The goal of the auth mechanism (+ optional DNS verification) is to facilitate a namespace for the name field, in reverse-DNS fashion. So it is unrelated to the repository.url field. It may make sense to cut another issue for making sure the repo at repository.url wants to be associated with this MCP server entry, similar to #96 for packages. And maybe another analogous mechanism for the entries in remotes (alluded to here; need to cut another ticket to follow up).

Hopefully from that starting point, the downstream considerations make more sense.

[domdomegg]

Linking up a few related threads: #221, #270, #279

[domdomegg]

Done in #279 🎉