Discovery of Model Context Protocol Servers via DNS TXT Records

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 12 April 2027.¶

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.¶

Table of Contents

1. Introduction

Model Context Protocol (MCP) [MCP] is an open protocol for structured interaction between AI agents and tool-providing servers. A complete agent-to-organisation-to-individual interaction chain has three distinct discovery requirements:¶

1. Service discovery. Where is the MCP server endpoint? What transport does it speak? What cryptographic key authenticates it? The _mcp.<domain> record answers this.¶

2. Organisational identity bootstrap. Who is the organisation operating the server? What is its legal entity? Where is it registered? Under what regulatory frameworks does it operate, and which automated access pathways must it refuse to participate in? The _org-alter.<domain> record answers this.¶

3. Individual identity recognition. Who is the Sovereign-tier person bound to a ~handle hosted under the domain? What public key signs their statements? What append-only log anchors the lifecycle of their identity? How may their envelope be revoked? The _alter.<domain> record answers this.¶

The three questions are distinct. An MCP client may need to discover an endpoint without caring about the operator's identity or any individual handle. An onboarding wizard installing an org-alter instance may need to read the operator's identity without caring (yet) about the MCP endpoint. A recognition verifier (resolving an alter:~alice URI) needs the individual envelope without necessarily invoking an MCP session. Conflating any two of these into a single TXT record would force every consumer to parse fields it does not need and would crowd the 255-octet character-string limit. Splitting them across three underscore-prefixed labels mirrors the pattern established by DKIM [RFC6376] (<selector>._domainkey.<domain>) and DMARC [RFC9989] (_dmarc.<domain>), where each record serves a single semantic purpose. SPF [RFC7208] and MTA-STS [RFC8461] set the same precedent for carrying policy in a TXT record under a reserved label.¶

This revision is fully backward-compatible with revisions 01 and 02. Implementations that consume only the _mcp.<domain> record continue to work unchanged. Implementations that wish to bootstrap an org-alter identity may additionally query _org-alter.<domain>. Implementations that wish to recognise an individual ~handle may additionally query _alter.<domain>.¶

This document stands alone. All three record formats (Section 5, Section 6, Section 7), all three procedures (Section 12.1, Section 12.2, Section 12.3), the signing input (Section 7.4) and the caching rules (Section 13) are given here in full. An implementer needs no other document in this series. Revisions 01 and 02 are cited where this document records what they said, and are cited informatively, because nothing here depends on fetching them.¶

The envelope published at _alter.<zone> is the handle-holder's own declaration, signed by their Ed25519 key and verifiable by any client with access to a DNSSEC-validating recursive resolver. It also carries a reference to an IdentityLog root, and Section 10 sets out what that reference does and does not establish.¶

2. Terminology

Envelope

An Ed25519-signed JSON object binding a ~handle to a public key, an IdentityLog root reference, an inception timestamp, a revocation hash commitment, a signature algorithm tag, a detached signature, and a caveats array. The TXT grammar that carries the seven required envelope fields across DNS, and the signing input over which they are verified, are specified in Section 7 of this document.¶

~handle

A Sovereign-tier identifier, leading tilde mandatory (e.g. ~alice). Bot-tier handles carry a .bot suffix (e.g. ~example-bot.bot); Instrument-tier handles use the prefix ~cc- (e.g. ~cc-example-model). An Instrument-tier handle identifies an instrument whose acts are attributed to the Sovereign that operates it; it is not an independent handle (Section 8.5 of [MORRISON-IFT]). After the tilde, a handle begins with a letter and continues with letters, digits, "-" and "."; it never contains "_". An organisation's handle may therefore be dotted, as in ~example.com. The grammar is the handle-name of [ALTER-URI], restated in Section 7.2, and the tier is read from the lexical form alone. A dotted handle is not a domain name, and the Handle-Domain Confusion consideration of [ALTER-URI] applies.¶

IdentityLog

An append-only transparency log recording envelope lifecycle events (mint, caveat-add, revocation, key-rotation), whose root the ilr= field of Section 7 references. The log's cadence, its witness protocol, and the client profile for checking it are NOT specified by this document and are not yet specified anywhere a reader can fetch. Section 10 states what a resolver may and may not conclude from ilr= in the meantime.¶

Recognition

The act of a resolver observing and verifying an envelope on cryptographic merit. A published record is an assertion the resolver may verify or reject.¶

DNSSEC Validation

The act of an authenticating DNS resolver verifying the RRSIG chain from the root trust anchor to the TXT RRset, per [RFC4033], [RFC4034], and [RFC4035], and setting the AD bit on the response delivered to the stub client.¶

DANE TLSA Pin

A DNS TLSA resource record [RFC6698] binding a server's leaf TLS certificate (or the public key therein) to the zone that hosts the envelope. In this document, the pin applies to the MCP endpoint at mcp.<zone>.¶

alter: URI

A URI scheme for dispatchable ~handle references, specified in [ALTER-URI] and provisionally registered with IANA on 5 October 2026 per [RFC7595] Section 4. Handler guidance is given in Section 11 of this document. Where this document names a ~handle in prose as a reference, it is written as an alter: URI, for example alter:~alice. The h field of Section 7.3.2 carries the bare form its grammar defines, and the value ~alice corresponds to the URI alter:~alice.¶

The terms Org-Identity Record, Identity Bootstrap, Canonical Entity Identifier and Regulatory Refusal Marker carry the meanings given by Section 6 and Section 12.2.¶

3. Related Work

Several drafts now publish agent discovery data in DNS, with overlapping vocabularies.¶

Two of them are called AID and they are different documents. [AGENT-AID] is "Agent Identity and Discovery", and [DNS-AID] is "DNS for AI Discovery".¶

[AGENT-AID] is the closest neighbour to the service-discovery record of this document, and it came first. It publishes a TXT record at _agent.<domain> carrying a leading v=aid2 version tag and semicolon-delimited key=value pairs, which give the endpoint URI (u), a protocol token (p), an authentication hint (a), and optionally an Ed25519 public key for endpoint proof (k), carried as an unpadded base64url JWK x value whose JWK thumbprint [RFC7638] is the HTTP Message Signature [RFC9421] keyid. The earlier v=aid1 format, with its i rotation identifier, stays valid through [AGENT-AID]'s compatibility window. The _mcp record of Section 5 reaches the same three facts, an endpoint, a protocol, and a key, in an underscore-prefixed TXT record with a leading version tag and semicolon-delimited pairs. The _mcp record derives its pattern from DKIM [RFC6376]. [AGENT-AID] published its record first, in March 2026.¶

