]> Alter Meridian Pty Ltd

Cronulla, NSW Australia blake@truealter.com

This document defines a DNS-based mechanism for the discovery of Model Context Protocol (MCP) servers. A TXT resource record published at the underscore-prefixed label _mcp.<domain> advertises the presence, endpoint URL, transport protocol, cryptographic identity, and capability profile of an MCP server associated with a domain name. The mechanism complements existing HTTPS-based discovery (.well-known/mcp/server-card.json) by providing a lightweight, resolver-cached bootstrap that requires no HTTPS round-trip. The design follows the precedent established by DKIM , SPF , DMARC , and MTA-STS , all of which use DNS TXT records at underscore-prefixed labels to advertise domain-scoped policy and service metadata.

Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 7, 2026.

Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Introduction Model Context Protocol (MCP) is an open protocol for structured interaction between AI agents and tool-providing servers. An MCP client that wishes to invoke tools, access resources, or issue prompts against a server must first discover the server's endpoint URL, transport, and authentication requirements. As of April 2026, MCP clients discover servers through three mechanisms: manual configuration (the user pastes a URL), registry lookup (centralized catalogues of known servers), and HTTPS-based endpoint discovery via .well-known/mcp/server-card.json as proposed in MCP SEP-1649 and SEP-1960 . None of these mechanisms satisfies the emerging requirement that any domain on the public internet may host an MCP server and that any MCP client may discover that server without prior knowledge or manual configuration. Manual configuration does not scale. Registry lookup introduces a centralized intermediary. HTTPS-based discovery requires an HTTPS round-trip to every candidate domain before the client knows whether an MCP server exists there at all. DNS provides a natural solution. The DNS is the internet's universal, decentralized, cached name-resolution layer. Every internet-connected client already has a DNS resolver. DNS TXT records at underscore-prefixed labels are the established convention for advertising domain-scoped service metadata, with successful precedents spanning two decades:

• DKIM publishes Ed25519/RSA public keys at <selector>._domainkey.<domain> for email authentication.
• SPF publishes sender policy at the domain apex.
• DMARC publishes alignment and reporting policy at _dmarc.<domain>.
• MTA-STS publishes mail transport security policy at _mta-sts.<domain>, with a split design: DNS advertises presence and a policy identifier; HTTPS carries the full policy.

This document proposes an analogous mechanism for MCP. A TXT resource record at _mcp.<domain> advertises the minimum information a client needs to bootstrap an MCP session: the endpoint URL and protocol version. Optional fields declare the transport protocol, a cryptographic public key for endpoint pinning, an epoch counter for key rotation, capability hints, attestation scope, and priority for multi-server failover. The design deliberately splits responsibility between DNS and HTTPS. DNS advertises presence, endpoint location, and transport metadata. HTTPS (via the Server Card defined in SEP-1649 ) carries the full capability manifest. This split mirrors MTA-STS and avoids both the 255-byte TXT record stuffing anti-pattern and the performance penalty of an HTTPS round-trip for every discovery attempt. The mechanism is general. It applies to any MCP server: tool providers, resource servers, identity endpoints, prompt libraries, and any future MCP primitive. It does not prescribe the semantics of the tools or resources behind the endpoint. A domain that publishes _mcp.<domain> declares only that an MCP server exists and where to find it. The DNS-based discovery mechanism defined in this document operates at the transport and endpoint layer of a broader identity infrastructure. Recent theoretical work establishes that discrete authentication events -- including DNS-advertised credential records and endpoint attestations -- are a special case of a continuous identity field maintained across the social-spatial manifold: formally, the maximum-entropy field consistent with the point-in-time observations that checkpoint mechanisms provide. This framing motivates several design choices in this document. The epoch field encodes temporal position in a continuous field, not a version counter for a static credential. The scope field encodes gauge restriction -- the set of identity dimensions exposed at this endpoint -- whose formal properties are specified by the consent architecture of the deploying identity infrastructure. Implementations that treat these fields as optional metadata underutilise the protocol's expressive capacity. The approach is deliberately conservative. A dedicated DNS resource record type (e.g., a hypothetical "MCP" RR type) was considered and rejected. SPF registered a dedicated RR type (type 99) in 2006; it was formally deprecated in because no DNS software ecosystem adopted it. Matrix's reliance on SRV records (_matrix._tcp.<domain>) has proven problematic for CDN-fronted deployments, prompting active proposals to remove SRV entirely. TXT records at underscore-prefixed labels are the only DNS-based service advertisement mechanism that is universally supported by authoritative servers, recursive resolvers, CDN-fronted domains, and DNS management interfaces as of 2026. The HTTPS RR type defined in is a promising future direction but does not yet enjoy universal resolver support or management UI exposure. This document does not preclude a future HTTPS RR-based alternative; it establishes the TXT-based mechanism as the baseline for immediate deployment.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 when, and only when, they appear in all capitals, as shown here.

