Discovery of Model Context Protocol Servers via DNS TXT Records
draft-morrison-mcp-dns-discovery-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Author | Blake Morrison | ||
| Last updated | 2026-04-06 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-morrison-mcp-dns-discovery-00
Network Working Group B. Morrison
Internet-Draft Alter Meridian Pty Ltd
Intended status: Informational April 2026
Expires: 8 October 2026
Discovery of Model Context Protocol Servers via DNS TXT Records
draft-morrison-mcp-dns-discovery-00
Abstract
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
[RFC6376], SPF [RFC7208], DMARC [RFC7489], and MTA-STS [RFC8461], 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 3 October 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Morrison Expires 8 October 2026 [Page 1]
Internet-Draft MCP DNS Discovery April 2026
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.
Table of Contents
1. Status of This Memo . . . . . . . . . . . . . . . . . . . . . 3
2. Copyright Notice . . . . . . . . . . . . . . . . . . . . . . 3
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Record Format . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. DNS Location . . . . . . . . . . . . . . . . . . . . . . 6
5.2. ABNF Grammar . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Field Definitions . . . . . . . . . . . . . . . . . . . . 7
5.3.1. v (REQUIRED) . . . . . . . . . . . . . . . . . . . . 7
5.3.2. url (REQUIRED) . . . . . . . . . . . . . . . . . . . 7
5.3.3. proto (OPTIONAL) . . . . . . . . . . . . . . . . . . 8
5.3.4. pk (OPTIONAL) . . . . . . . . . . . . . . . . . . . . 8
5.3.5. epoch (OPTIONAL) . . . . . . . . . . . . . . . . . . 8
5.3.6. cap (OPTIONAL) . . . . . . . . . . . . . . . . . . . 9
5.3.7. attest (OPTIONAL) . . . . . . . . . . . . . . . . . . 9
5.3.8. scope (OPTIONAL) . . . . . . . . . . . . . . . . . . 10
5.3.9. priority (OPTIONAL) . . . . . . . . . . . . . . . . . 10
5.3.10. ttl (OPTIONAL) . . . . . . . . . . . . . . . . . . . 10
5.3.11. ext (OPTIONAL) . . . . . . . . . . . . . . . . . . . 11
5.4. Forward Compatibility . . . . . . . . . . . . . . . . . . 11
5.5. Multi-String Concatenation . . . . . . . . . . . . . . . 11
6. Discovery Procedure . . . . . . . . . . . . . . . . . . . . . 11
6.1. Input . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 12
6.3. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7.1. DNS Response Integrity . . . . . . . . . . . . . . . . . 13
7.2. TLS as Primary Authentication . . . . . . . . . . . . . . 14
7.3. Key Pinning via the pk Field . . . . . . . . . . . . . . 14
7.4. Key Rotation . . . . . . . . . . . . . . . . . . . . . . 15
7.5. Replay and Freshness . . . . . . . . . . . . . . . . . . 15
7.6. Denial of Service . . . . . . . . . . . . . . . . . . . . 16
7.7. Zone Control and Record Authenticity . . . . . . . . . . 16
7.8. Attestation Scope as Security Boundary . . . . . . . . . 16
7.9. Multi-Server Key Consistency . . . . . . . . . . . . . . 17
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
8.1. DNS Query Metadata . . . . . . . . . . . . . . . . . . . 17
8.2. Discovery Record Content . . . . . . . . . . . . . . . . 17
8.3. Individual Privacy . . . . . . . . . . . . . . . . . . . 17
Morrison Expires 8 October 2026 [Page 2]
Internet-Draft MCP DNS Discovery April 2026
8.4. Caching and Linkability . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9.1. Underscored DNS Node Name Registration . . . . . . . . . 18
9.2. No New RR Type . . . . . . . . . . . . . . . . . . . . . 18
9.3. Version Registry . . . . . . . . . . . . . . . . . . . . 18
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Minimal Record . . . . . . . . . . . . . . . . . . . . . 19
10.2. Identity-Bound Record . . . . . . . . . . . . . . . . . 19
10.3. Multi-Server Failover . . . . . . . . . . . . . . . . . 19
10.4. Handle-Scoped Record . . . . . . . . . . . . . . . . . . 20
11. Interoperability . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Relationship to HTTPS RR (RFC 9460) . . . . . . . . . . 20
11.2. Relationship to DID Methods . . . . . . . . . . . . . . 21
11.3. Relationship to .well-known/mcp . . . . . . . . . . . . 21
11.4. Relationship to Agent Identity and Discovery (AID) . . . 21
11.5. Relationship to Google Agent-to-Agent Protocol (A2A) . . 21
11.6. Coexistence with SEP-1959 . . . . . . . . . . . . . . . 22
12. Implementation Status . . . . . . . . . . . . . . . . . . . . 22
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
13.1. Normative References . . . . . . . . . . . . . . . . . . 23
13.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Discovery Pseudocode . . . . . . . . . . . . . . . . 24
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 26
Appendix C. Normative References . . . . . . . . . . . . . . . . 26
Appendix D. Informative References . . . . . . . . . . . . . . . 27
Appendix E. Authors' Addresses . . . . . . . . . . . . . . . . . 29
1. 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 6, 2026.
2. Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Morrison Expires 8 October 2026 [Page 3]
Internet-Draft MCP DNS Discovery April 2026
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.
3. Introduction
Model Context Protocol (MCP) [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
[SEP-1649] and SEP-1960 [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 [RFC6376] publishes Ed25519/RSA public keys at
<selector>._domainkey.<domain> for email authentication.
* SPF [RFC7208] publishes sender policy at the domain apex.
* DMARC [RFC7489] publishes alignment and reporting policy at
_dmarc.<domain>.
* MTA-STS [RFC8461] 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.
Morrison Expires 8 October 2026 [Page 4]
Internet-Draft MCP DNS Discovery April 2026
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 [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 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 [RFC7208] 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 [RFC9460] 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.
3.1. 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 [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Morrison Expires 8 October 2026 [Page 5]
Internet-Draft MCP DNS Discovery April 2026
4. Terminology
MCP Model Context Protocol, as specified by the Agentic AI
Foundation [MCP].
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 [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.
5. Record Format
5.1. DNS Location
The Discovery Record is a DNS TXT resource record [RFC1035] 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
[RFC8552] 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.
Morrison Expires 8 October 2026 [Page 6]
Internet-Draft MCP DNS Discovery April 2026
5.2. 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=" 1_DIGIT cap-
field = "cap=" cap-csv attest-field = "attest=" attest-csv scope-
field = "scope=" scope-csv priority-field = "priority=" 1_DIGIT 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 / "-" / "_" ) ```
5.3. Field Definitions
5.3.1. 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.
5.3.2. 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.
Morrison Expires 8 October 2026 [Page 7]
Internet-Draft MCP DNS Discovery April 2026
5.3.3. 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.
5.3.4. pk (OPTIONAL)
Ed25519 public key for endpoint verification, encoded as
ed25519:<base64url> where <base64url> is the raw 32-byte public key
encoded per [RFC4648] 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 [RFC9421] on MCP
responses.
3. The key declared in the Server Card [SEP-1649] served by the
endpoint.
If verification fails, the client MUST treat the server as untrusted
and SHOULD NOT proceed with the MCP session.
5.3.5. 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:
Morrison Expires 8 October 2026 [Page 8]
Internet-Draft MCP DNS Discovery April 2026
* 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.
5.3.6. 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.
5.3.7. 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.
Morrison Expires 8 October 2026 [Page 9]
Internet-Draft MCP DNS Discovery April 2026
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.
5.3.8. 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.
5.3.9. 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.
5.3.10. 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.
Morrison Expires 8 October 2026 [Page 10]
Internet-Draft MCP DNS Discovery April 2026
5.3.11. 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.
5.4. 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).
5.5. Multi-String Concatenation
DNS TXT resource records are limited to 255 bytes per character-
string [RFC1035]. 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 [RFC7208]
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.
6. 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.
Morrison Expires 8 October 2026 [Page 11]
Internet-Draft MCP DNS Discovery April 2026
6.1. 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.
6.2. 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.
Morrison Expires 8 October 2026 [Page 12]
Internet-Draft MCP DNS Discovery April 2026
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
[SEP-1649], or https://<origin>/.well-known/mcp per SEP-1960
[SEP-1960]. If fallback succeeds, proceed with the MCP session.
If fallback fails, discovery has failed.
6.3. 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).
7. Security Considerations
7.1. 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.
Morrison Expires 8 October 2026 [Page 13]
Internet-Draft MCP DNS Discovery April 2026
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.
7.2. 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.
7.3. 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.
Morrison Expires 8 October 2026 [Page 14]
Internet-Draft MCP DNS Discovery April 2026
7.4. 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.
7.5. 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).
Morrison Expires 8 October 2026 [Page 15]
Internet-Draft MCP DNS Discovery April 2026
7.6. 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.
7.7. 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.
7.8. 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.
Morrison Expires 8 October 2026 [Page 16]
Internet-Draft MCP DNS Discovery April 2026
7.9. 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.
8. Privacy Considerations
8.1. 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).
8.2. 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.
8.3. 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.
Morrison Expires 8 October 2026 [Page 17]
Internet-Draft MCP DNS Discovery April 2026
8.4. 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.
9. IANA Considerations
9.1. 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 [RFC8552]:
+--------+------------+-----------------------------+ | 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.
9.2. 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 [RFC7208], 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.
9.3. 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 [MCP]. 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.
Morrison Expires 8 October 2026 [Page 18]
Internet-Draft MCP DNS Discovery April 2026
10. Examples
This section provides non-normative examples of Discovery Records for
common deployment scenarios.
10.1. 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.
10.2. 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.
10.3. Multi-Server Failover
An operator running geographically redundant MCP servers publishes
multiple records with distinct priorities:
Morrison Expires 8 October 2026 [Page 19]
Internet-Draft MCP DNS Discovery April 2026
_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).
10.4. 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.
11. Interoperability
11.1. Relationship to HTTPS RR (RFC 9460)
The SVCB/HTTPS DNS record type [RFC9460] 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.
Morrison Expires 8 October 2026 [Page 20]
Internet-Draft MCP DNS Discovery April 2026
11.2. 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.
11.3. Relationship to .well-known/mcp
The .well-known/mcp endpoint proposed in SEP-1960 [SEP-1960] and the
Server Card proposed in SEP-1649 [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.
11.4. Relationship to Agent Identity and Discovery (AID)
The Agent Identity and Discovery protocol [AID] 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.
11.5. 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.
Morrison Expires 8 October 2026 [Page 21]
Internet-Draft MCP DNS Discovery April 2026
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.
11.6. Coexistence with SEP-1959
MCP SEP-1959 [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.
12. 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.
Morrison Expires 8 October 2026 [Page 22]
Internet-Draft MCP DNS Discovery April 2026
13. References
13.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", RFC 7208,
DOI 10.17487/RFC7208, April 2014,
<https://www.rfc-editor.org/info/rfc7208>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8461] 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,
<https://www.rfc-editor.org/info/rfc8461>.
[RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource
Records through "Underscored" Naming of Attribute Leaves",
BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019,
<https://www.rfc-editor.org/info/rfc8552>.
[RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP
Message Signatures", RFC 9421, DOI 10.17487/RFC9421,
February 2024, <https://www.rfc-editor.org/info/rfc9421>.
[MCP] Agentic AI Foundation, "Model Context Protocol
Specification", 2026, <https://modelcontextprotocol.io>.
13.2. Informative References
Morrison Expires 8 October 2026 [Page 23]
Internet-Draft MCP DNS Discovery April 2026
[RFC6376] 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,
<https://www.rfc-editor.org/info/rfc6376>.
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<https://www.rfc-editor.org/info/rfc7489>.
[RFC9460] 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, <https://www.rfc-editor.org/info/rfc9460>.
[SEP-1649] "MCP Server Cards", n.d.,
<https://github.com/modelcontextprotocol/
modelcontextprotocol/issues/1649>.
[SEP-1959] "DNS-Based MCP Server Identity Verification", n.d.,
<https://github.com/modelcontextprotocol/
modelcontextprotocol/issues/1959>.
[SEP-1960] ".well-known/mcp Discovery Endpoint", n.d.,
<https://github.com/modelcontextprotocol/
modelcontextprotocol/issues/1960>.
[SEP-2127] "MCP Server Cards (PR)", n.d.,
<https://github.com/modelcontextprotocol/
modelcontextprotocol/pull/2127>.
[AID] "Agent Identity & Discovery", n.d.,
<https://datatracker.ietf.org/doc/draft-nemethi-aid-agent-
identity-discovery/>.
[SERRA] "MCP Discovery URI", n.d.,
<https://datatracker.ietf.org/doc/draft-serra-mcp-
discovery-uri/02/>.
Appendix A. 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
Morrison Expires 8 October 2026 [Page 24]
Internet-Draft MCP DNS Discovery April 2026
# Step 2: Construct query name
qname = "_mcp." + domain
# Step 3: Query DNS
response = dns_query(qname, type=TXT, prefer=DoH)
# Step 4: Handle response
if response.status == NXDOMAIN or response.answers == []:
return https_fallback(domain)
if response.status == SERVFAIL:
if retry_with_backoff(qname, type=TXT):
# retry succeeded, proceed
pass
else:
return https_fallback(domain)
# Step 5: Parse records
valid_records = []
for rdata in response.answers:
text = concatenate_strings(rdata)
fields = parse_semicolon_fields(text)
if fields[0] != "v=mcp1":
continue # discard non-mcp1 records
record = extract_fields(fields)
if not is_valid_https_url(record.url):
continue # discard malformed records
valid_records.append(record)
if valid_records == []:
return https_fallback(domain)
# Step 6: Sort by priority
valid_records.sort(key=lambda r: r.priority)
# Step 7: Connect
for record in valid_records:
try:
session = tls_connect(record.url)
if record.pk is not None:
if not verify_key(session, record.pk):
continue # key mismatch, try next
Morrison Expires 8 October 2026 [Page 25]
Internet-Draft MCP DNS Discovery April 2026
mcp = mcp_initialize(session, record.proto)
return mcp # discovery complete
except ConnectionError:
continue # try next record
# Step 8: All records failed
return https_fallback(domain)
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)
# Try .well-known/mcp (SEP-1960)
manifest_url = "https://" + domain + "/.well-known/mcp"
manifest = https_get(manifest_url)
if manifest is not None:
return mcp_connect_from_manifest(manifest)
return None # discovery failed ```
Appendix B. 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.
Appendix C. Normative References
* [RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November
1987.
* [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March
1997.
Morrison Expires 8 October 2026 [Page 26]
Internet-Draft MCP DNS Discovery April 2026
* [RFC4648] 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.
* [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI
10.17487/RFC7208, April 2014.
* [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.
* [RFC8461] 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.
* [RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource
Records through 'Underscored' Naming of Attribute Leaves", BCP
222, RFC 8552, DOI 10.17487/RFC8552, March 2019.
* [RFC9421] Backman, A., Richer, J., and M. Sporny, "HTTP Message
Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024.
* [MCP] Agentic AI Foundation, "Model Context Protocol
Specification", https://modelcontextprotocol.io, 2026.
Appendix D. 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.
Morrison Expires 8 October 2026 [Page 27]
Internet-Draft MCP DNS Discovery April 2026
* [RFC6376] 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.
* [RFC7489] 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.
* [RFC9460] 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.
* [SEP-1649] "MCP Server Cards", Agentic AI Foundation,
https://github.com/modelcontextprotocol/modelcontextprotocol/
issues/1649
* [SEP-1959] "DNS-Based MCP Server Identity Verification", Agentic
AI Foundation,
https://github.com/modelcontextprotocol/modelcontextprotocol/
issues/1959
* [SEP-1960] ".well-known/mcp Discovery Endpoint", Agentic AI
Foundation,
https://github.com/modelcontextprotocol/modelcontextprotocol/
issues/1960
* [SEP-2127] "MCP Server Cards (PR)", Agentic AI Foundation,
https://github.com/modelcontextprotocol/modelcontextprotocol/
pull/2127
* [AID] 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/
Morrison Expires 8 October 2026 [Page 28]
Internet-Draft MCP DNS Discovery April 2026
* [SERRA] Serra, et al., "MCP Discovery URI", Internet-Draft draft-
serra-mcp-discovery-uri, https://datatracker.ietf.org/doc/draft-
serra-mcp-discovery-uri/
Appendix E. Authors' Addresses
Blake Morrison Alter Meridian Pty Ltd Cronulla, NSW 2230 Australia
Email: blake@truealter.com URI: https://truealter.com
Morrison Expires 8 October 2026 [Page 29]