The two can be published together. [AGENT-AID] gives where an agent is and which protocol to speak to it. The _mcp record gives an MCP endpoint's transport, authentication, capability scope and key epoch, and the _org-alter record of Section 6 gives the legal entity behind the endpoint, its registry identifier, operating regions and regulatory refusal markers. A client that learns p=mcp from _agent.<domain> may also look up _mcp.<domain>.¶

The keys bind different things, so publishing both is not a duplication. The k of [AGENT-AID] binds a key to an endpoint, and proves control of the server that answers. The _alter and _org-alter records bind a key to a ~handle or to a legal entity, with a log root and a revocation commitment.¶

[DNS-AID] specifies discovery of AI agents through DNS. It carries connectivity in SVCB records with TXT as a fallback, an alpn parameter that may hold the transport, an application-layer agent protocol, or both (alpn=mcp,h2,h3), and an optional bap parameter for the agent protocol alone, so that consumers can match on the agent protocol without parsing transports out of alpn. It predates this document's treatment of the same question. Both operate over unicast DNS. DNS-AID addresses agent discovery generally, while this document addresses one protocol family and adds the identity records that carry a signed envelope.¶

[MDNS-AGENT] specifies zero-configuration discovery over mDNS and DNS-SD. Its proto parameter names the agent protocol family, and it defines exactly one value for it, proto=a2a, saying that A2A is the only instantiation included in that document and leaving other agent protocols to future work. It defines no registry for the key. This document uses proto with the same meaning. The owner names and service types of the two documents differ, so no record is shared between them.¶

[MDNS-ARCHITECT] publishes registered agents through standard A, SVCB, and SRV records at a registry, with a worked SVCB example that puts the agent protocol and the transport side by side (SVCB 0 mcp ... alpn=h2).¶

[SAIP] is a neighbour to the identity records of this document rather than to its service-discovery record. It publishes an agent's Ed25519 public key in an underscore-prefixed TXT record at _saip.<domain>, with a leading v= version tag, deriving its pattern, as this document does, from DKIM [RFC6376] and SPF [RFC7208]. Its Section 10, "Trust and Attestation Discovery", specifies that publication and the discovery of the key from it. The bindings differ. The _saip record binds a key to a vendor's declared network footprint, carrying authorised ASNs, authorised IP prefixes, and an expiry. The _alter record of Section 7 binds a key to a ~handle, with a log root and a revocation commitment. A deployment that wanted both could publish both, and nothing in either record's owner name or field set collides with the other.¶

The neighbouring drafts keep the agent protocol and the transport apart, each in its own way. [MDNS-AGENT] defines proto as the agent protocol identifier and never as a transport, and carries the connection data in the SRV record instead. [MDNS-ARCHITECT] defines no proto key at all, and keeps the agent protocol distinct from the wire protocol inside its SVCB record, the one in the mcp position and the other in alpn. Neither of them puts a transport where the agent protocol belongs. Revision 01 of this document did, and this document no longer does.¶

This document uses one parameter for the agent protocol family and a second, separate parameter for the transport or binding. The transport parameter is named transport because the Model Context Protocol specification already calls this axis by that name, so an MCP implementer meets one term, not two.¶

This document keeps a third axis separate again. transport names the binding (streamable-http, sse), and the wire protocol underneath it (h2, h3) is left to the alpn service parameter of SVCB and HTTPS records [RFC9460], where DNS already carries it. [DNS-AID] permits alpn to hold the transport, the agent protocol, or both. This document does not overload alpn in that way.¶

4. Why TXT rather than SVCB

[DNS-AID] carries its connectivity data in SVCB records, with TXT as a fallback, and [MDNS-ARCHITECT] uses SVCB. This document is the reverse, TXT is the primary carrier. The reason is the payload.¶

An _mcp record's value is almost entirely opaque tokens the resolver does not interpret, an endpoint URL, a public key, a capability list, an attestation scope. SVCB is useful when a resolver or a connection library acts on the parameters directly, selecting a transport, following an alpn, choosing a port. It adds a registered SvcParamKey per field and a priority-ordered target list. For a record whose fields are consumed by an MCP client after resolution, and not by the resolver, that machinery is overhead without a matching benefit, and a TXT string is the lighter carrier.¶

Where a field IS resolver-actionable, this document defers to SVCB rather than duplicating it. The wire protocol lives in the SVCB or HTTPS alpn parameter [RFC9460], never in this TXT record, for that reason. An operator who wants SVCB-based transport selection publishes an HTTPS record for the endpoint host in the ordinary way, and the two records coexist.¶

5. Record Format: _mcp.<domain> (Service Discovery)

This section defines the Discovery Record introduced in revision 00, in full.¶

_mcp.<policy-domain>. IN TXT "<record-value>"

mcp-record      = version *( ";" SP field )
version         = "v=mcp1"
field           = url-field / proto-field / transport-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
transport-field = "transport=" transport-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 "=" *qtext

https-uri       = "https://" *uri-char
uri-char        = %x21-3A / %x3C-7E
                ; printable ASCII, excluding ";" (%x3B) and SP.
                ; A URI carries no raw space, so admitting one here
                ; would let a url= value swallow the field after it.
qtext           = %x20-3A / %x3C-7E
                ; printable ASCII and SP, excluding ";" (%x3B),
                ; which delimits one field from the next.  A value
                ; that could contain ";" could swallow the delimiter.
algo            = "ed25519"
base64url       = 1*( ALPHA / DIGIT / "-" / "_" )
proto-value     = token
transport-value = 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 / "-" / "_" )

_mcp.example.com. IN TXT (
  "v=mcp1; url=https://mcp.example.com; "
  "pk=ed25519:LongBase64UrlEncodedPublicKeyValueHere; "
  "epoch=3; attest=employ,contract,alumnus; scope=tools,identity"
)

6. Record Format: _org-alter.<domain> (Identity Bootstrap)

This section defines the Org-Identity Record introduced in revision 02. It is given here in full.¶

_org-alter.<policy-domain>. IN TXT "<record-value>"

orgalter-record = version *( ";" SP field )
version       = "v=alter1"
field         = org-field / entity-field / entity-type-field /
                founded-field / regions-field / regulated-field /
                bootstrap-field / mcp-policy-field /
                epoch-field / pk-field / attest-field /
                ext-field / unknown-field