Terminology

MCP

Model Context Protocol, as specified by the Agentic AI Foundation .

Discovery Record

A DNS TXT resource record published at the _mcp label under a Policy Domain, conforming to the syntax defined in Section 3.

Server Card

A JSON metadata document served at .well-known/mcp/server-card.json per MCP SEP-1649 , describing the full capabilities and authentication requirements of an MCP server.

Policy Domain

The domain name under which a Discovery Record is published. For the record _mcp.example.com, the Policy Domain is example.com.

Origin Domain

The domain name extracted from an identifier (email address, URL, handle, or similar) that triggers the discovery procedure.

Epoch

A monotonic non-negative integer published in the Discovery Record that increments on every key rotation event. Used to bind signed claims to a specific key generation and to enable epoch-based revocation.

Attestation Scope

The set of claim types that an MCP server declares it is authorized to issue, published via the attest field.

Record Format

DNS Location The Discovery Record is a DNS TXT resource record published at the label _mcp prepended to the Policy Domain: _mcp.<policy-domain>. IN TXT "<record-value>" The underscore prefix conforms to the conventions established in for globally scoped, underscore-prefixed DNS node names. Multiple TXT resource records MAY be published at the same DNS name. When multiple records exist, each MUST independently conform to the syntax defined in this section. Clients MUST evaluate all returned records and select among them using the priority field as described below.

ABNF Grammar The record value is a semicolon-delimited sequence of key-value pairs. The following ABNF [RFC5234] defines the syntax: ``` mcp-record = version *( ";" SP field ) version = "v=mcp1" field = url-field / proto-field / pk-field / epoch-field / cap-field / attest-field / scope-field / priority-field / ttl-field / ext-field / unknown-field url-field = "url=" https-uri proto-field = "proto=" proto-value pk-field = "pk=" algo ":" base64url epoch-field = "epoch=" 1DIGIT cap-field = "cap=" cap-csv attest-field = "attest=" attest-csv scope-field = "scope=" scope-csv priority-field = "priority=" 1DIGIT ttl-field = "ttl=" 1*DIGIT ext-field = "ext=" https-uri unknown-field = token "=" *VCHAR https-uri = "https://" VCHAR algo = "ed25519" base64url = 1( ALPHA / DIGIT / "-" / "" ) proto-value = "streamable-http" / "sse" / "stdio-url" / token cap-csv = cap-token *( "," cap-token ) cap-token = token attest-csv = attest-token *( "," attest-token ) attest-token = token scope-csv = scope-token *( "," scope-token ) scope-token = "tools" / "resources" / "prompts" / "sampling" / "identity" / token token = 1*( ALPHA / DIGIT / "-" / "" ) ```

Field Definitions

v (REQUIRED) Protocol version identifier. MUST be the literal string mcp1. MUST appear as the first field in the record. Clients MUST reject any record whose v field is absent, is not the first field, or contains a value other than mcp1. This version gate enables future incompatible revisions of the record format. A future version mcp2 would indicate breaking changes to field semantics or discovery flow.

url (REQUIRED) The HTTPS URL of the MCP server endpoint. MUST use the https scheme. MUST be a syntactically valid URI per RFC 3986. This is the entry point for MCP session establishment. Clients MUST NOT attempt to connect to URLs using schemes other than https. Servers MUST present a valid TLS certificate for the hostname in the URL.

proto (OPTIONAL) The transport protocol used by the MCP server. Default value: streamable-http. Defined values:

• streamable-http -- HTTP-based streaming transport (default).
• sse -- Server-Sent Events transport.
• stdio-url -- URL pointing to a signed launch descriptor for a stdio-based server (descriptor format out of scope).

Implementations SHOULD support at least streamable-http. Unknown values MUST cause the client to skip this record and proceed to the next record by priority, or to HTTPS fallback.

pk (OPTIONAL) Ed25519 public key for endpoint verification, encoded as ed25519:<base64url> where <base64url> is the raw 32-byte public key encoded per Section 5, without padding. When present, the pk field provides a cryptographic binding between the DNS record and the MCP server. Clients MUST verify that the key matches at least one of the following:

1. A key in the server's TLS certificate SubjectPublicKeyInfo.
2. The signing key used in HTTP Message Signatures on MCP responses.
3. The key declared in the Server Card served by the endpoint.

