Summary

This PR adds optional DNS bootstrap discovery to SEP-2127.

The intent is not to store MCP Server Cards directly in DNS, and not to replace the proposed .well-known/mcp-server-card endpoint. Instead, DNS can act as an authoritative, cache-friendly bootstrap layer that points clients to an MCP Server Card, AI Card catalog, or equivalent services document.

This keeps .well-known/mcp-server-card as the primary HTTP discovery mechanism while giving domain owners another way to advertise discovery metadata when they control DNS but not web-root routing.

Motivation

SEP-2127 currently identifies lack of domain-level discovery as a pain point. It also considers DNS-based discovery, but rejects it because a DNS-only approach would be limited to domain-level discovery and would not work well for path-based or port-based MCP servers.

This PR narrows the DNS role:

• DNS does not carry the Server Card.
• DNS does not need to model every path-based or port-based deployment.
• DNS only points to a discovery document.
• The discovered document can then point to arbitrary HTTPS URLs for Server Cards.

That preserves support for path-specific, port-specific, multi-server, and third-party-hosted MCP deployments.

Why this helps

Many domain owners can update DNS records but cannot reliably place arbitrary files under /.well-known/, especially when using hosted website platforms, SaaS builders, reverse proxies, or vendor-managed web frontends.

Optional DNS bootstrap gives those domain owners a way to say:

This is where my MCP discovery metadata lives.

The client can still retrieve the Server Card over HTTPS and validate it according to the existing discovery flow.

Relationship to Intelligence-over-DNS / IOD

This PR references Intelligence-over-DNS as an example of a DNSSEC-backed mechanism for publishing structured, machine-readable service metadata through DNS:

https://github.com/markjr/Intelligence-over-DNS

IOD includes a services document type for API endpoints and MCP server locations, which makes it a natural substrate for this kind of bootstrap discovery.

The SEP does not need to normatively adopt IOD. The point is to leave room for DNS-backed discovery documents, including IOD-style services documents, without requiring DNS to carry complete MCP Server Cards.

Security considerations

DNS-discovered metadata should remain advisory discovery metadata, not authorization.

Clients that implement DNS bootstrap should still:

• validate HTTPS when fetching Server Cards or catalogs;
• validate response media type and schema conformance;
• validate DNSSEC when the DNS discovery mechanism requires it;
• avoid treating DNS-discovered metadata as an access-control decision;
• fall back to .well-known/mcp-server-card when no DNS bootstrap record exists.

Design framing

The distinction is:

• DNS-only Server Card discovery: too restrictive.
• DNS bootstrap for Server Card discovery: useful and compatible with this SEP.

In short: DNS answers “where is the discovery document for this domain?” The Server Card answers “how do I connect to this MCP server?”