org-field        = "org=" text-value
entity-field     = "entity=" registry ":" text-value
entity-type-field = "entity-type=" text-value
founded-field    = "founded=" date-fullyear
regions-field    = "regions=" region-csv
regulated-field  = "regulated=" framework-csv
bootstrap-field  = "bootstrap=" https-uri
mcp-policy-field = "mcp-policy=" policy-token
epoch-field      = "epoch=" 1*DIGIT
pk-field         = "pk=" algo ":" base64url
attest-field     = "attest=" attest-csv
ext-field        = "ext=" https-uri
unknown-field    = token "=" *qtext

registry      = "abn" / "acn" / "ein" / "ch" / "cro" / "lei" / token
text-value    = 1*qtext
qtext         = %x20-3A / %x3C-7E
              ; printable ASCII and SP, excluding ";" (%x3B),
              ; which delimits fields.  A legal entity name carries
              ; spaces, so VCHAR alone cannot express one.
region-csv    = region-token *( "," region-token )
region-token  = 2ALPHA   ; ISO 3166-1 alpha-2
framework-csv = framework-token *( "," framework-token )
framework-token = "disp" / "itar" / "ear" / "hipaa" / "gdpr" /
                  "soc2" / "iso27001" / "iso42001" / "essential8" /
                  "aprs" / token
policy-token  = "open" / "refuse-automated" / "refuse-tenant" /
                "refuse-all" / token
date-fullyear = 4DIGIT [ "-" 2DIGIT [ "-" 2DIGIT ] ]
algo          = "ed25519"
base64url     = 1*( ALPHA / DIGIT / "-" / "_" )
https-uri     = "https://" *uri-char
uri-char      = %x21-3A / %x3C-7E
              ; printable ASCII, excluding ";" (%x3B) and SP.
              ; A URI carries no raw space.
token         = 1*( ALPHA / DIGIT / "-" / "_" )

org=Example Pty Ltd
org=Example Corporation

entity=abn:12345678901

regions=AU,NZ,SG

7. Record Format: _alter.<domain> (Envelope Publication)

This section defines the Envelope Publication record introduced in revision 03. The record publishes the seven required fields of the identity envelope (binding a ~handle to its public key, IdentityLog root, inception timestamp, revocation commitment, and detached signature, under a protocol version) at an underscore-prefixed label under the handle's hosting zone. The envelope schema admits an optional caveats array which is never carried in DNS; this document specifies no transport and no vocabulary for it, so under this document the array is always empty and the signature is computed over an empty array (Section 7.4). The signature algorithm is not a separate field. It is derived from the pk= prefix via the registry of Section 16.7, and enters the signing input under that derivation.¶

_alter.<zone>. IN TXT "<record-value>"

; Publisher emission.  A conformant publisher MUST emit this form.
alter-record   = version ";" SP handle-field
                 ";" SP pubkey-field
                 ";" SP ilr-field
                 ";" SP ts-field
                 ";" SP rev-field
                 ";" SP sig-field
                 *( ";" SP unknown-field )

; Resolver acceptance.  A conformant resolver MUST accept this form.
; The version field stays first.  The remaining six required fields
; may arrive in any order, each exactly once, interleaved with any
; number of unknown fields.
alter-accepted = version *( ";" SP accepted-field )
accepted-field = handle-field / pubkey-field / ilr-field
               / ts-field / rev-field / sig-field
               / unknown-field

version        = "v=alter1"
handle-field   = "h=" handle
pubkey-field   = "pk=" algo ":" base64url
ilr-field      = "ilr=" base64url     ; SHA-256 of IdentityLog root
ts-field       = "ts=" 1*DIGIT        ; inception_ts, Unix seconds
rev-field      = "rev=" base64url   ; SHA-256 of revocation pre-image
sig-field      = "sig=" base64url     ; Ed25519 detached signature
unknown-field  = token "=" *qtext

handle         = "~" handle-name
handle-name    = sovereign-name / bot-name / instrument-name
sovereign-name = ALPHA *( ALPHA / DIGIT / "-" / "." )
               ; Sovereign tier
bot-name       = ALPHA *( ALPHA / DIGIT / "-" / "." ) ".bot"
               ; Bot tier
instrument-name
               = "cc-" 1*( ALPHA / DIGIT / "-" / "." )
               ; Instrument tier
algo          = "ed25519"
base64url      = 1*( ALPHA / DIGIT / "-" / "_" )
token          = 1*( ALPHA / DIGIT / "-" / "_" )
qtext          = %x20-3A / %x3C-7E
               ; printable ASCII and SP, excluding ";" (%x3B),
               ; which delimits one field from the next.

pk=ed25519:<base64url-no-pad-32-bytes>

8. DNSSEC Requirement

The zone publishing an _alter.<domain> envelope record MUST be DNSSEC-signed per [RFC4033], [RFC4034], and [RFC4035]. Authoritative servers MUST respond with valid RRSIG coverage for the TXT RRset. Recursive resolvers handling queries for the envelope RRset MUST perform DNSSEC validation and MUST set the AD (Authenticated Data) bit on the response delivered to the stub client.¶

Stub clients (MCP clients, alter-runtime daemons, onboarding wizards, recognition verifiers) consuming _alter.<domain> envelope records MUST reject any response that lacks a set AD bit or that fails local RRSIG verification when operating in validating-stub mode. A record obtained over an unvalidated DNS path MUST be treated as unauthenticated TXT content. Treating it as an envelope is a downgrade vulnerability (Section 14.1).¶

This requirement is specific to _alter.<domain> records. DNSSEC is RECOMMENDED but not REQUIRED for _mcp.<domain> and _org-alter.<domain> records in this revision, for backward compatibility with revision 01 and revision 02 deployments. Future revisions of this document MAY promote DNSSEC to REQUIRED for the other two records once deployment data justifies the promotion.¶

9. DANE TLSA Pin

The MCP endpoint associated with a published envelope MUST carry a DANE TLSA resource record [RFC6698] binding the endpoint's leaf TLS certificate or SubjectPublicKeyInfo to the zone. The TLSA record MUST be published at:¶

_443._tcp.mcp.<zone>. IN TLSA <usage> <selector> <matching-type>
                              <cert-association-data>

Recommended parameters:¶

• Usage field. 3 (DANE-EE), pin the end-entity certificate directly, with no CA chain reliance. A publisher that explicitly requires CA-chain validation MAY use 1 (PKIX-EE) instead. Publishers MUST NOT use 0 (PKIX-TA) or 2 (DANE-TA) for the envelope record; the trust basis of the envelope is the end-entity leaf.¶