If verification fails, the client MUST treat the server as untrusted and SHOULD NOT proceed with the MCP session.

epoch (OPTIONAL) A monotonic non-negative integer that increments on every key rotation. Default value: 0. Signed claims or attestations issued by the MCP server carry a key identifier (kid) of the form <algo>:<pk>#<epoch>. Verifiers resolve the Discovery Record, extract the current epoch, and apply the following rules:

• Claims with epoch == current are valid (subject to temporal checks).
• Claims with epoch < current are revoked unless the claim's expiry timestamp predates the rotation event.
• Claims with epoch > current MUST be rejected as either forgeries or evidence of a stale verifier DNS cache.

The epoch field enables epoch-based revocation without external Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol (OCSP) infrastructure. Incrementing the epoch revokes all outstanding claims issued under prior epochs, subject to the grace period defined by each claim's expiry.

cap (OPTIONAL) Capability tier advertised by the server, expressed as a comma-separated list of tokens. This field provides a coarse hint to clients about the functional scope of the server. No normative semantics are defined for specific capability values in this document. Protocol extensions MAY define capability tokens and their semantics. Clients that do not recognize a capability token MUST ignore it.

attest (OPTIONAL) A comma-separated list of attestation types that the MCP server declares it is authorized to issue. The value enumerates claim types that downstream verifiers will accept from this issuer. Defined values (extensible):

• employ -- Current employment affiliation.
• contract -- Contractual or freelance engagement.
• alumnus -- Former affiliation.
• director -- Board or directorial role.
• member -- Generic membership (professional body, association).
• contrib -- Verified contribution without formal affiliation.

Verifiers MUST reject any attestation claim whose type is not present in the issuer's attest field. This provides a structural defense against capability creep: the domain's published attestation scope is the upper bound on what its claims can assert. Forward compatibility: unknown attestation values MUST be ignored, not rejected. A verifier encountering attest=employ,fellow where fellow is undefined treats the record as attest=employ and proceeds.

scope (OPTIONAL) Comma-separated list of MCP primitives supported by the server. Defined values:

• tools -- The server exposes callable tools.
• resources -- The server exposes readable resources.
• prompts -- The server exposes prompt templates.
• sampling -- The server supports LLM sampling requests.
• identity -- The server supports identity resolution queries.

Unknown values MUST be ignored. This field is advisory; the authoritative capability set is declared during the MCP initialize handshake.

priority (OPTIONAL) A non-negative integer. Default value: 10. When multiple Discovery Records exist at the same DNS name, clients MUST sort records by priority in ascending order and attempt connection to lower-valued records first. This field enables multi-server failover without external load balancing. If connection to the highest-priority server fails, the client proceeds to the next record.

ttl (OPTIONAL) Advisory TTL in seconds for client-side caching of the parsed Discovery Record metadata. Clients MAY use this value to avoid repeated DNS lookups when the DNS TTL is shorter than desired. The DNS TTL itself remains authoritative for cache expiry of the raw DNS response; the ttl field applies to post-parse metadata caching only.

ext (OPTIONAL) An HTTPS URL pointing to a protocol-extension document. The format and semantics of the extension document are defined by the protocol extension, not by this specification. This field enables protocol-specific extensions (identity protocols, payment protocols, agent-to-agent negotiation) to attach additional metadata without consuming space in the DNS TXT record. The extension document MUST be served over HTTPS. Clients that do not recognize or support the extension MUST ignore this field.

Forward Compatibility Implementations MUST ignore unknown fields. A parser encountering a field name that it does not recognize MUST skip that field and continue parsing the remaining fields. This rule ensures that future extensions to the record format do not break existing implementations. Breaking changes to the semantics of existing fields require a version bump (e.g., v=mcp2).

Multi-String Concatenation DNS TXT resource records are limited to 255 bytes per character-string . When a Discovery Record exceeds 255 bytes, the record MUST be split across multiple character-strings within a single TXT RDATA, which the DNS resolver concatenates per Section 3.3. Example of a multi-string record: _mcp.example.com. IN TXT ( "v=mcp1; url=https://mcp.example.com; " "pk=ed25519:LongBase64UrlEncodedPublicKeyValueHere; " "epoch=3; attest=employ,contract,alumnus; scope=tools,identity" ) Parsers MUST concatenate all character-strings within a single TXT RDATA before parsing the semicolon-delimited fields. Parsers MUST NOT treat each character-string as an independent record.

Discovery Procedure This section defines the step-by-step algorithm that an MCP client follows to discover an MCP server associated with a given domain.