• Selector field. 1 (SPKI), pin the SubjectPublicKeyInfo so that certificate rotations preserving the keypair do not invalidate the record. Selector 0 (full certificate) MAY be used but requires more frequent TLSA republication.¶

• Matching-type field. 1 (SHA-256). Matching type 2 (SHA-512) is reserved for future revisions.¶

Clients establishing an MCP session at https://mcp.<zone>/ in conjunction with a resolved envelope MUST fetch and validate the TLSA record, MUST abort the TLS handshake on mismatch, and MUST NOT fall back to PKIX-only validation on TLSA failure.¶

The TLSA requirement is scoped to envelopes whose MCP session establishment is triggered by the resolved envelope (i.e. when the envelope resolution and the subsequent MCP session are part of a single recognition transaction). MCP clients that do not resolve an envelope (e.g. revision 01 clients consuming only _mcp.<domain>) are out of scope for this requirement and continue to operate under revision 01 rules.¶

10. IdentityLog Cross-Reference

The ilr= field of the _alter.<domain> record carries a base64url-no-pad SHA-256 digest of an IdentityLog root claimed by the publisher to have been witnessed at envelope creation.¶

What ilr= can and cannot establish:¶

• A resolver that has an independent view of the log MAY confirm that the root named in ilr= is one the log actually published.¶

• A resolver MUST NOT conclude from ilr= that the envelope in front of it is recorded in that log. The field carries a root and nothing else. It carries no leaf hash, no audit path, and no proof of inclusion, so no resolver can perform that check, and Section 14.3 sets out the forgery this permits.¶

• A resolver MUST NOT treat the presence, absence, or successful lookup of ilr= as a defence against envelope substitution.¶

The field is advisory. It is kept so that the wire format does not change.¶

The log's leaf hashing, tree construction, cadence, and witness protocol are not specified by this document, and a reader should not assume a specification exists.¶

The revocation check also crosses the IdentityLog. Where a resolver has access to the log's revocation surface, it MUST treat the envelope as revoked, and MUST NOT honour it regardless of the freshness of the TXT RRset, if a pre-image whose SHA-256 equals the rev= field has been revealed there.¶

A reader implementing from this document alone has no such access. The surface that carries reveals is not specified here and is not published anywhere a reader can fetch, so revocation status cannot presently be established from DNS alone.¶

11. alter: URI Scheme Cross-Reference

The URI scheme alter: provides a dispatchable surface for ~handle references: operating-system URI handlers (xdg-mime, LSHandlers, Windows registry, Android intent-filter) invoke a resolver that retrieves the envelope from DNS and verifies it per Section 12.3.¶

The scheme is specified in [ALTER-URI]. The registration sought is provisional, per [RFC7595] Section 4, under the procedure of [RFC7595] Section 7.2. The full registration body, scheme syntax, semantics, encoding considerations, interoperability and security considerations, author and change controller, is submitted to IANA separately from this document. The registration reference will be substituted when IANA assigns one.¶

Handlers invoked via alter: URIs MUST perform full envelope verification, DNSSEC validation (Section 8), and DANE TLSA binding (Section 9) when establishing any HTTPS session, before acting on any content or directive derived from the envelope.¶

12. Discovery and Bootstrap Procedures

The formats these procedures consume are given in full in Section 5, Section 6 and Section 7.¶

13. Caching

The rules for the first two records are those of [DNSDISC-01] and [DNSDISC-02], unchanged, with the key continuity rule of Section 13.1 added in revision 06, restated here so that a reader need not fetch either document to cache correctly.¶

For _mcp.<domain>, clients SHOULD cache the parsed record metadata for the duration of the DNS TTL. Where the record carries a ttl field, clients MAY extend the metadata cache to that duration, but MUST re-validate the underlying DNS record when the DNS TTL expires. A client that has connected to an MCP server and verified its pk SHOULD cache the verified key binding and re-validate it on subsequent connections, which is trust on first use with periodic re-verification against DNS. What the client does when that re-verification disagrees with what it cached is stated in Section 13.1.¶

For _org-alter.<domain>, records SHOULD be cached for the duration of the DNS TTL. An onboarding wizard typically reads the record once at install time and persists the resolved state locally, so the DNS record need not be re-read on every invocation. Wizards MAY re-read it on operator request, on epoch change detected by a periodic background poll, or on identity verification failure.¶

_alter.<domain> records SHOULD be cached for the duration of the DNS TTL. Resolvers MUST NOT serve stale envelope TXT past the RRset TTL unless they are themselves validating caches and can re-confirm RRSIG coverage on each serve. Recognition verifiers MAY cache successful verification results locally for a short interval (bounded above by the RRset TTL or 3600 seconds, whichever is smaller) to amortise the cost of repeated JCS and Ed25519 operations. A resolver that is able to perform the revocation check at all (Section 10 sets out why one working from this document alone is not) MUST re-run it on each recognition event, not on each cache refresh.¶

14. Security Considerations

The security considerations of [DNSDISC-01] Section 7 apply to the _mcp record, and those of [DNSDISC-02] Section 10 apply to the _org-alter record. The subsections below cover the _alter envelope record and the rules this document adds to the other two records.¶

15. Privacy Considerations

The privacy considerations of [DNSDISC-01] Section 8 apply to the _mcp record, and those of [DNSDISC-02] Section 11 apply to the _org-alter record. The subsections below cover the _alter envelope record.¶

16. IANA Considerations

17. Examples

This section provides non-normative examples of Envelope Records for common deployment scenarios.¶

_alter.example.com. 3600 IN TXT (
  "v=alter1; h=~alice; "
  "pk=ed25519:<EXAMPLE-pubkey-32B-base64url>; "
  "ilr=<EXAMPLE-identitylog-root-32B-base64url>; "
  "ts=1729123456; "
  "rev=<EXAMPLE-revocation-hash-32B-base64url>; "
  "sig=<EXAMPLE-ed25519-signature-64B-base64url>"
)

_alter.example.org. 3600 IN TXT "v=alter1; h=~alice; pk=..."
_alter.example.org. 3600 IN TXT "v=alter1; h=~bob; pk=..."
_alter.example.org. 3600 IN TXT "v=alter1; h=~carol.bot; pk=..."

_mcp.example.com.      IN TXT "v=mcp1; url=https://mcp.example.com/"
_org-alter.example.com. IN TXT "v=alter1; org=Example Org; ..."
_alter.example.com.     IN TXT "v=alter1; h=~alice; "
                               "pk=ed25519:...; ilr=...; "
                               "ts=...; rev=...; sig=..."
_443._tcp.mcp.example.com. IN TLSA 3 1 1 <sha256-of-spki>

18. Interoperability with Earlier Record Generations

A domain that publishes only an _mcp.<domain> record published under revision 01 continues to work with all revision 01, 02, and 03 clients. Where that record carries a transport value in proto, a client conforming to this revision reads it under steps A and B of Section 5.3.5 and reaches the same endpoint over the same transport. No republication is required for the record to keep working, and none is required for a record carrying a proto value that no revision recognised, because such a record was skipped by revision 01 clients and is skipped by these.¶

A domain that publishes _mcp.<domain> and _org-alter.<domain> (revision 02) continues to work with revision 02 clients and with clients conforming to this document, unchanged. A client conforming to this document may additionally query _alter.<domain> and MUST handle its absence gracefully, which is the common case and the recommended one: publication of that record is NOT RECOMMENDED (Section 7.1.1), so a conforming client should expect to find it absent and MUST NOT treat its absence as an error.¶

A domain that publishes only _alter.<domain> (envelope-only, no MCP server, no organisational record) is permitted by the grammar. The configuration is NOT RECOMMENDED per Section 7.1.1.¶

The three records are orthogonal along their semantic axes but share the zone's DNSSEC trust root. A resolver conforming to this document that resolves any subset of the three records treats each resolution as independent and does not fail the resolution of one record because another is absent or malformed.¶

19. Implementation Status

This section records the status of known implementations at the time of publication, per [RFC7942].¶

Deployed and resolvable in the truealter.com zone:¶

• _mcp.truealter.com, carrying v=mcp1 with url, proto, pk, epoch, and cap. This is the only record in the zone that a resolver can verify against this document today.¶

• _alter.truealter.com, carrying v=alter1. It does not carry the envelope field set (h, ilr, ts, rev, sig) and is therefore NOT an instance of the Envelope Record of Section 7. No conformant Envelope Record is published in this zone.¶

• _org-alter.truealter.com, carrying v=alter1 with org, entity, entity-type, founded, regions, mcp-policy, epoch, pk, and attest. It omits regulated and bootstrap. Its pk is the same key the _mcp record carries, as step 5 of Section 12.2.2 requires.¶

The zone is DNSSEC-signed, so the requirement of Section 8 is met by the operator. truealter.com publishes a key-signing key and a zone-signing key, both algorithm 13, and the parent zone holds a corresponding DS record.¶

Implemented in code, and NOT exercised against any conformant envelope, because none is published:¶

• A resolver and verification library implementing the JCS signing-input construction of Section 7.4 and the Ed25519 signature check. It conforms to this revision on the signing input and the signature check. It does NOT conform on two steps of the recognition procedure of Section 12.3: it still treats the IdentityLog cross-reference as fatal, where step 9 now says a resolver MUST NOT abort, and it still fetches caveats over HTTPS, which step 11 now places out of scope. Those two steps follow revision 04. It also does not yet perform the revocation check of step 12, so it does not refuse a claim signed under a revoked key, and it does not check the h field against the grammar of Section 7.3.2.¶

NOT deployed:¶

• _443._tcp.mcp.truealter.com does not resolve, so no DANE TLSA pin is published and the DANE binding of Section 9 is untested in deployment.¶

• There is no signed-tree-head federation and no witness-mirror network.¶

• No inclusion proof is generated or checked anywhere. The ilr field of Section 7.2 is published as a bare root with no proof attached. Section 14.3 sets out what that permits.¶

The Envelope Record of Section 7 therefore has NO conformant deployment at the time of writing, in this zone or any other known to the author. It is specified, implemented in a verifier, and unpublished.¶

The deployed _alter.truealter.com record carries none of the envelope fields that Section 7 defines, so it is not an instance of the Envelope Record and a resolver MUST NOT treat it as one.¶

The key continuity rule of Section 13.1 is new in revision 06. No implementation of it is claimed.¶

20. 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>.