Input The procedure takes a single input: an Origin Domain. The Origin Domain is typically extracted from an identifier encountered during agent operation -- an email address (user@example.com yields example.com), a URL (https://example.com/path yields example.com), a handle (~user@example.com yields example.com), or a bare domain.

Algorithm

1. Normalize. Convert the Origin Domain to its canonical form: lowercase per [RFC4343], apply IDNA2008 processing where the domain contains non-ASCII labels.
2. Construct query name. Prepend the label _mcp. to the normalized Origin Domain, yielding _mcp.<origin>..
3. Query DNS. Issue a DNS query for _mcp.<origin>. IN TXT via the client's configured recursive resolver. Clients SHOULD prefer DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) to protect query privacy (see Section 6).
4. Handle DNS response. a. If the response is NOERROR with one or more TXT records, proceed to step 5. b. If the response is NXDOMAIN or NOERROR with zero TXT records, proceed to step 8 (HTTPS fallback). c. If the response is SERVFAIL or the query times out, the client MAY retry with exponential backoff or proceed to step 8.
5. Parse records. For each TXT RDATA in the response: a. Concatenate all character-strings within the RDATA. b. Split the concatenated string on the ";" delimiter, trimming leading and trailing whitespace from each field. c. Verify that the first field is v=mcp1. If not, discard this record. d. Extract all recognized fields. Ignore unknown fields per Section 3.7. e. Verify that the url field is present and contains a syntactically valid HTTPS URL. If not, discard this record.
6. Sort by priority. Collect all valid records. Sort by priority in ascending order (lowest value first). Records with equal priority MAY be tried in any order.
7. Connect. For each record in priority order: a. Establish a TLS connection to the host in the url field. b. If the record contains a pk field, verify the key per Section 3.3.4. On failure, skip to the next record. c. Initiate the MCP session using the transport declared in proto (defaulting to streamable-http). d. If the MCP initialize handshake succeeds, discovery is complete. e. If connection or handshake fails, proceed to the next record. If all records are exhausted, proceed to step 8.
8. HTTPS fallback. Attempt HTTPS-based discovery by fetching https://<origin>/.well-known/mcp/server-card.json per SEP-1649 , or https://<origin>/.well-known/mcp per SEP-1960 . If fallback succeeds, proceed with the MCP session. If fallback fails, discovery has failed.

Caching Clients SHOULD cache the parsed Discovery Record metadata for the duration of the DNS TTL. When the Discovery Record includes a ttl field, clients MAY extend their metadata cache to that duration, but MUST re-validate the underlying DNS record when the DNS TTL expires. Clients that have previously connected to an MCP server and verified its pk SHOULD cache the verified key binding and re-validate it on subsequent connections (Trust On First Use, with periodic re-verification against DNS).

Security Considerations

DNS Response Integrity DNS responses are subject to forgery through cache poisoning, on-path interception, and resolver compromise. A forged Discovery Record could redirect clients to a malicious MCP server. Operators SHOULD sign their zones with DNSSEC [RFC4033] [RFC4034] [RFC4035]. Clients SHOULD request DNSSEC validation from their recursive resolver (the AD flag) and SHOULD treat responses that fail DNSSEC validation as equivalent to NXDOMAIN. When the parent zone is unsigned, DNSSEC provides no protection; clients MUST rely on the TLS and key-pinning mechanisms described below. DNSSEC deployment remains uneven. This specification does not require DNSSEC because doing so would exclude a significant fraction of potential deployers. Instead, DNSSEC is RECOMMENDED as a defense-in-depth layer, with TLS as the primary authentication mechanism.

TLS as Primary Authentication The url field MUST use the https scheme. The MCP server MUST present a valid TLS certificate for the hostname in the URL, issued by a certificate authority trusted by the client. TLS authenticates the server to the client and provides confidentiality and integrity for the MCP session. Even if the DNS record is forged, an attacker cannot present a valid TLS certificate for the legitimate server's hostname without compromising the WebPKI trust chain.

Key Pinning via the pk Field The optional pk field provides an additional layer of authentication independent of the WebPKI. When present, the client verifies that the server's Ed25519 key matches the key declared in DNS. This binding is valuable in two scenarios:

1. Certificate authority compromise. If a CA issues a fraudulent certificate for the server's hostname, the pk binding detects the discrepancy because the attacker does not possess the correct Ed25519 private key.
2. Attestation verification. Signed artifacts (attestations, identity claims, x402 payment receipts) issued by the server can be verified against the pk in DNS, providing a verification path that does not depend on the TLS session.

Key pinning introduces a risk of key loss. If the operator loses the private key corresponding to the published pk, legitimate clients will reject the server. Operators MUST maintain secure key backups and SHOULD implement the key rotation procedure described below.

Key Rotation Key rotation follows the overlapping-key pattern established by DKIM:

1. Generate a new Ed25519 keypair.
2. Update the MCP server to accept both the old and new keys.
3. Publish a new Discovery Record with the updated pk and incremented epoch.
4. Wait for at least 2x the DNS TTL to allow cached records to expire.
5. Remove the old key from the MCP server.

During the overlap window (steps 2-4), clients with cached old records and clients with fresh new records both succeed. The epoch field enables verifiers to detect stale claims: a claim signed with epoch=N is revoked once the Discovery Record shows epoch=N+1, unless the claim's expiry predates the rotation event. Operators SHOULD NOT rotate keys more frequently than once per DNS TTL period. Frequent rotation increases the risk of verification failures during the overlap window.

Replay and Freshness Discovery Records are public and cacheable. An attacker who observes a Discovery Record can replay it, but this provides no advantage: the record contains no secrets, and replaying a legitimate record simply directs clients to the legitimate server. The epoch field provides freshness for signed artifacts. A verifier that encounters a claim with an epoch lower than the current Discovery Record epoch knows the signing key has been rotated and can apply epoch-based revocation. MCP servers that issue signed attestations SHOULD include a nonce and timestamp in each attestation. Verifiers SHOULD reject attestations older than a policy-defined maximum age (e.g., 300 seconds for session-bound attestations).

Denial of Service An attacker who can inject DNS responses (absent DNSSEC) could publish a Discovery Record pointing to an attacker-controlled server, or could inject NXDOMAIN to suppress discovery. The TLS requirement mitigates server impersonation (the attacker cannot obtain a valid certificate), but suppression of discovery cannot be mitigated at the DNS layer alone. Clients SHOULD implement the HTTPS fallback described in Section 4 to reduce the impact of DNS-layer suppression.

Zone Control and Record Authenticity The _mcp. label is under the Policy Domain's own DNS zone. Publication of the Discovery Record is therefore an authenticated act: only an entity with write access to the zone can create or modify the record. This matches the trust model of DKIM, MTA-STS, and DMARC, where the zone holder's control of the DNS record is the root of authority. Delegated subdomains (e.g., _mcp.dept.example.com) inherit the trust properties of the subdomain's zone. If dept.example.com is delegated to a separate zone with its own set of nameservers, the operator of that zone controls its Discovery Record independently. Clients MUST NOT assume that a Discovery Record at a subdomain is authorized by the parent domain's zone operator.

Attestation Scope as Security Boundary The attest field provides a structural defense against capability creep. By publishing the set of attestation types it will issue, a domain establishes an upper bound that verifiers can enforce. An MCP server that publishes attest=employ,contract cannot legitimately issue a director attestation, and verifiers MUST reject such claims even if the cryptographic signature is valid. This mechanism transforms the DNS record into a capability declaration: the domain operator explicitly consents to a bounded set of claim types, and verifiers enforce that boundary. The operator can expand or contract the attest set at any time by updating the DNS record; the change takes effect at DNS TTL expiry.

Multi-Server Key Consistency When multiple Discovery Records are published at the same DNS name (for failover), the records MAY declare different pk values (one per server) or the same pk value (shared key). Operators using distinct keys per server MUST ensure that all servers share the same epoch. A split-epoch configuration (where different servers advertise different epoch values) creates ambiguous revocation semantics and MUST be avoided.

Privacy Considerations

DNS Query Metadata DNS queries are visible to the recursive resolver, and potentially to on-path observers between the client and the resolver. A client resolving _mcp.example.com reveals to its resolver that it intends to interact with example.com via MCP. Clients concerned with query metadata leakage SHOULD use DNS-over-HTTPS (DoH) [RFC8484] or DNS-over-TLS (DoT) [RFC7858] and SHOULD prefer resolvers that publish strong privacy policies (e.g., no query logging, GDPR compliance).

Discovery Record Content The Discovery Record itself is public by design. It contains no per-user information. The fields describe the MCP server's endpoint, transport, and capabilities -- all of which are properties of the domain operator, not of any individual user. Operators who wish to keep the existence of their MCP server private SHOULD NOT publish a Discovery Record and SHOULD rely on out-of-band configuration or authenticated HTTPS-based discovery.

Individual Privacy The Discovery Record is a domain-level record. This specification does not define per-user DNS records and explicitly discourages them. Individual identity resolution, where applicable, occurs at the MCP application layer behind the server endpoint, subject to application-level consent and access control mechanisms that are outside the scope of this document. A domain that publishes a Discovery Record does not reveal anything about the individuals associated with that domain. The server behind the endpoint determines what information, if any, is disclosed about individuals, and under what conditions.

Caching and Linkability Clients that cache Discovery Record metadata (including pk bindings) should be aware that cached state can be used for cross-session linkability if the cache is not partitioned by context. Implementations SHOULD partition Discovery Record caches by the requesting context (e.g., per-conversation or per-user) to prevent cross-context tracking.

Identity Assurance Decay Implementations SHOULD NOT assume that a valid Discovery Record at time t_0 implies identity assurance at time t_1 > t_0. The identity field framework of formalises this as the identity light-cone: outside the light-cone boundary, the infrastructure's model of the attesting entity is based on stale posterior estimates, and assurance confidence degrades at a rate determined by the propagation characteristics of the underlying identity infrastructure. Concretely: a DNS-advertised identity record cached for the full TTL without re-attestation approaches maximum-entropy assurance at the TTL boundary. Implementations relying on identity claims for access control decisions SHOULD treat TTL as an assurance-decay parameter, not merely a caching directive.

Scope as Privacy Boundary The scope field is a privacy boundary declaration in the sense of : it restricts the identity dimensions exposed at the advertised endpoint to those explicitly listed. Implementations that expand scope beyond the declared value -- inferring capability from context, caching undeclared capability assertions, or propagating identity information across scope boundaries -- violate the consent architecture that the deploying identity infrastructure is designed to preserve. Such violations constitute a security failure independent of whether any cryptographic mechanism is breached.

IANA Considerations

Underscored DNS Node Name Registration This document requests IANA to register the following entry in the "Underscored and Globally Scoped DNS Node Names" registry established by : +--------+------------+-----------------------------+ | RR Type| _NODE NAME | Reference | +--------+------------+-----------------------------+ | TXT | _mcp | [this document], Section 3 | +--------+------------+-----------------------------+ The _mcp label is used to publish Discovery Records for Model Context Protocol servers as defined in Section 3 of this document.

No New RR Type This document does not request registration of a new DNS resource record type. The Discovery Record uses the existing TXT RR type. The historical experience of SPF , which registered a dedicated RR type 99 that was subsequently deprecated due to lack of deployment, strongly argues against proposing a new RR type for MCP discovery. TXT records are universally supported by DNS operators, resolvers, management interfaces, and CDN-fronted services.

Version Registry This document defines the version tag v=mcp1. Future versions of the Discovery Record format (e.g., v=mcp2) SHOULD be coordinated with the Agentic AI Foundation's MCP specification process . This document recommends that the Agentic AI Foundation establish a version registry for the v=mcpN tag, with IETF liaison for cross-registry coordination if an IETF working group is chartered for MCP discovery.

Examples This section provides non-normative examples of Discovery Records for common deployment scenarios.

Minimal Record The simplest valid Discovery Record contains only the version and endpoint URL: _mcp.example.com. IN TXT "v=mcp1; url=https://mcp.example.com" A client discovering this record connects to https://mcp.example.com using the default streamable-http transport with no authentication requirement and no key pinning. This is appropriate for public MCP servers offering openly available tools.

Identity-Bound Record A server that issues signed attestations and participates in identity resolution publishes a full record with key pinning, epoch tracking, and attestation scope: _mcp.truealter.com. IN TXT ( "v=mcp1; url=https://mcp.truealter.com; " "proto=streamable-http; " "pk=ed25519:dGhpcyBpcyBhIHNhbXBsZSBrZXk; " "epoch=3; cap=E4; " "attest=employ,contract,alumnus,member; " "scope=tools,resources,prompts,identity; " "ext=https://truealter.com/.well-known/alter-ext.json" ) Clients connecting to this server:

1. Verify the Ed25519 key against the TLS session or HTTP Message Signatures.
2. Know that signed claims carry kid=ed25519:dGhpc...#3 and can be revoked by incrementing the epoch.
3. Can fetch the extension document for protocol-specific metadata (e.g., identity resolution, payment addresses).
4. Know the server supports identity resolution (scope=...identity) and that it is authorized to issue employment, contract, alumnus, and membership attestations.

Multi-Server Failover An operator running geographically redundant MCP servers publishes multiple records with distinct priorities: _mcp.bigcorp.com. IN TXT "v=mcp1; url=https://mcp-us.bigcorp.com; priority=10; pk=ed25519:USKeyHere; epoch=5" _mcp.bigcorp.com. IN TXT "v=mcp1; url=https://mcp-eu.bigcorp.com; priority=20; pk=ed25519:EUKeyHere; epoch=5" _mcp.bigcorp.com. IN TXT "v=mcp1; url=https://mcp-ap.bigcorp.com; priority=30; pk=ed25519:APKeyHere; epoch=5" Clients sort by priority and attempt the US endpoint first, failing over to EU, then AP. All three servers share the same epoch, ensuring consistent revocation semantics. The pk values MAY differ across servers (each server holds its own keypair) or MAY be identical (shared key, centralized signing).

Handle-Scoped Record A subdomain-scoped record enables sovereign individuals who operate their own domain to publish a personal MCP endpoint: _mcp.blake.alter.dev. IN TXT "v=mcp1; url=https://alter.dev/~blake/mcp; scope=identity; pk=ed25519:PersonalKeyHere; epoch=1" This record declares that identity queries for blake within the alter.dev domain should be directed to https://alter.dev/~blake/mcp. Handle-scoped records are optional and are intended for the specific use case of individuals who operate their own identity endpoint. The common case -- where individuals are resolved through an organizational MCP server -- requires only a single record at the organizational domain.

Interoperability

Relationship to HTTPS RR (RFC 9460) The SVCB/HTTPS DNS record type provides service binding with extensible key-value parameters, and could in principle carry MCP discovery metadata. However, as of 2026, HTTPS RR deployment is uneven, DNS management interfaces expose it inconsistently, and no MCP-specific SvcParamKey has been registered. This specification uses TXT records for Phase 1 deployment. A future revision MAY define an MCP-specific SvcParamKey for HTTPS RR, enabling operators to publish MCP metadata alongside HTTPS service parameters. Such a revision would be appropriate once HTTPS RR resolver and management tooling reaches the deployment level currently enjoyed by TXT records.

Relationship to DID Methods The W3C Decentralized Identifier (DID) ecosystem includes methods that resolve via DNS. did:web resolves to https://<domain>/.well-known/did.json. did:dns is in early development. The Discovery Record is not a DID method and does not produce DID Documents. However, the pk field in a Discovery Record can serve as a verification method reference in a DID Document, and a did:web document can reference the MCP endpoint declared in the Discovery Record. The two mechanisms are complementary: DID provides a general-purpose identifier framework; the Discovery Record provides MCP-specific endpoint discovery.

Relationship to .well-known/mcp The .well-known/mcp endpoint proposed in SEP-1960 and the Server Card proposed in SEP-1649 are the HTTPS-based discovery mechanisms for MCP. This specification defines the DNS-based discovery layer and explicitly designates the .well-known/mcp endpoint as the fallback when DNS discovery fails or returns no result. The intended deployment is layered: DNS provides the fast, cacheable bootstrap; the Server Card provides the full metadata. Operators SHOULD publish both a Discovery Record and a Server Card. Clients SHOULD attempt DNS discovery first and fall back to HTTPS discovery.

Relationship to Agent Identity and Discovery (AID) The Agent Identity and Discovery protocol uses _agent.<domain> TXT records with a v=aid1 version tag to provide cross-protocol meta-discovery (MCP, A2A, OpenAPI, and others). The _mcp. record defined in this document is MCP-specific and provides richer MCP-native fields (epoch, attest, scope, proto). The two mechanisms are complementary. _agent.<domain> is the cross-protocol meta layer; _mcp.<domain> is the MCP-specific refinement. A domain MAY publish both records. A client that discovers MCP support via _agent.<domain> MAY subsequently query _mcp.<domain> for detailed MCP metadata.

Relationship to Google Agent-to-Agent Protocol (A2A) The Google Agent-to-Agent Protocol (A2A) uses /.well-known/agent-card.json for HTTPS-based agent discovery. A2A does not currently define a DNS-based discovery mechanism. The _mcp. Discovery Record is MCP-specific and does not apply to A2A endpoints. However, the _mcp. pattern is structurally generalizable: a future _a2a.<domain> TXT record could follow the same conventions (version prefix, URL field, key pinning, priority) to provide DNS-based discovery for A2A servers. This document does not define such a record but notes the pattern's applicability.

Coexistence with SEP-1959 MCP SEP-1959 proposes DNS-based MCP server identity verification using a TXT record format with fields including auth, transport, and sec. This document defines a complementary but more general mechanism. The key differences are:

• This document defines epoch for key-lifecycle management, which SEP-1959 does not address.
• This document defines attest for attestation scope bounding, which SEP-1959 does not address.
• This document defines a formal ABNF grammar and explicit forward-compatibility rules.

The authors intend to coordinate with the SEP-1959 author to merge or align the two proposals. Where the field semantics overlap (version, URL, transport, key), convergence on a single field vocabulary is desirable.

Implementation Status This section records the status of known implementations at the time of publication, per [RFC7942]. ALTER (https://truealter.com) maintains a reference implementation comprising:

• A live Discovery Record at _mcp.truealter.com exercising the full field set including pk, epoch, attest, and ext.
• An MCP server responding to discovery-initiated connections with tool, resource, and identity-resolution capabilities.
• A verification CLI (alter-dns check <domain>) that resolves Discovery Records, validates key bindings, and reports endpoint reachability.

The implementation targets MCP specification version 2025-11 and uses streamable-http as the default transport.

References Normative References This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby ADministrative Management Domains (ADMDs) can explicitly authorize the hosts that are allowed to use their domain names, and a receiving host can check such authorization. This document obsoletes RFC 4408. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. SMTP MTA Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers (SPs) to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate. Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA. The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services. This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange. Agentic AI Foundation Informative References DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK] Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling. Originators of Internet Mail need to be able to associate reliable and authenticated domain identifiers with messages, communicate policies about messages that use those identifiers, and report about mail using those identifiers. These abilities have several benefits: Receivers can provide feedback to Domain Owners about the use of their domains; this feedback can provide valuable insight about the management of internal operations and the presence of external domain name abuse. DMARC does not produce or encourage elevated delivery privilege of authenticated email. DMARC is a mechanism for policy distribution that enables increasingly strict handling of messages that fail authentication checks, ranging from no action, through altered delivery, up to message rejection. This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. n.d. n.d. n.d. n.d. n.d. n.d. Alter Meridian Pty Ltd

Discovery Pseudocode The following pseudocode illustrates the discovery algorithm defined in Section 4. It is non-normative. ``` function discover_mcp(origin_domain): # Step 1: Normalize domain = normalize(origin_domain) # lowercase, IDNA2008 function https_fallback(domain): # Try .well-known/mcp/server-card.json (SEP-1649) card_url = "https://" + domain + "/.well-known/mcp/server-card.json" card = https_get(card_url) if card is not None: return mcp_connect_from_card(card)

Change Log draft-morrison-mcp-dns-discovery-00 (April 2026):

• Initial submission.
• Defines _mcp.<domain> TXT record format with ABNF grammar.
• Defines discovery procedure with HTTPS fallback.
• Defines pk, epoch, attest, scope, cap, priority, ttl, and ext fields.
• Registers _mcp in the underscored DNS node name registry.

Normative References

• Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987.
• Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
• Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006.
• [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008.
• Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014.
• Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.
• Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A., and J. Jones, "SMTP MTA Strict Transport Security (MTA-STS)", RFC 8461, DOI 10.17487/RFC8461, September 2018.
• Crocker, D., "Scoped Interpretation of DNS Resource Records through 'Underscored' Naming of Attribute Leaves", BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019.
• Backman, A., Richer, J., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024.
• Agentic AI Foundation, "Model Context Protocol Specification", https://modelcontextprotocol.io, 2026.

Informative References

• [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005.
• [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005.
• [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005.
• [RFC4343] Eastlake 3rd, D., "Domain Name System (DNS) Case Insensitivity Clarification", RFC 4343, DOI 10.17487/RFC4343, January 2006.
• Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011.
• Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain- based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015.
• [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016.
• [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016.
• [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018.
• Schwartz, B., Bishop, M., and E. Nygren, "Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)", RFC 9460, DOI 10.17487/RFC9460, November 2023.
• "MCP Server Cards", Agentic AI Foundation, https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1649
• "DNS-Based MCP Server Identity Verification", Agentic AI Foundation, https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1959
• ".well-known/mcp Discovery Endpoint", Agentic AI Foundation, https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1960
• "MCP Server Cards (PR)", Agentic AI Foundation, https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2127
• Nemethi, et al., "Agent Identity and Discovery", Internet-Draft draft-nemethi-aid-agent-identity-discovery, https://datatracker.ietf.org/doc/draft-nemethi-aid-agent-identity-discovery/
• Serra, et al., "MCP Discovery URI", Internet-Draft draft-serra-mcp-discovery-uri, https://datatracker.ietf.org/doc/draft-serra-mcp-discovery-uri/

Authors' Addresses Blake Morrison Alter Meridian Pty Ltd Cronulla, NSW 2230 Australia Email: blake@truealter.com URI: https://truealter.com