[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, <https://www.rfc-editor.org/info/rfc4033>.

[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, <https://www.rfc-editor.org/info/rfc4034>.

[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, <https://www.rfc-editor.org/info/rfc4035>.

[RFC4343]

Eastlake 3rd, D., "Domain Name System (DNS) Case Insensitivity Clarification", RFC 4343, DOI 10.17487/RFC4343, January 2006, <https://www.rfc-editor.org/info/rfc4343>.

[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>.

[RFC5234]

Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.

[RFC6698]

Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, <https://www.rfc-editor.org/info/rfc6698>.

[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>.

[RFC7595]

Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015, <https://www.rfc-editor.org/info/rfc7595>.

[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>.

[RFC8785]

Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, <https://www.rfc-editor.org/info/rfc8785>.

[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>.

[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>.

[MCP]

Agentic AI Foundation, "Model Context Protocol Specification", 2026, <https://modelcontextprotocol.io>.

21. Informative References

[RFC7638]

Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, <https://www.rfc-editor.org/info/rfc7638>.

[AGENT-AID]

Nemethi, B., "Agent Identity and Discovery (AID)", 2026, <https://datatracker.ietf.org/doc/draft-nemethi-dawn-aid/>.

[DNS-AID]

Mozley, J., Williams, N., Sarikaya, B., Schott, R., and J. Damick, "DNS for AI Discovery", 2026, <https://datatracker.ietf.org/doc/draft-mozleywilliams-dnsop-dnsaid/>.

[MDNS-AGENT]

Jakab, L. and F. Brockners, "Zero-Configuration Agent Discovery", 2026, <https://datatracker.ietf.org/doc/draft-jakab-dawn-agent-discovery-mdns/>.

[MDNS-ARCHITECT]

Yao, J., Geng, G., Chen, M., and H. Li, "Agent Discovery Architecture", 2026, <https://datatracker.ietf.org/doc/draft-yao-dawn-agent-discovery-architect/>.

[SAIP]

Jovancevic, S., "SAIP: Signed Agent Identity Protocol", 2026, <https://datatracker.ietf.org/doc/draft-jovancevic-saip/>.

[ALTER-URI]

Morrison, B., "The 'alter' URI Scheme for Dispatchable ~handle References", Work in Progress, Internet-Draft, draft-morrison-alter-uri-scheme, 2026, <https://datatracker.ietf.org/doc/draft-morrison-alter-uri-scheme/>.

[DNSDISC-01]

Morrison, B., "Discovery of Model Context Protocol Servers via DNS TXT Records", Work in Progress, Internet-Draft, draft-morrison-mcp-dns-discovery-01, April 2026, <https://datatracker.ietf.org/doc/html/draft-morrison-mcp-dns-discovery-01>.

[DNSDISC-02]

Morrison, B., "Discovery of Model Context Protocol Servers via DNS TXT Records", Work in Progress, Internet-Draft, draft-morrison-mcp-dns-discovery-02, April 2026, <https://datatracker.ietf.org/doc/html/draft-morrison-mcp-dns-discovery-02>.

[DOMAIN-SET]

Barrett, T., Schaub, C., Barrett, A., and P. Kowalik, "The Domain Set Discovery Protocol (domain-set)", Work in Progress, Internet-Draft, draft-barrett-dnsop-domain-set-00, August 2026, <https://datatracker.ietf.org/doc/html/draft-barrett-dnsop-domain-set-00>.

[RFC2606]

Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, <https://www.rfc-editor.org/info/rfc2606>.

[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>.

[RFC6781]

Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC Operational Practices, Version 2", RFC 6781, DOI 10.17487/RFC6781, December 2012, <https://www.rfc-editor.org/info/rfc6781>.

[RFC9989]

Herr, T., Ed. and J. Levine, Ed., "Domain-Based Message Authentication, Reporting, and Conformance (DMARC)", RFC 9989, DOI 10.17487/RFC9989, May 2026, <https://www.rfc-editor.org/info/rfc9989>.

[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, <https://www.rfc-editor.org/info/rfc7858>.

[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, <https://www.rfc-editor.org/info/rfc7942>.

[RFC8484]

Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, <https://www.rfc-editor.org/info/rfc8484>.

[RFC9083]

Hollenbeck, S. and A. Newton, "JSON Responses for the Registration Data Access Protocol (RDAP)", STD 95, RFC 9083, DOI 10.17487/RFC9083, June 2021, <https://www.rfc-editor.org/info/rfc9083>.

[SEP-1649]

"MCP Server Cards", n.d., <https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1649>.

[SEP-1960]

".well-known/mcp Discovery Endpoint", n.d., <https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1960>.

[MORRISON-IFT]

Morrison, B., "Identity Field Theory: Toward a Physics of Being Known", 2026, <https://doi.org/10.6084/m9.figshare.31951383>.

Appendix A. Recognition Pseudocode

The following pseudocode illustrates the combined recognition procedure defined in Section 12.3. It is non-normative; the normative procedure is the twelve-step algorithm in the body of this document.¶

function recognise_envelope(handle, zone):
    # Step 1-2: Query + DNSSEC
    response = dns_query("_alter." + zone, type=TXT, prefer=DoH)
    if not response.ad_bit and not local_rrsig_validate(response):
        raise UnauthenticatedResponse

    # Step 3-5: Chunk reassembly + handle disambiguation + fields
    records = [parse_alter_record(rr) for rr in response.rrset]
    record = find(records, lambda r: r.h == handle)
    if record is None or record.v != "alter1":
        raise RecordNotFound
    for f in ["h", "pk", "ilr", "ts", "rev", "sig"]:
        if not hasattr(record, f):
            raise MalformedRecord

    # Step 6-7: Envelope reconstruction + JCS.  Keys are the TXT
    # field names; every value stays a string, ts included.
    alg = signature_alg_for_prefix(record.pk)   # Signature Algorithm
                                               # Registry
    envelope = {
        "v": record.v,
        "h": record.h,
        "pk": record.pk,
        "ilr": record.ilr,
        "ts": record.ts,
        "rev": record.rev,
        "caveats": [],
        "signature_alg": alg,
    }
    signing_input = jcs_canonicalise(envelope)

    # Step 8: signature verify under the derived algorithm
    if not signature_verify(alg, record.pk, record.sig,
                            signing_input):
        raise SignatureInvalid

    # Step 9: IdentityLog cross-ref. ADVISORY. Confirms the ROOT
    # was published; cannot confirm THIS envelope is under that
    # root, so a failure annotates and never aborts. See 12.3.
    ilr_root_seen = identitylog_root_published(record.ilr)

    # Step 10: DANE TLSA (if establishing MCP session)
    if establishing_mcp_session(zone):
        tlsa = dns_query("_443._tcp.mcp." + zone, type=TLSA)
        if not tlsa_matches_endpoint(tlsa, "mcp." + zone):
            raise TLSAFailure

    # Step 11: Caveats are OUT OF SCOPE for this document (Sec 12.3).
    # No transport and no vocabulary are specified, so the verified
    # envelope carries none and the signature is checked over [].
    caveats = []

    # Step 12: Revocation
    if identitylog_revocation_revealed(record.rev):
        raise EnvelopeRevoked

    return VerifiedEnvelope(record, caveats, ilr_root_seen)

Appendix B. Document History

draft-morrison-mcp-dns-discovery-08 (October 2026):¶

One change to a record format: the handle in the h field now follows the handle-name grammar of [ALTER-URI]. It begins with a letter, admits "." so that an organisation's handle such as ~example.com can be carried, and no longer admits "_". No change to any procedure. Two new requirements: a publisher SHOULD NOT publish an envelope for an Instrument-tier handle (Section 7.3.2), and a verifier MUST NOT honour a claim signed under the key of a revoked envelope (Section 7.3.6).¶

• Records in the Abstract, Section 2 and Section 16.2 that IANA provisionally registered the alter: scheme on 5 October 2026, and says in Section 19 that the verifier does not yet perform the step 12 revocation check or check the h grammar.¶

• States in Section 7.3.6, the Erasure paragraph of Section 7.1.1 and step 12 of Section 12.3 that revocation takes effect when the pre-image is revealed, with no grace period, and that every claim signed under the revoked envelope's key is invalid from that moment, whenever it was signed. The epoch rotation of the _mcp record keeps its per-claim expiry grace.¶

• Says in Section 7.3.8, Section 7.5 and Section 16.3 that a new envelope field is introduced only together with a new envelope version, and that resolvers ignore fields they do not know. Earlier text pointed new fields at a registry that does not exist.¶

• Replaces the notes at the head of Section 14 and Section 15, which said the revision 01 and 02 considerations were retained, with sentences citing [DNSDISC-01] Sections 7 and 8 and [DNSDISC-02] Sections 10 and 11. No consideration is added or removed.¶

• Strikes the sentence saying this document is what the [AGENT-AID] mcp protocol token defers to, at the request of the [AGENT-AID] author, whose registry points that token at the MCP specification. Section 3 now says only that a client that learns p=mcp may also look up _mcp.¶

• Cites [ALTER-URI] for the alter: scheme, corrects the [RFC7595] section for provisional registration to Section 4, and says in Section 12.3 that an alter: URI supplies the handle and that the zone is never derived from the handle's spelling. Removes editing-history notes from the Introduction and Terminology, and trims wording in Section 3 and Section 4.¶

• Rewrites Section 3 to describe each neighbouring draft by what it specifies, without characterising its intent or scope.¶

• Moves accounts of earlier revisions out of the body and into this appendix, and removes commentary on the document's own candour.¶

• Removes the identity field framing from the Introduction, and cites [MORRISON-IFT] from the ~handle definition instead. Removes two terminology notes that were editorial guidance rather than definitions.¶

• Makes entity and regulated proper subsections of Section 6.3. States the forward-compatibility rule for unknown regulated tokens by reference to step 4 of Section 12.2.¶

• Corrects item 3 of Section 14.3, which said a malicious zone operator is caught by defence (1), which does not hold. Corrects a section reference in Appendix A. Removes the provisional-use sentence from Section 16.1.¶

• Corrects the Instrument-tier description in Section 2 to match Section 8.5 of [MORRISON-IFT], says at the h field of Section 7.3.2 that an Instrument-tier handle has no envelope of its own, and removes the Instrument-tier envelope example, which contradicted it.¶

• Corrects statements in Section 3, Section 4 and Section 5.3.3 about what neighbouring drafts specify.¶

• Removes a schema URL that does not resolve, and a fallback in Section 11 that no procedure defines.¶

• Corrects revision references in Section 1, Section 5, Section 12.1 and Section 13, and replaces references to earlier record generations with section numbers.¶

• Removes product terms and an undefined term from Section 2, Section 9, Section 12.2.2 and Section 15.1, and replaces a third-party name in an example.¶

• Replaces the authoring organisation's own name and ABN in the examples of Section 6.3.3 and the section before it with example values.¶

draft-morrison-mcp-dns-discovery-07 (September 2026):¶

Tracks the current [AGENT-AID] revision and corrects the status of the alter: URI scheme. No change to any record defined here.¶

• Stops describing the alter: URI scheme as provisionally registered with IANA (Section 2, Section 11, Section 16.2). Revision 06 said it was, and it was not. Provisional registration is now requested.¶

• Moves the revision summary out of the Abstract. This appendix carries it in full.¶

• Names the revision that made each change in four sentences that said "this revision" about revisions 05 and 06.¶

• Describes the [AGENT-AID] record in its aid2 format, where revision 06 still described aid1. The endpoint-proof key is now an unpadded base64url JWK x value with its JWK thumbprint [RFC7638] as the signature keyid, and the i rotation identifier is gone. aid1 stays valid through [AGENT-AID]'s compatibility window.¶

• Points the [AGENT-AID] reference at draft-nemethi-dawn-aid, the name the document now carries.¶

draft-morrison-mcp-dns-discovery-06 (September 2026):¶

Adds a key continuity rule for the _mcp record, the first normative change since revision 05, and corrects two statements in the revision 05 Implementation Status section. No record format changes and no field is added.¶

• Adds Section 13.1. Every earlier revision described the _mcp key binding as trust on first use with periodic re-verification, and none said what a client does when the re-verification disagrees. A client following revision 05 that had pinned a key would accept a different one on the next connection, which is the case of a lapsed domain registered again by someone else. The new section covers a changed key under the same epoch, an epoch that goes down, a declared rotation, and a record that drops its pk.¶

• States that an epoch decrease is never a conformant publisher state (Section 5.3.7). The earlier rules covered a claim whose epoch is below or above the record's, and nothing covered the record's own epoch going down, which is what a new registrant publishing epoch=0 over a pinned epoch=2 looks like.¶

• Extends step 7b of Section 12.1.2 to apply the rule, and to verify against a pinned key where the record no longer carries one. The procedure's opening sentence no longer claims the algorithm of [DNSDISC-01] unchanged.¶

• Adopts the graded change-of-control signals of [DOMAIN-SET] Section 6.3 for the pinned binding (Section 13.1.2), and adds [DOMAIN-SET] and [RFC9083] as informative references. [DOMAIN-SET] already specified a consumer-side rule for a lapsed and re-registered domain, and this document had none.¶

• Keeps absence of a record distinct from revocation, and says the difference from [DOMAIN-SET] Section 6.4 is deliberate (Section 13.1.1). That document treats removal of a record as revocation. This one does not, for the envelope record since revision 03 and now for the pinned key binding, because clearing a pin on absence would let one suppressed resolution reset a client to first use.¶

• Adds Section 14.8, which states the change-of-control exposure for all three records, and states for the _alter record that this document specifies no pin and that a new registrant passes every FATAL step of Section 12.3.¶

• Records in Section 19 that no implementation of the new rule is claimed.¶

The two Implementation Status corrections, both of which understated the deployment:¶

• Corrects the DNSSEC statement. Revision 05 said truealter.com was not DNSSEC-signed and that the parent zone held no DS. The zone was signed nine days before revision 05 was filed and is signed today, with a key-signing key and a zone-signing key at algorithm 13 and a DS in the parent. The consequence revision 05 drew from the erroneous statement, that no Envelope Record could be relied upon in this zone, is withdrawn with it.¶

• Records _org-alter.truealter.com as deployed. Revision 05 recorded it as NXDOMAIN, which was accurate when filed. It has since been provisioned and carries the field set named in the Implementation Status section.¶

• The remaining statements of that section were re-checked against the zone and against the code and are carried forward unchanged. The absent DANE TLSA pin, the absence of any conformant Envelope Record, the two recognition steps on which the verifier still follows revision 04, the absent federation and witness network, and the absence of inclusion proofs all still hold.¶

draft-morrison-mcp-dns-discovery-05 (July 2026):¶

Corrections to -04, and the record formats and procedures restated in full. No new mechanism.¶

• Restores the citation of [AGENT-AID], which revision 01 carried and revisions 02 through 04 dropped, and distinguishes it from [DNS-AID], a different draft with the same acronym. Revision 05 also said that this document is what the [AGENT-AID] mcp protocol token defers to. Revision 08 strikes that sentence at the request of the [AGENT-AID] author.¶

• Gives all three record formats (Section 5, Section 6, Section 7), all three procedures (Section 12.1, Section 12.2, Section 12.3) and the caching rules (Section 13) in full. Revisions 03 and 04 incorporated the first two records and their procedures by reference to revisions 01 and 02.¶

• Separates the agent protocol family from the transport binding in the _mcp record. Revision 01 used proto for the transport. proto now names the protocol family and transport names the binding, which is the term the Model Context Protocol specification uses.¶

• States how to read an _mcp record published under revision 01 (Section 5.3.5). A proto value that names neither the protocol family nor a known transport causes the record to be SKIPPED, as revision 01 required.¶

• Reconciles the _mcp grammar with its prose. The grammar admits any token in proto and transport; proto has exactly one defined value and transport exactly three, and the two sets are disjoint.¶

• Replaces 1*VCHAR for org, entity and entity-type with a text-value rule that admits SP and excludes only the field separator (Section 6.2).¶

• Stops every value rule in all three grammars from running past the end of its own field. unknown-field and https-uri were defined over *VCHAR, which includes the semicolon. qtext admits SP and excludes the semicolon; uri-char excludes both.¶

• States that unknown-field matches only a field name this document does not define, so a defined field whose value is malformed makes the record malformed (Section 5.2). The split-on-semicolon parse in Section 12.1 already behaved this way.¶

• Requires a publisher emitting transport to emit proto=mcp with it (Section 5.3.5).¶

• Adds Section 3 and Section 4.¶

• Cites each label in the IANA table (Section 16.1) to the section of this document that defines it.¶

• Rewrites Section 19 against the deployed zone and code. The -04 section claimed an _org-alter record, a DANE TLSA pin, a conformant envelope record and a signed-tree-head witness federation, none of which existed.¶

• Withdraws the claim in Section 14.3 defence (1) that ilr= defeats envelope substitution.¶

• Fixes the signing input of Section 7.4. The keys are the TXT field names, v is inside the signed object, and ts is a JSON string. An envelope signed under -04 does not verify under -05. No envelope signed under -04 exists.¶

• Derives signature_alg from the pk= algorithm prefix via the registry of Section 16.7.¶

• Allows a split within a key-value pair in Section 7.6, so a field longer than 255 octets can be carried.¶

• Marks publication of a per-individual envelope in DNS as NOT RECOMMENDED, and forbids more than one handle at one owner name (Section 7.1, Section 7.1.1).¶

• Withdraws the IdentityLog witness federation everywhere -04 asserted it, and makes the cross-reference at step 9 of Section 12.3 advisory. The ilr= field is kept so the wire format does not change.¶

• States that a reader implementing from this document alone cannot check revocation.¶

• Repairs every internal cross-reference.¶

• Corrects all four references into [DNSDISC-01] and [DNSDISC-02]. The _mcp record format is Section 5 of [DNSDISC-01], not Section 3, and its discovery procedure is Section 6, not Section 4. The _org-alter record format is Section 6 of [DNSDISC-02], not Section 4, and its bootstrap procedure is Section 7, not Section 6.¶

• Gives the _alter record two ABNF grammars (Section 7.2), one for publisher emission and one for resolver acceptance, with the field-cardinality rule stated beside them.¶

• Reconciles Section 14.6 with step 5 of Section 12.2. The _mcp and _org-alter keys must match; only the envelope key of Section 7 MAY differ.¶

• Removes two hand-written reference sections that duplicated the generated ones.¶

• Corrects the field count to seven REQUIRED fields.¶

draft-morrison-mcp-dns-discovery-03 (April 2026):¶

Editorial corrections (retiring -02):¶

• Removes the third-party-domain worked example used in -02 and replaces all instances with [RFC2606] reserved example-domain forms; no third-party operational domain appears in any illustrative DNS record in this revision.¶

• Strips city and locality fields from the author front-matter block, retaining only name, organisation, and email per editorial policy.¶

Substantive additions:¶

• Adds the _alter.<domain> Envelope Record (Section 7).¶

• Defines v, h, pk, ilr, ts, rev, sig fields for the new record.¶

• Introduces a mandatory DNSSEC validation requirement for _alter.<domain> responses (Section 8).¶

• Introduces a mandatory DANE TLSA [RFC6698] pin on the MCP endpoint (Section 9) for envelope-triggered MCP sessions.¶

• Adds the IdentityLog cross-reference requirement (Section 10). Revision 05 withdraws it; see the -05 entry above.¶

• Adds a provisional alter: URI scheme cross-reference per [RFC7595] (Section 11).¶

• Adds the envelope recognition procedure (Section 12.3), a twelve-step algorithm.¶

• Adds IANA registration for _alter underscore-prefixed label (Section 16.1) and the independent v=alter1 envelope version namespace.¶

• Adds a Signature Algorithm Registry (Section 16.7) with initial value ed25519.¶

• Adds Security Considerations for DNSSEC downgrade, TLSA pin rotation, envelope substitution, revocation opacity, clock skew, cross-record key consistency, and passive-stream coupling.¶

• Adds Privacy Considerations for public handle disclosure, DNS query metadata, and revocation unlinkability.¶

• Adds Examples for minimal envelope, multi-handle zone, full ~alter zone with all three records, and Instrument-tier handle.¶

• Adds Implementation Status entry for the envelope reference implementation.¶

• Incorporated the v01 _mcp.<domain> and v02 _org-alter.<domain> record specifications by reference, leaving them unchanged. Revision 05 restates both in full; see the -05 entry above.¶

draft-morrison-mcp-dns-discovery-02 (April 2026):¶

• Adds the _org-alter.<domain> Org-Identity Record.¶

• Defines org, entity, entity-type, founded, regions, regulated, bootstrap, mcp-policy, epoch, pk, attest, ext fields for the organisational record.¶

• Adds the Identity Bootstrap procedure.¶

• Adds IANA registration for _org-alter underscore-prefixed label.¶

• Adds version tag v=alter1 (org-alter namespace) and registry namespace and framework token registries.¶

• Adds Examples for minimal, full, regulated (DISP), and multi-regulator deployments.¶

• Adds Implementation Status entry for the orgalter_discover reference library.¶

• v01 _mcp.<domain> record specification is incorporated by reference and remains unchanged.¶

draft-morrison-mcp-dns-discovery-01 (April 2026):¶

• Adds Identity Field Theory grounding for epoch and scope.¶

• Refines security considerations for identity assurance decay.¶

• Refines privacy considerations for scope as a privacy boundary.¶

• Adds Coexistence section with SEP-1959, AID, A2A.¶

• Adds Implementation Status section.¶

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.¶

Contributors

Author's Address