Discovery of Model Context Protocol Servers via DNS TXT Records

Discovery of Model Context Protocol Servers via DNS TXT Records Alter Meridian Pty Ltd

blake@truealter.com

This document defines a DNS-based mechanism for discovering Model Context Protocol (MCP) servers, the identity of the organisations that operate them, and a cryptographic identity envelope bound to an individual Sovereign-tier ~handle published under the same zone. Three TXT records are defined. _mcp.<domain> advertises an MCP server's endpoint URL, agent protocol family, transport binding, cryptographic identity, and capability profile. _org-alter.<domain> advertises the operator's canonical organisational identity, including its legal entity, registry identifier, regions of operation, and any regulatory framework under which it must refuse external automated access. _alter.<domain> publishes an Ed25519-signed envelope binding a ~handle to a public key, an IdentityLog root reference, and a revocation commitment. DNSSEC validation is REQUIRED for the envelope record, and a DANE TLSA pin on the MCP endpoint is REQUIRED where resolving an envelope and opening an MCP session are one recognition transaction. This revision (v06) adds a key continuity rule for the _mcp record. It says what a client does when the key it pinned differs from the key DNS now serves, and when the published epoch goes down, neither of which any earlier revision covered. It also corrects two statements in the Implementation Status section. Revision 05 withdrew several claims that v04 could not support, marked publication of a per-individual envelope in DNS as NOT RECOMMENDED on enumeration, size, and erasure grounds, and separated the agent protocol family from the transport binding in the _mcp record, aligning that vocabulary with neighbouring DNS agent-discovery drafts. All three record formats and all three procedures are given here in full, so no earlier revision need be fetched. The mechanism complements HTTPS-based discovery, and follows the precedent set by DKIM, SPF, DMARC, and MTA-STS. Provisional registration of a companion alter: URI scheme is requested of IANA, and is not yet granted.

Introduction Model Context Protocol (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:

Service discovery. Where is the MCP server endpoint? What transport does it speak? What cryptographic key authenticates it? This is the question v01 of this document answers via the _mcp.<domain> record.
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? This is the question v02 answers via the _org-alter.<domain> record.
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? This is the question v03 introduces via the _alter.<domain> record.

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 (_domainkey._domain) and DMARC (_dmarc._domain), where each record serves a single semantic purpose. SPF and MTA-STS set the same precedent for carrying policy in a TXT record under a reserved label. This revision is fully backward-compatible with v01 and v02. 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. Earlier revisions deferred the envelope schema, the JSON Canonicalisation Scheme (JCS, ) serialisation, and the verification algorithm to a companion specification a reader could not fetch, which made this document unimplementable by anyone outside its author's organisation. They also incorporated the _mcp and _org-alter record formats and procedures by reference to revisions 01 and 02, by section numbers that named the wrong sections, so a reader who followed a pointer arrived at the wrong place in the right document. Both deferrals are removed. All three record formats (, , ), all three procedures (, , ), the signing input () and the caching rules () 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 individual-identity layer is grounded, as the organisational layer is, in the identity field framework of . A ~handle is not a reserved alphanumeric slot but a durable recognition attractor in the identity field. A DNS record provides a discrete checkpoint into that field: the envelope published at _alter.<zone> is the handle-holder's own canonical declaration, signed by their Ed25519 key and consumable by any resolver with access to a DNSSEC-validating recursive resolver. It also carries a reference to an IdentityLog root, whose status as a trust anchor sets out honestly and narrowly.

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 when, and only when, they appear in all capitals, as shown here.

Terminology (Terminology from v01 and v02 is retained. Additional terms introduced in this revision are defined below.)

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 envelope is the unification primitive of the ~alter identity architecture. The TXT grammar that carries the seven required envelope fields across DNS, and the signing input over which they are verified, are specified in 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).
IdentityLog: An append-only transparency log recording envelope lifecycle events (mint, caveat-add, revocation, key-rotation), whose root the ilr= field of references. Revision 04 of this document described a Signed Tree Head emitted every minute and cross-anchored to four named witness surfaces. No such witness federation exists, and the description is withdrawn. 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. states what a resolver may and may not conclude from ilr= in the meantime.
Organ: A broadcast surface for the envelope. The three organs are: DNS publication (this document), the local alter-runtime L3 daemon, and a hardware-anchored device-organ quorum. The term is canonical; do not substitute "channel", "vector", or "emitter" at the architectural level.
Recognition: The act of a resolver observing and verifying an envelope on cryptographic merit. Recognition is distinct from claim: publishing a TXT record is not a claim of identity, it is an observable assertion that the resolver may verify or reject. No field of this document carries a claim verb; resolvers recognise envelopes, they do not honour publisher assertions about them.
DNSSEC Validation: The act of an authenticating DNS resolver verifying the RRSIG chain from the root trust anchor to the TXT RRset, per , , and , and setting the AD bit on the response delivered to the stub client.
DANE TLSA Pin: A DNS TLSA resource record 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 dispatch URI scheme provisionally registered with IANA per . Handler guidance is given in of this document.

(Terms from v02, Org-Identity Record, Identity Bootstrap, Canonical Entity Identifier, Regulatory Refusal Marker, are retained.)

Related Work Several drafts now publish agent discovery data in DNS, and they arrived at overlapping vocabularies independently. Two of them are called AID and they are different documents. is "Agent Identity and Discovery", and is "DNS for AI Discovery". A reader who meets both should not have to work that out from context, so this document names them apart. 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=aid1 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) with a rotation identifier (i). The _mcp record of 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, and both patterns are derived from DKIM . Neither document copied the other. Two drafts landed on one shape because DKIM is where anyone publishing a key in TXT learns to look, and published that shape first, in March 2026. The two compose, and says how. Its abstract states that AID is intentionally small and that after discovery, protocol-specific mechanisms such as MCP handle communication and capability negotiation, and its protocol registry already carries mcp as a token. This document is what that token defers to. answers where an agent is and which protocol to speak to it; the _mcp record answers what an MCP endpoint then requires, its transport, its authentication, its capability scope and its key epoch; and the _org-alter record of answers who is behind the endpoint, with a legal entity, a registry identifier, operating regions and regulatory refusal markers. A deployment may publish both, and a client that learns p=mcp from _agent.<domain> may query _mcp.<domain> for the depth deliberately leaves out. The keys bind different things, which is why publishing both is not a duplication. The k of 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. One proves the door is the right door. The other says who owns the building. Revision 01 of this document made the first of these points, in a section titled "Relationship to Agent Identity and Discovery (AID)". Revision 02 dropped the prose and kept the reference, and revisions 03 and 04 dropped both. That was an error and this revision reverses it. 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 and is the most substantial neighbouring work in the space. It operates over unicast DNS, as this document does, and the two are complementary rather than competing. DNS-AID addresses agent discovery generally, while this document addresses one protocol family in depth and adds the identity records that carry a signed envelope. 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. The slot this document would occupy in that vocabulary, proto=mcp, is therefore open rather than taken, and the two documents agree on what the key MEANS, which is the part that matters for an implementer reading both. Its Section 7 puts discovery across links out of scope while noting that existing wide-area and aggregated DNS-SD facilities can provide it without changing the descriptor, so its scope is not permanently local. No record is ever shared with this document's records regardless, because the owner names and service types differ. 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). It is a third reading of the same axis, and it strengthens the case for a shared distinction rather than weakening it. 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 and SPF . Its Section 10, "Trust and Attestation Discovery", specifies that publication and the discovery of the key from it, so the two documents are solving the same problem at the same layer: how a verifier finds the key that a signature must check against. 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 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. These drafts would serve their readers better with one vocabulary. An implementer reading two of them should not have to hold two meanings for one key in their head. The neighbouring drafts keep the agent protocol and the transport apart, each in its own way. defines proto as the agent protocol identifier and never as a transport, and carries the connection data in the SRV record instead. 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 exactly that, so revision 01 is the odd one out, and it is the reading that has to give way. The alignment adopted here is therefore 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 , where DNS already carries it. permits alpn to hold the transport, the agent protocol, or both, and a reader of that draft and this one should know that this document does not overload alpn in the same way. Three axes are made explicit here rather than two, and the third is not carried in TXT at all.

Why TXT rather than SVCB The neighbouring drafts carry their connectivity data in SVCB records, with TXT as a fallback. This document is the reverse, TXT is the primary carrier. The reason is the payload, not a rejection of SVCB. 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 earns its place 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 , never in this TXT record, for exactly 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.

Record Format: _mcp.<domain> (Service Discovery) This section defines the Discovery Record introduced in v01. It is given here in full. Revisions 03 and 04 incorporated it by reference, by a section number that named the wrong section, and a reader could not follow the pointer.

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

ABNF Grammar The record value is a semicolon-delimited sequence of key-value pairs. The following ABNF defines the syntax: unknown-field matches ONLY a field name this document does not define. ABNF has no way to say "any token except these", so the exclusion is stated here, and it is normative. Where a field name IS defined above, the field MUST be parsed by that field's own rule. A record in which a defined field's value does not satisfy its own rule is MALFORMED, and a client MUST discard it, exactly as discards a record whose url is not a valid HTTPS URI. A client MUST NOT re-read such a field as an unknown-field. Without this rule the alternation would swallow every defect it was written to exclude: url=https://x.com priority=5 would parse as an unknown field named url rather than as the malformed url field it is. The grammar admits any token in proto and in transport, and that is deliberate. Syntactic admissibility is not definition. Revision 01 admitted any token in proto and records in the wild carry transport values there, so a resolver MUST be able to PARSE such a record before it can decide what to do with it, and the reading rule of is what decides. A grammar that rejected those records at the parser would leave the reading rule with nothing to read. The values this document DEFINES are enumerated in the field definitions below, and they are few. proto has exactly one defined value, mcp. transport has exactly three, streamable-http, sse, and stdio-url. Those two sets are disjoint, so no value is defined for both fields. A transport value appearing in proto is RECOGNISED there, under , and is not DEFINED there; the distinction is what makes the previous sentence true.

Field Definitions

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

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

proto (OPTIONAL) The agent protocol family the endpoint speaks. Default value: mcp. For a record published at _mcp.<domain> the only value defined by this document is mcp; the field is retained because the same key, with the same meaning, is used by neighbouring discovery drafts (see ) and a client that reads several of them should not have to special-case this one. proto does not name a transport. It does not carry streamable-http, sse, h2, h3, or any other binding. The transport is carried by the transport field below. A record published under revision 01 may still carry a transport value here, and says exactly how to read one. The field is OPTIONAL, but not unconditionally. A publisher that emits a transport field MUST also emit proto=mcp, for the interoperability reason given in . Omitting proto is permitted only where transport is also omitted.

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

streamable-http, the HTTP-based streaming transport (default).
sse, the HTTP+SSE transport of MCP protocol version 2024-11-05, retained for deployed servers. The Model Context Protocol specification marks this transport superseded by streamable-http. It is listed so an existing server stays discoverable, not as a recommendation for new deployments.
stdio-url, a URL pointing to a signed launch descriptor for a stdio-based server (descriptor format out of scope). This is a discovery convenience defined by this document, not one of the MCP specification's own transport names.

The field is named transport because that is the term the Model Context Protocol specification itself uses for this axis, so an _mcp record and an MCP client configuration name the transport the same way. Implementations SHOULD support at least streamable-http. A client that meets a transport value it does not recognise MUST skip the record and proceed to the next record by priority, or to HTTPS fallback. The wire protocol beneath the transport (h2, h3, http/1.1) is NOT carried in this record. It is already expressible as the alpn service parameter of an SVCB or HTTPS resource record , and duplicating it in TXT would create two sources of truth for one fact.

Reading a record published before this revision Revision 01 of this document defined proto as the transport, so records in the wild carry proto=streamable-http, proto=sse, or proto=stdio-url. Revision 01 also admitted ANY token in that field, and required a client that met a proto value it did not recognise to SKIP the record. Both of those behaviours are preserved here. Such records remain valid and MUST be read as follows. A client reading an _mcp record determines two things, the protocol family first and the transport second. Taking them in the other order is what makes an unrecognised value look harmless, so the order is normative. Step A, the protocol family. The family is mcp where any one of the following holds:

proto is absent;
proto carries mcp;
proto carries one of the three values defined for transport in . This is the revision 01 form, in which the transport was written into proto.

Where proto carries any other value, it names a protocol family this document does not define. The client MUST skip the record and proceed to the next record by priority, or to HTTPS fallback. It MUST NOT treat the value as a transport, and it MUST NOT apply a default transport to the record. This holds whether or not a transport field is also present: a record reading transport=streamable-http; proto=websocket is skipped, because the family is unknown, and the presence of a readable transport does not make an unknown family speakable. Step B, the transport. A client reaches this step only where Step A yielded the family mcp.

Where transport is present and carries one of the three values defined in , that value is the transport, and any transport value carried in proto MUST be ignored.
Where transport is present and carries any other value, the client MUST skip the record, and MUST proceed to the next record by priority or to HTTPS fallback ().
Where transport is absent and proto carries one of the three defined transport values, that value is the transport. This is the revision 01 form.
Where transport is absent and proto is absent or carries mcp, the transport is streamable-http.

The skip in Step A is the rule that matters, and it is written out because the obvious reading gets it wrong. Revision 01 admitted any token in proto, so proto=websocket was a syntactically legal record, and every conformant revision 01 client SKIPPED it, because revision 01 required a skip on an unrecognised proto value. A client that instead read an unrecognised proto value as a protocol family, and then applied the default transport, would open a streamable-http session against a server that never offered one. That record was unusable under revision 01 and it stays unusable here. Preserving the skip is what keeps the two revisions interoperable. Widening the rule to absorb any unknown token would do the opposite, because it would newly accept records that no client could ever use. A publisher that emits a transport field MUST also emit proto=mcp. This is not decoration. A revision 01 client does not know the transport field, and its own forward-compatibility rule tells it to IGNORE any field it does not know, so it reads only proto. A record carrying transport=streamable-http beside proto=sse would therefore resolve to streamable-http under this revision and to sse under revision 01, which is one record and two transports. Setting proto=mcp alongside transport removes the divergence, because a revision 01 client then finds no transport it recognises in proto and skips the record rather than reaching a different endpoint state than a current client would. Publishers SHOULD move to the two-field form. No flag day is required, because the two forms are distinguishable by inspection, and because no value is defined for both fields ().

pk (OPTIONAL) Ed25519 public key for endpoint verification, encoded as ed25519:<base64url> where <base64url> is the raw 32-byte public key encoded per Section 5, without padding. Where 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:

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

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

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

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

The epoch field enables epoch-based revocation without external Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol (OCSP) infrastructure. Incrementing the epoch revokes all outstanding claims issued under prior epochs, subject to the grace period defined by each claim's expiry. The rules above compare a claim against the record. They do not compare the record against itself over time. A publisher never lowers the epoch, because the field is monotonic, so a record whose epoch is lower than one a client has already observed is not a state a conformant publisher produces. states what a client does when it observes one, and what it does when the pk changes.

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 recognise a capability token MUST ignore it.

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

employ, current employment affiliation.
contract, contractual or freelance engagement.
alumnus, former affiliation.
director, board or directorial role.
member, generic membership (professional body, association).
contrib, verified contribution without formal affiliation.

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

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

tools, the server exposes callable tools.
resources, the server exposes readable resources.
prompts, the server exposes prompt templates.
sampling, the server supports LLM sampling requests.
identity, the server supports identity resolution queries.

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

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

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

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

Forward Compatibility Implementations MUST ignore unknown fields. A parser encountering a field name that it does not recognise 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. Ignoring an unknown FIELD is not the same act as skipping a record on an unrecognised VALUE in a field this document defines. The first is required here; the second is required by and . Breaking changes to the semantics of existing fields require a version bump, for example v=mcp2.

Multi-String Concatenation DNS TXT resource records are limited to 255 bytes per character-string . Where a Discovery Record exceeds 255 bytes, the record MUST be split across multiple character-strings within a single TXT RDATA, which the DNS resolver concatenates per Section 3.3. Example of a multi-string record: 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.

Record Format: _org-alter.<domain> (Identity Bootstrap) This section defines the Org-Identity Record introduced in v02. It is given here in full, for the same reason is.

DNS Location The Org-Identity Record is a DNS TXT resource record published at the label _org-alter prepended to the Policy Domain: . IN TXT "" ]]> The underscore prefix conforms to the conventions established in for globally scoped, underscore-prefixed DNS node names. A domain MAY publish a _mcp.<domain> record without an _org-alter.<domain> record (service-only deployment), or an _org-alter.<domain> record without a _mcp.<domain> record (identity-only deployment), or both (full deployment). The recommended pattern for any operator running an org-alter instance is to publish both. Multiple TXT resource records MAY be published at the same DNS name (e.g., for staged identity rotation). Clients MUST evaluate all returned records and select the one with the highest epoch field.

ABNF Grammar The record value is a semicolon-delimited sequence of key-value pairs. The following ABNF defines the syntax: The text-value rule corrects a defect inherited from revision 02, which defined org, entity and entity-type over 1*VCHAR. VCHAR is %x21-7E and excludes the space, so that grammar could not derive org=Alter Meridian Pty Ltd or entity-type=Pty Ltd, which are the values revision 02's own examples published. A legal entity name carries spaces, so the rule now admits them, and excludes only the semicolon that separates one field from the next. A URI does not carry a raw space, so bootstrap and ext are defined over uri-char rather than text-value. A character class that is right for a name is not thereby right for a URI: admitting SP in a URI value would let it run past its own end and consume the field after it. As in , unknown-field matches ONLY a field name this document does not define. Where a field name IS defined above, the field MUST be parsed by that field's own rule, and a record in which a defined field's value does not satisfy its rule is MALFORMED and MUST be discarded rather than re-read as an unknown field.

Field Definitions

v (REQUIRED) Protocol version identifier. MUST be the literal string alter1. 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 alter1. The version namespace is independent of the _mcp record's v=mcp1 namespace. This allows the two record types to evolve independently.

org (REQUIRED) The canonical legal name of the organisation operating the domain. MUST be the registered legal entity name as it appears in the operator's primary corporate registry, not a trading name or brand. For trading names, see the optional entity-type field. Examples: ### entity (RECOMMENDED) A globally-disambiguating canonical entity identifier, prefixed by its registry namespace. Defined registries:

abn: -- Australian Business Number (11 digits, no spaces).
acn: -- Australian Company Number (9 digits, no spaces).
ein: -- US Employer Identification Number (NN-NNNNNNN).
ch: -- UK Companies House number (8 alphanumeric).
cro: -- Irish Companies Registration Office number.
lei: -- Legal Entity Identifier (20 alphanumeric per ISO 17442).

Additional registries MAY be defined; clients MUST treat unknown registry namespaces as opaque identifiers. Example: The entity field is the primary anti-impersonation defence for the identity layer: a domain claiming to be Alter Meridian Pty Ltd without an ABN that resolves to that name in ABR Lookup is detectable as a mismatch by any verifier with access to the public registry.

entity-type (OPTIONAL) A short human-readable label for the entity's type, drawn from its jurisdiction's vocabulary. Examples: Pty Ltd, LLC, GmbH, SAS, non-profit. This field is advisory and is intended for display to humans; it is not a structured taxonomy.

founded (OPTIONAL) The date the legal entity was founded or registered, as YYYY or YYYY-MM or YYYY-MM-DD per ISO 8601. This field is advisory and is used by onboarding wizards and identity verifiers to display "Founded N years ago" or to detect implausibly young entities making strong claims.

regions (OPTIONAL) A comma-separated list of ISO 3166-1 alpha-2 country codes indicating the operator's primary regions of operation. This field is advisory. It is used by onboarding wizards to set sane defaults for jurisdiction-specific behaviour (e.g., currency, locale, public registry preference). Example: ### regulated (OPTIONAL but STRUCTURALLY SIGNIFICANT) A comma-separated list of regulatory framework tokens under which the operator is bound. Defined values (extensible):

disp -- Australian Defence Industry Security Program.
itar -- US International Traffic in Arms Regulations.
ear -- US Export Administration Regulations.
hipaa -- US Health Insurance Portability and Accountability Act.
gdpr -- EU General Data Protection Regulation.
soc2 -- AICPA SOC 2 Type II.
iso27001 -- ISO/IEC 27001 information security management.
iso42001 -- ISO/IEC 42001 AI management systems.
essential8 -- ASD Essential Eight (ML2 or higher).
aprs -- Australian Privacy Principles / Privacy Act.

The presence of any token in this field is a structural promise: the operator declares that they are bound by the named framework and that automated access pathways crossing the regulated boundary MUST be refused. Onboarding wizards reading this field MUST refuse to attempt L5/L6 authenticated access to data stores covered by the declared framework, regardless of whether credentials are available. This converts the DNS record into an out-of-band consent boundary: a remote agent's tooling becomes structurally aware that integration is forbidden before it ever attempts a connection. An agent that ignores this declaration and attempts integration anyway commits a detectable, attributable violation. Forward compatibility: unknown framework tokens MUST be treated conservatively (assume the strictest defensible refusal) rather than ignored.

bootstrap (OPTIONAL) An HTTPS URL pointing to a JSON document containing additional identity bootstrap metadata: a directory of public roster members (if the org chooses to publish one), an organisational logo URL, a canonical public website URL, an attest profile beyond what fits in DNS, and any operator-defined extensions. The bootstrap document MUST be served over HTTPS with a valid TLS certificate for the Policy Domain. The document format is operator-defined; recommended schema is published as https://truealter.com/.well-known/org-alter-bootstrap.schema.json as a non-normative reference.

mcp-policy (OPTIONAL) A single token declaring how the operator's MCP endpoint relates to external automated access:

open -- The MCP endpoint accepts queries from any agent with appropriate authentication.
refuse-automated -- The MCP endpoint exists for human-mediated access only. Automated agents SHOULD NOT initiate sessions.
refuse-tenant -- The MCP endpoint exists, but the operator runs one or more tenants (e.g., an M365 tenant) into which automated access is forbidden. This is the typical declaration for an org-alter instance run by an operator who has DISP-accredited or ITAR-bound systems alongside their public meta-layer.
refuse-all -- The MCP endpoint exists for the operator's own internal use only. External agents MUST NOT attempt connection.

Default value, if absent: open. The mcp-policy field complements the regulated field. regulated=disp; mcp-policy=refuse-tenant is the canonical declaration for a defence contractor running an org-alter at the unclassified meta-layer alongside a regulated tenant they will not allow automated agents to enter.

epoch (OPTIONAL) A monotonic non-negative integer that increments on every identity rotation event (e.g., legal entity restructure, change of control, move to a new jurisdiction). Default value: 0. Semantics mirror the epoch field of the _mcp record defined in v01. A wizard that has persisted this record's pk and epoch applies the rules of when it re-reads the record.

pk (OPTIONAL) Ed25519 public key for endpoint verification, encoded identically to the v01 _mcp record's pk field. When present, the same key provides cryptographic binding for both endpoint discovery and identity bootstrap.

attest (OPTIONAL) A comma-separated list of attestation types the operator declares it is authorised to issue, identical in semantics to the v01 _mcp record attest field. Where both records publish an attest field, the values MUST be consistent. An onboarding wizard SHOULD use the union of the two.

ext (OPTIONAL) An HTTPS URL pointing to a protocol-extension document, identical in semantics to the v01 _mcp record ext field. This field is distinct from bootstrap: ext is for protocol-level extensions to the discovery format itself; bootstrap is for operator-level identity metadata.

Forward Compatibility Implementations MUST ignore unknown fields. This rule, identical to the v01 _mcp record specification, ensures that future extensions to the _org-alter record format do not break existing implementations.

Record Format: _alter.<domain> (Envelope Publication) This section defines the new Envelope Publication record introduced in v03. The record publishes the seven required fields of the ~alter 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 (). The signature algorithm is not a separate field. It is derived from the pk= prefix via the registry of , and enters the signing input under that derivation.

DNS Location The Envelope Record is a DNS TXT resource record published at the label _alter prepended to the hosting zone: . IN TXT "" ]]> The underscore prefix conforms to the conventions established in for globally scoped, underscore-prefixed DNS node names. Publication of a per-individual envelope at this label is NOT RECOMMENDED, for the reasons in . That applies to any number of handles. Revision 04 additionally permitted a zone to host more than one ~handle by publishing multiple TXT RRs at this one owner name, with resolvers disambiguating on the h= field; that pattern is the enumeration exposure of in its sharpest form, and a zone MUST NOT use it. A domain MAY publish any combination of _mcp.<domain>, _org-alter.<domain>, and _alter.<domain> records independently (service-only, identity-only, envelope-only, or any intersection).

Applicability of the Envelope Record Publication of a per-individual envelope in DNS is NOT RECOMMENDED for new deployments. Three properties of DNS are the reason. Enumeration. Where a zone co-hosts several handles at one owner name, a single query returns the entire set. That is a membership roll, published to the internet, retrievable by anyone, and the individuals listed in it cannot each consent to the disclosure of the others. Even with one handle per zone, DNSSEC's authenticated denial of existence permits zone walking unless NSEC3 or a compact denial scheme is deployed, and this document never required one. Size. A conformant envelope does not fit in a single 255-octet character-string, and no conformant envelope is smaller than the limit. Co-hosting a handful of handles at one owner name exceeds the 1232-octet fragmentation budget that current DNS operational guidance assumes, and the RRset grows without bound in the number of handles. The resolution algorithm of retrieves the whole RRset and filters client-side, so the cost of resolving one handle grows with the number of handles the zone hosts. Erasure. A DNS record, once published and cached, cannot be recalled. A mechanism that binds a natural person's identifier to a key in public DNS offers that person no way to withdraw the binding from the caches and passive collectors that have already taken it. Revocation, where this document specifies it at all, marks a binding dead; it does not unpublish it. These are properties of this mechanism as specified. The envelope format itself, its signing input (), and the verification procedure () are not implicated by them.

ABNF Grammar The record value is a semicolon-delimited sequence of key-value pairs. Two grammars are given, because a publisher and a resolver are held to different rules. alter-record is what a conformant publisher MUST emit. alter-accepted is what a conformant resolver MUST accept. Every alter-record is an alter-accepted; the converse does not hold. Revisions 03 and 04 gave the publisher grammar alone, and separately required resolvers to accept records that grammar cannot derive, which is a contradiction this revision removes. The following ABNF (per ) defines the syntax: ABNF alone cannot express "each of these six exactly once, in any order", so the cardinality rule is stated here and is normative. A resolver MUST reject any record in which a required field is absent, or in which any field name appears more than once. ABNF cannot express the exclusion either. As in , unknown-field matches ONLY a field name this document does not define. Where a field name IS defined above, the field MUST be parsed by that field's own rule, and a record in which a defined field's value does not satisfy its rule is MALFORMED and MUST be rejected rather than re-read as an unknown field. The seven keys are REQUIRED. Publishers MUST NOT omit or reorder them, and MUST emit them in the order shown in alter-record. The v field is first for publisher and resolver alike. A resolver MUST reject a record whose v field is absent or is not the first field (), so the ordering freedom above extends to the remaining six required fields and to unknown fields, and never to v. Ordering among those six carries no meaning, and a resolver MUST NOT derive any from it. Resolvers MUST tolerate unknown fields wherever they appear, and MUST ignore them, per the forward-compatibility rule of . Field order on the wire has no part in signature computation. The signed bytes are the JCS serialisation specified in , which sorts member names in code-point order and is therefore blind to the order the TXT record used.

Field Definitions

v (REQUIRED) Protocol version identifier. MUST be the literal string alter1. MUST appear as the first field in the record. Resolvers MUST reject any record whose v field is absent, is not the first field, or contains a value other than alter1. The version namespace v=alter1 on _alter.<zone> is independent of the identically-named v=alter1 on _org-alter.<zone>. The two namespaces are disambiguated by the enclosing record label and MUST NOT be conflated. Future versions of either record may advance independently (e.g. _alter.<zone> may progress to v=alter2 while _org-alter.<zone> remains at v=alter1, or the reverse).

h (REQUIRED) The Sovereign-, Bot-, or Instrument-tier ~handle to which the envelope binds. The leading tilde is mandatory. Where a resolver encounters multiple envelope TXT RRs sharing an owner name, h= is the sole field it MAY use to disambiguate them. Publishers MUST NOT create that arrangement (); the rule is retained for resolvers only, so that a record published under revision 04 can still be read.

pk (REQUIRED) An Ed25519 public key prefixed by its algorithm namespace and encoded in base64url without padding per Section 5: ]]> Resolvers MUST reject records whose algorithm prefix is not ed25519 until a future revision registers additional algorithms. The pk value is the verification key for the detached signature in the sig field.

ilr (REQUIRED) Base64url-no-pad SHA-256 digest of an IdentityLog root that the publisher claims was witnessed at envelope creation. Revision 04 required resolvers to cross-reference this value and treated a failure to do so as fatal. That requirement is WITHDRAWN. The field carries a root and nothing more, so it cannot establish that this envelope is recorded in that log, and a resolver MUST NOT rely on it to detect substitution. states what it can and cannot establish, and sets out the forgery it permits.

ts (REQUIRED) Envelope inception timestamp, expressed on the wire as decimal Unix seconds. Resolvers MAY use this field to detect clock skew, evaluate caveat maturity, or reject envelopes with implausibly future inception. In the signing input of the value is carried as a JSON string of those same decimal digits, never as a JSON number. A resolver that re-types it as a number canonicalises different bytes and every signature fails against it.

rev (REQUIRED) Base64url-no-pad SHA-256 digest of the revocation pre-image. Revocation is effected by revealing the pre-image to the IdentityLog; upon reveal, the envelope is considered revoked and MUST NOT be honoured by resolvers. The rev field is a forward-secure commitment: the pre-image is never published in DNS and is released only at revocation time to the log. Publishers MUST NOT treat removal of the TXT record as revocation. Absence of a record is indistinguishable from misconfiguration; only pre-image reveal is authoritative.

sig (REQUIRED) Base64url-no-pad detached signature over the JCS-canonicalised envelope JSON with the sig field absent. Canonicalisation is specified by . The signing input is the envelope JSON reconstructed from the parsed TXT fields, plus a signature_alg member derived from the pk= algorithm prefix per the registry of , plus an EMPTY caveats array. The signature algorithm itself is the one named by the pk= prefix. The exact signing input is normative and appears in ; it is not restated by reference elsewhere.

Unknown fields Fields not enumerated above MUST be ignored by resolvers per the forward-compatibility rule (). Future revisions of this document MAY register additional envelope fields; such extensions MUST be distinguishable from private-use extensions by registration via the mechanism in .

Canonical Serialisation The sig input is constructed as follows. This construction is normative and exhaustive. An implementation that deviates in a key name, a value type, or the membership of the object will produce bytes that no other implementation can verify.

Parse the TXT RR character-strings into key-value pairs.
Derive signature_alg from the algorithm prefix of the pk value via the Signature Algorithm Registry of . For pk=ed25519:... the derivation yields the string Ed25519.
Construct the envelope JSON object, whose members are exactly the six parsed fields that are not sig, plus the derived signature_alg, plus caveats: ", "h": "", "pk": "", "ilr": "", "ts": "", "rev": "", "caveats": [], "signature_alg": "" } ]]> The keys are the TXT field names, not expanded synonyms. Every value is a JSON string, ts included, which carries the decimal digits of the TXT field verbatim and is NOT converted to a JSON number. caveats is a JSON array and, for any envelope resolved from DNS under this document, it MUST be the EMPTY array. This document defines no caveat transport and no caveat vocabulary, so a non-empty array has no interoperable meaning and an implementation MUST NOT construct one. sig MUST be absent from the signing input, and no other member may be present. These rules make the signed bytes a total function of the TXT record, which is the property v04 lacked.
Apply JSON Canonicalisation Scheme to the object, which sorts the member names in code-point order. The member order shown above is illustrative and has no effect on the canonical bytes.
The resulting byte stream is the signing input for the algorithm named in step 2.

Verification reverses this construction and checks the detached signature in the sig field against the derived byte stream. v is inside the signing input. A resolver that accepted an envelope whose version was unsigned could be walked down to a weaker version namespace by an on-path rewrite of the v field alone, so the version is signed with everything else. Publishers MUST emit TXT fields in the order given in , but the DNS key=value ordering has no role in signature computation: the signed bytes are always the JCS serialisation of the JSON object.

Forward Compatibility Resolvers MUST ignore unknown fields in the _alter.<domain> record. This rule, identical to the v01 _mcp and v02 _org-alter specifications, ensures that future extensions do not break existing implementations. Publishers MUST NOT introduce new fields that repurpose or overload the seven required field names; new fields MUST use new names registered via the procedure in .

Multi-String Reassembly Where the serialised envelope exceeds the 255-octet character-string limit of Section 3.3.14, publishers SHOULD split at ; boundaries between complete key-value pairs where the pair fits. A publisher MAY split within a key-value pair, and MUST do so where a single pair exceeds 255 octets on its own, which any signature algorithm with a large signature will require. Resolvers MUST concatenate the character-strings of a TXT RR in the order returned by the DNS library (i.e. the RR wire order) BEFORE parsing, so the split point is not observable to the parser and carries no meaning.

DNSSEC Requirement The zone publishing an _alter.<domain> envelope record MUST be DNSSEC-signed per , , and . 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. An envelope obtained over an unvalidated DNS path is not an envelope; it is unauthenticated TXT content. Treating it otherwise is a downgrade vulnerability (). 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 v01 and v02 deployments. Future revisions of this document MAY promote DNSSEC to REQUIRED for the other two records once deployment data justifies the promotion.

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

]]>

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 organ; 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. v01-only clients consuming only _mcp.<domain>) are out of scope for this requirement and continue to operate under v01 rules.

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. Revision 04 of this document required resolvers to cross-reference that value against one of four named witness surfaces, and treated a failure to do so as fatal to recognition. That requirement is WITHDRAWN. It named surfaces that do not exist, and it would not have achieved what it claimed even if they did. What ilr= can and cannot establish, stated plainly:

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 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 retained so that withdrawing its security claim does not also force a breaking change to the wire format. It is advisory. 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. This is a gap in the mechanism, not a property of it, and it is stated rather than papered over.

alter: URI Scheme Cross-Reference An IANA-registered 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 , falling back to the HTTPS .well-known surface where the DNS record is absent. Registration is provisional per Section 3. 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 IANA request is in progress as of the publication date of this revision; the final registration reference will be substituted when available. Handlers invoked via alter: URIs MUST perform full envelope verification, DNSSEC validation (), and DANE TLSA binding () when establishing any HTTPS session, before acting on any content or directive derived from the envelope.

Discovery and Bootstrap Procedures The three procedures below are normative and complete. None of them is a summary of an algorithm specified elsewhere. Revisions 03 and 04 of this document did not restate the first two. They pointed at them by section number, in a document the reader was expected to fetch separately, and every one of those pointers named the wrong section. Nothing is incorporated by reference now. The formats these procedures consume are given in full in and , and the procedures themselves are below.

Discovery Procedure: _mcp.<domain> This is the algorithm an MCP client follows to discover an MCP server associated with a given domain. It is the algorithm of , restated here in full. Step 7b is extended by this revision to apply the key continuity rule of . Every other step is unchanged.

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

Algorithm

Normalise. Convert the Origin Domain to its canonical form: lowercase per , and apply IDNA2008 processing where the domain contains non-ASCII labels.
Construct query name. Prepend the label _mcp. to the normalised Origin Domain, yielding _mcp.<origin>..
Query DNS. Issue a DNS query for _mcp.<origin>. IN TXT via the client's configured recursive resolver. Clients SHOULD prefer DoH () or DoT () to protect query privacy ().
Handle the DNS response. a. On NOERROR with one or more TXT records, proceed to step 5. b. On NXDOMAIN, or NOERROR with zero TXT records, proceed to step 8 (HTTPS fallback). c. On SERVFAIL or timeout, the client MAY retry with exponential backoff, or proceed to step 8.
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 it is not, discard this record. d. Extract all recognised fields. Ignore unknown fields, per the forward-compatibility rule of . e. Verify that the url field is present and carries a syntactically valid HTTPS URL. If it does not, discard this record.
Sort by priority. Collect all valid records and sort them by priority in ascending order, lowest value first. Records of equal priority MAY be tried in any order.
Connect. For each record in priority order: a. Establish a TLS connection to the host named in the url field. b. Where the client holds a pinned key binding for the Origin Domain, apply first, and verify the endpoint against the pinned key whether or not the record carries a pk field. Otherwise, where the record carries a pk field, verify the key per . On failure, skip to the next record. c. Determine the transport by applying the reading rule of to the record's transport and proto fields. Where that rule directs the client to SKIP the record, skip it and proceed to the next record by priority. Otherwise, initiate the MCP session over the transport the rule yields. 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.
HTTPS fallback. Attempt HTTPS-based discovery by fetching https://<origin>/.well-known/mcp/server-card.json per , or https://<origin>/.well-known/mcp per . If fallback succeeds, proceed with the MCP session. If fallback fails, discovery has failed.

This procedure does not consume the _alter.<domain> record and imposes no DNSSEC requirement. A client that resolves an envelope executes instead, which does.

Identity Bootstrap Procedure: _org-alter.<domain> This is the procedure by which an org-alter implementation reads its own DNS records on first install to populate its canonical identity state. It is the algorithm of , unchanged, restated here in full.

Input The procedure takes a single input, the operator's primary domain name, being the Policy Domain under which the operator publishes records.

Algorithm

Query _org-alter.<domain> TXT. Issue a DNS query for the Org-Identity Record.
If found, parse and load. Extract org, entity, entity-type, founded, regions, regulated, and mcp-policy into the org-alter's identity state. These become the canonical identity declaration the org-alter uses in all subsequent self-reports, brief generation, and external attestation.
If bootstrap= is present, fetch the bootstrap document over HTTPS. Validate the document's TLS certificate against the Policy Domain. Merge the document's roster, logo, and extension fields into the identity state. Reject the bootstrap document if its TLS certificate is invalid, or if its content does not parse.
Honour regulated= and mcp-policy= as immutable structural constraints on the org-alter instance. a. If regulated carries any framework token, set the org-alter's boundary policy to refuse, and disable every passive ingester layer. b. If mcp-policy=refuse-tenant, the org-alter MUST refuse to install any ingester that requires authenticated access to a tenant covered by the declared framework, even where credentials are subsequently provided. c. The wizard SHOULD display these constraints to the operator for confirmation, and MUST NOT allow the operator to override them silently. An operator who wishes to relax a constraint MUST update the DNS record first, then re-run bootstrap.
Cross-check _mcp.<domain>. Query the service-discovery record of . Where both records exist and both publish a pk field, the values MUST match. A mismatch indicates either a configuration error or a key compromise; the wizard MUST refuse to bootstrap under that condition, and MUST surface the discrepancy to the operator. states how this rule relates to the envelope key of , which is a distinct key and is not subject to it.
Verify against public registries. Where the entity field declares a known registry namespace (for example abn:), the wizard SHOULD query the corresponding free public registry and verify that the declared entity identifier resolves to the declared org name. A mismatch is not necessarily fatal, because names change and registries lag, but the wizard MUST surface the discrepancy and MUST require operator confirmation before proceeding.
Persist canonical state. Write the resolved identity into the org-alter's local identity state, source-citing each field to its DNS or HTTPS origin.

First-Run Cold Start For an operator who has not yet published an _org-alter record at the time of installation, the wizard MUST fall back to interactive seeding. It prompts for org, optionally prompts for entity, and asks whether the operator's environment is regulated. After interactive seeding, the wizard SHOULD generate a draft DNS record value for the operator to publish, which completes the bootstrap loop.

Envelope Recognition Procedure: _alter.<domain> The procedure takes two inputs, a zone and the ~handle to be recognised, and both are REQUIRED. An alter:~<handle> reference supplies both. A resolver that has only a zone, and no handle, cannot execute this procedure. Step 4 selects the record whose h= matches the requested handle, and with no requested handle there is nothing to match against. Such a resolver has not been asked a recognition question, and MUST NOT treat whatever record it finds at the owner name as the answer to one. Given those two inputs, a resolver MUST execute the following steps in order. Steps 1 through 8 and step 10 are FATAL: failure of any of them terminates recognition, and the envelope MUST be treated as unverified. Steps 9, 11 and 12 are ADVISORY in one specific sense, and one only: BEING UNABLE TO PERFORM THEM MUST NOT terminate recognition, because a resolver that cannot reach a surface has learned nothing either way. A POSITIVE finding at one of them is a different matter, and step 12 is the case that bites: a revocation actually observed is FATAL and MUST abort (step 12; ). Revision 04 made every step fatal, including steps that a conformant resolver cannot perform at all, which made verification unreachable.

Query. Issue a DNS TXT query for _alter.<zone>.. Use DoH or DoT in preference to UDP/53 where operationally feasible.
DNSSEC validation. Validate the RRSIG chain from the root trust anchor to the TXT RRset (). Confirm the AD bit on the response when relying on an upstream validating resolver, or locally RRSIG-validate in validating-stub mode. On failure, abort.
Chunk reassembly. Concatenate character-strings in RR order; parse ; -separated key-value pairs.
Handle disambiguation. Select the record whose h= field matches the requested ~handle. If no record matches, abort.
Field extraction. Confirm presence of the seven required fields (v, h, pk, ilr, ts, rev, sig). Reject any record missing any required field, or whose v is not alter1.
Envelope reconstruction. Build the envelope JSON exactly as specifies, deriving signature_alg from the pk= prefix and supplying an empty caveats array.
JCS canonicalisation. Apply JCS to the envelope with the sig field absent.
Ed25519 verification. Verify the detached sig over the JCS byte stream using the public key in pk. On failure, abort.
IdentityLog cross-reference (ADVISORY, no longer fatal). A resolver with an independent view of the log MAY confirm that the root named in ilr= is one the log published. A resolver MUST NOT abort on failure, and MUST NOT treat success as evidence that this envelope is in the log, because ilr= carries no proof of inclusion (; ). Revision 04 made this step fatal on a check that cannot do what it claimed.
DANE TLSA validation. When establishing an MCP session at mcp.<zone> as part of the same recognition transaction, fetch the TLSA record at _443._tcp.mcp.<zone>. and gate the TLS handshake on the binding (). On mismatch, abort.
Caveats evaluation (OUT OF SCOPE for this document). The envelope schema admits an optional caveats array, which is never carried in DNS. This document specifies neither a transport for it nor a vocabulary, so a resolver implementing this document alone MUST treat the envelope as having no caveats, and MUST verify the signature over an empty caveats array per . A future document may define a caveats surface, and until one does, an envelope whose signer intended caveats cannot be distinguished from one that carries none. That limitation is stated here rather than hidden.
Revocation check (ADVISORY). Where the resolver has access to the log's revocation surface, consult it. This step is ADVISORY in the sense that being UNABLE to perform it MUST NOT terminate recognition; a resolver that cannot reach a revocation surface has learned nothing either way, and says why one implementing this document alone cannot. A POSITIVE result is another matter entirely: if a pre-image whose SHA-256 equals rev= has been revealed, the envelope IS revoked, recognition MUST abort, and the envelope MUST NOT be honoured however fresh the TXT RRset.

An envelope is verified when every FATAL step (1 through 8, and 10) has succeeded AND no ADVISORY step has returned a positive failure. The distinction matters at step 12: a resolver that CANNOT reach a revocation surface has learned nothing and proceeds, while a resolver that OBSERVES a revocation MUST abort and MUST NOT treat the envelope as verified. Steps 9, 11 and 12 are advisory only as to unreachability, because gating verification on a step no conformant implementation can execute would make verification unreachable, and a specification no one can satisfy is not a specification. A verified envelope is the sole admissible input to a recognition-over-qualification gate, and an unverified envelope MUST be refused upstream of any authorisation or trust decision. The twelve-step procedure above is normative and complete. It is not a summary of an algorithm specified elsewhere.

Caching The rules for the first two records are those of and , unchanged, 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 . 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 ( sets out why one working from this document alone is not) MUST re-run it on each recognition event, not on each cache refresh.

Key Continuity Revisions 01 through 06 said that a client caches a verified key binding and re-validates it, and said nothing about a re-validation that fails. Trust on first use is only as strong as the rule for the second use, and there was no such rule. This section supplies it. The mechanism is the one SSH clients have long applied to host keys, and it introduces nothing new. A pinned key binding is the triple a client holds after a successful verification under : the Origin Domain, the pk it verified, and the epoch the record carried at the time, defaulting to 0 where the record carried none. On each later resolution of _mcp.<domain> for which it holds a pin, the client compares the record it receives with the pin, and the following rules apply in order.

Same key, same epoch. Continuity holds. The client proceeds under .
Epoch lower than the pinned epoch. The epoch is monotonic (), so a decrease is never a state a conformant publisher produces. It indicates a stale or manipulated response, a publisher restoring an old record, or a new operator of the domain that began its own count at 0. The client MUST NOT lower its pinned epoch, and MUST NOT replace its pinned key on the strength of this record. It SHOULD re-query, bypassing any local cache it controls. Where the served key equals the pinned key, the client MAY proceed, and MUST evaluate the kid of any claim against its pinned epoch rather than the lower served one. Where the served key differs, the client MUST treat the server as untrusted, exactly as a failed verification under , and SHOULD surface the discrepancy.
Different key, same epoch. The record's own contract is that the epoch increments on every key rotation, so a key that changes without it is an undeclared change. The client MUST treat the server as untrusted, MUST NOT replace its pin, and SHOULD surface the discrepancy.
Different key, higher epoch. This is a declared rotation. The client MUST verify the new key per before replacing its pin, and on success MAY replace the pinned key and epoch. A declared rotation is also exactly what a new operator of a lapsed and re-registered domain can publish, because the epoch is self-asserted by whoever controls the zone. A client with access to registration data SHOULD therefore apply the change-of-control signals of before it replaces the pin.
Same key, higher epoch. The client MAY raise its pinned epoch. Claims under the lower epoch are then handled per .
No key. A record that carried a pk when the pin was made and now carries none has not released the pin. The client MUST continue to verify the endpoint against the pinned key, as step 7b of requires. Removing the field is not a way to rotate a key.

A pinned key MUST NOT be replaced automatically under rules 2, 3 or 6. It MAY be replaced by an action of the client's user or operator, taken outside this procedure and after the discrepancy has been surfaced to them.

Absence Is Not Revocation A client that holds a pin and finds no _mcp record, on NXDOMAIN or on NOERROR with no TXT records, proceeds to the HTTPS fallback of step 8 of . It MUST NOT clear the pin, and MUST NOT treat the absence as revocation of the binding or of any claim issued under it. A client that reaches an endpoint for the same Origin Domain by fallback SHOULD verify it against the pinned key. This is the position takes for the envelope record, and it is deliberate here for the same reason. A zone that is briefly unreachable, through an outage, a registrar incident or a tooling error, must not become a revocation event. It is deliberate for a second reason that applies to pins alone. If absence cleared a pin, an attacker able to suppress the record for a single resolution would reset the client to first use, and could then publish its own key and have it accepted as though no pin had ever existed. It is also a deliberate difference from , which holds in its Section 6.4 that removal of a record is revocation. The two records do different jobs. A domain-set record is an attestation its publisher withdraws by deleting it. An _mcp record is a pointer to an endpoint, and a key binding is revoked by rotation, under rule 4 above, never by the record going away.

Change-of-Control Signals The epoch cannot distinguish a rotation by the existing operator from a rotation by a new one, because both publish a higher epoch and a new key. Registration data can, in part. Section 6.3 gives consumer rules for this case, graded by the strength of the signal, and this document adopts them for the pinned key binding. A client with access to registration data for the Origin Domain, for example through RDAP , SHOULD consume those signals in the order given there, and act on them as follows.

Creation date changed. The registry object was deleted and the name registered again, and renewal or restoration never changes it. The domain is now operated by a party the pin says nothing about. The client MUST discard the pin, MUST NOT carry the pinned binding, or any trust its user or operator attached to it, forward to whatever key the record now serves, and SHOULD surface the change. A binding made after that point is a first use, and MUST NOT be presented as a continuation of the earlier one.
Lapse indicators. A registry grace status, or an expiry earlier than the observation, means the registration lapsed. Control may have passed without deletion, because names sold on in expiry auctions keep their creation date. A declared rotation under rule 4 observed while a lapse indicator is present MUST NOT replace the pin automatically, and SHOULD be surfaced for the action of the user or operator described above.
Transfer indicators. A transfer event, or a change of sponsoring registrar, SHOULD be surfaced as a warning. It does not by itself block a declared rotation.

A change of control that leaves no trace in registration data, such as a sale inside one registrar with no lapse, followed by a declared rotation, is not detectable by a client following this document. states the same limit for its own records. It is stated here rather than hidden.

Security Considerations (Security considerations from v01 and v02 are retained. Additional considerations introduced by the envelope layer are below.)

DNSSEC Downgrade The mandatory DNSSEC requirement in is the primary defence against on-path manipulation of envelope TXT content. An attacker who can inject unsigned responses, e.g. via a compromised resolver or a DNS middlebox that strips RRSIG, would otherwise be able to substitute an attacker-controlled envelope at the resolver boundary. Stub clients MUST reject any response lacking AD or failing local RRSIG verification. Operators MUST NOT downgrade the _alter. RRset to unsigned during KSK/ZSK rollover (see for best-current practice on rollover).

TLSA Pin Rotation The DANE TLSA requirement in binds the MCP endpoint's TLS leaf to a specific hash. Operators rotating certificates MUST publish the new TLSA record before the new certificate is activated on the live listener, with a grace window of at least twice the TLSA RRset TTL. Selector 1 (SPKI) survives rotations that preserve the keypair; selector 0 requires republication on every rotation. Loss of the TLS private key forces certificate reissue and republication of the TLSA record, not silent cert replacement. It does not engage the rev= reveal path, which revokes the identity envelope and has no bearing on a TLS leaf.

Envelope Substitution An attacker in control of a domain's DNS can publish an arbitrary envelope for any ~handle claimed to be hosted under that zone. The structural defences, and the limit of each, are:

IdentityLog witness. This defence does not hold as specified, and revision 04 was wrong to claim it did. Revision 04 stated that substitution of a locally-minted envelope that had not been witnessed would fail, and that an attacker would have to corrupt a log mirror. Neither is true of the mechanism this document specifies. ilr= carries a bare tree root and no proof of anything, so a resolver can confirm that the named root was witnessed but CANNOT confirm that the envelope in front of it is a leaf under that root, and no field of would let it. A zone attacker therefore mints an envelope, copies any genuinely witnessed root out of the public log, signs, and publishes. The result satisfies every check the recognition procedure of specifies. As specified, ilr= establishes only that the publisher could read a public value. Implementers MUST NOT rely on ilr= to detect substitution.
Ed25519 signature. The detached signature binds the envelope to a specific Ed25519 key. An attacker who does not hold the private key cannot forge a valid sig. An attacker who does hold the private key has already compromised the handle; the revocation path () is the residual mitigation.
DNSSEC. prevents tampering with the TXT RRset in transit. This does not prevent a malicious zone operator from publishing a malicious envelope, that attack is caught at (1) and (2), but it prevents third-party substitution.

Revocation Opacity Revocation is effected by revealing the pre-image to the IdentityLog, not by removing the TXT record. Absence of a record is indistinguishable from misconfiguration; resolvers MUST NOT treat absence as revocation. This design is deliberate: a zone briefly unreachable (DNS outage, registrar incident, tooling error) must not accidentally become a revocation event. applies the same position to a pinned _mcp key binding, and says why it differs from . The cost is that a compromised zone may continue to serve a valid (but intended-to-be-revoked) envelope until the rightful handle-holder reveals the pre-image. This document does not specify where a reveal is published, and says why no such surface can be assumed, so revocation is not presently actionable by a resolver working from this document alone. Handle-holders SHOULD establish a pre-committed revocation reveal procedure at mint time.

Clock Skew and ts= The ts= inception timestamp is advisory: resolvers MAY use it to detect implausibly future envelopes (e.g. minted more than a few hundred seconds after current wall time) but MUST NOT rely on local clock for security-critical decisions. This document specifies no authoritative ordering anchor. ts= is self-asserted by the publisher and is advisory only.

Cross-Record Key Consistency Where all three records (_mcp, _org-alter, _alter) are published under one zone and each carries a pk field, the values MUST be evaluated for consistency. Two different rules apply, and revision 04 stated only one of them, which contradicted the bootstrap procedure it incorporated by reference. The _mcp.pk and _org-alter.pk fields are the service key and the organisational key. Step 5 of , restated from , requires them to MATCH where both are published, and requires a bootstrapping wizard to refuse and to surface the discrepancy where they do not. That rule is unchanged. A mismatch across that pair indicates a configuration error or a key compromise. The _alter.pk field is the Sovereign-tier envelope key. It is a structurally distinct key with a distinct purpose, it is NOT subject to the bootstrap match rule, and it MAY differ from both of the others. A resolver MUST NOT treat a difference between _alter.pk and either of the other two as evidence of anything. Where a zone operator has deliberately bound all three to one Ed25519 key, which is a common pattern in a single-operator deployment, a later mismatch indicates either a rotation in progress or a compromise, and resolvers SHOULD surface it. A resolver cannot distinguish that deployment from one that intended three distinct keys, because this document publishes no signal of the operator's intent, so the surfacing is advisory and MUST NOT be fatal.

Passive-Stream Coupling A publisher SHOULD NOT ride an inferred trait, a passive-stream derivative, or a provenance-tagged attribute on the _alter.<domain> record. Revision 04 asserted that none could, calling it a structural property rather than a recommendation, on the grounds that the ABNF enumerates every field a resolver accepts. That claim is WITHDRAWN. The ABNF of admits unknown-field = token "=" *qtext, which is arbitrary attribute carriage by construction, and requires resolvers to IGNORE unknown fields rather than reject the record. The qtext rule bounds only the field DELIMITER, so that an unknown field cannot swallow the semicolon and consume the fields after it. It bounds nothing about the field's meaning. Nothing in this document structurally prevents a publisher from riding additional attributes on this owner name, and a resolver MUST NOT infer from a record's conformance that it carries nothing else. Two consequences follow, and neither was stated before. An unknown-field is NOT covered by the signing input of , which spans the six required fields other than sig, plus the derived signature_alg and an empty caveats array, and nothing else. Any attribute riding the record is therefore UNSIGNED, and a resolver MUST NOT attribute it to the handle-holder. And because a resolver ignores what it does not recognise, the record is a viable carrier for data the envelope was never meant to convey. The privacy implications of passive inference are out of scope for this document; the carriage risk is not, and it is stated here.

Change of Control Every record this document defines names its subject by a domain, and a domain can change hands. When a registration lapses and the name is registered again, the new registrant controls the zone and can publish any of the three records. Nothing in the records changes shape when that happens, and no single resolution can tell the new operator from the old one. For the _mcp record, is the defence. A client that pinned the prior operator's key refuses an undeclared key change and an epoch that goes down, keeps its pin when the record disappears, and, where it can read registration data, discards the pin on a changed creation date rather than carrying it to the new operator. A client that has never connected before has no pin, and for that client a re-registered domain is indistinguishable from any other first use. For the _alter record, the limit stated in applies without change. The envelope carries no epoch, and this document specifies no pin for it. A new registrant can mint an envelope for a handle under a key of its own and satisfy every FATAL step of . A resolver that has previously verified an envelope for the same handle, and now finds a different pk, SHOULD surface the change. It learns nothing further from this document about which of the two keys the handle-holder controls.

Privacy Considerations (Privacy considerations from v01 and v02 are retained. Additional considerations introduced by the envelope layer are below.)

Public Handle Disclosure Publishing _alter.<domain> exposes the bound ~handle, its Ed25519 public key, its IdentityLog root, its inception timestamp, and its revocation-hash commitment to any DNS observer. Revision 04 called that exposure by design, on the grounds that the envelope is intended to be publicly verifiable. Public verifiability does not require public enumeration, and sets out why the two came bundled here and should not have. A handle-holder who requires concealment MUST NOT publish an _alter.<domain> record; alternative organs (the local alter-runtime daemon for local-only recognition, or a hardware-anchored device-organ quorum for device-local presence proof) support recognition without DNS publication.

DNS Query Metadata A resolver querying _alter.example.com reveals to its recursive resolver that it intends to verify the envelope hosted under that zone. Query metadata privacy is addressed at the transport layer: clients SHOULD prefer DoH () or DoT () over UDP/53 where operationally feasible. This consideration is identical to v01 / v02 and is repeated here for emphasis given the greater individual-identity sensitivity of the envelope surface.

Revocation Unlinkability The rev= field is the SHA-256 of a secret pre-image; publishing it does not disclose the pre-image. An observer cannot predict the pre-image or link it back to any identifier. Reveal at revocation time links the pre-image to the envelope, but only at the moment of revocation, not during the envelope's active lifetime.

IANA Considerations

Underscored DNS Node Name Registration This document requests IANA to update the entries in the "Underscored and Globally Scoped DNS Node Names" registry established by as follows. Each label is defined by this document, in the section named, and no longer by an earlier revision of it.

RR Type	_NODE NAME	Reference
TXT	`_mcp`	of this document
TXT	`_org-alter`	of this document
TXT	`_alter`	of this document

The _alter label is used to publish envelope records as defined in of this document. Formal registration of _alter in the RFC 8552 registry is proposed on Standards Action maturation of this draft; during the Internet-Draft phase, the label operates under the provisional-use convention established by _dmarc, _mta-sts, _mcp (this draft), and _org-alter (this draft).

alter: URI Scheme Registration This document cross-references the provisional URI scheme registration of alter: per Section 3. The full registration body is submitted to IANA separately. This document notes that recognition verifiers invoked via alter: URIs MUST follow of this document for envelope verification.

Envelope Version Registry This document defines the version tag v=alter1 for the _alter.<domain> record, independent of the identically-named tag on the _org-alter.<domain> record. Future versions (v=alter2 and beyond) SHOULD be coordinated with the ~alter implementation community and documented in successor revisions of this draft. Until a formal IETF working group is chartered for identity-envelope DNS publication, the authors maintain the version namespace.

Org-Alter Version Registry (unchanged from v02) The version tag v=alter1 for the _org-alter.<domain> record is preserved from v02. No changes are requested in this revision.

Registry Namespace Registry (unchanged from v02) The initial set of entity field registry namespaces (abn, acn, ein, ch, cro, lei) defined in v02 is preserved unchanged.

Framework Token Registry (unchanged from v02) The initial set of regulated framework tokens (disp, itar, ear, hipaa, gdpr, soc2, iso27001, iso42001, essential8, aprs) defined in v02 is preserved unchanged.

Signature Algorithm Registry This document defines the initial pk= and sig= algorithm namespace ed25519 for the _alter.<domain> record. Future algorithms (e.g. ed448, ml-dsa-65) MAY be registered by successor documents. Resolvers MUST reject records whose algorithm prefix is not registered at the resolver's protocol version.

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

Minimal Envelope for a Single Handle (NOT RECOMMENDED) A zone hosting a single Sovereign-tier handle publishes its envelope at _alter.<zone>.: ; " "ilr=; " "ts=1729123456; " "rev=; " "sig=" ) ]]> All base64url values in this example are illustrative. Production values are the Ed25519 public key, SHA-256 digests, and 64-byte detached signature encoded per Section 5 without padding.

Zone Hosting Multiple Handles (a publisher MUST NOT do this) This example is retained so that a resolver can read the records a v04 publisher may already have published. It is NOT a pattern to follow. The shape below IS the enumeration exposure described in the Applicability statement. One query at the owner name returns every handle the zone hosts, and none of the individuals listed can consent on behalf of the others. A publisher MUST NOT create it (). Resolvers disambiguate by the h= field: A resolver asked to verify ~bob at example.org selects the second RR.

Full Zone (All Three Records; the _alter record is NOT RECOMMENDED) A zone operator running an org-alter instance for their own principal handle publishes all three records: ]]> Together these expose: the MCP service endpoint and its capabilities (_mcp); the legal entity, regulatory posture, and jurisdictional regions (_org-alter); the Sovereign-tier envelope for ~alice (_alter); and the DANE TLSA pin on the MCP endpoint. A resolver may consume any subset according to its recognition requirement.

Instrument-Tier Handle (NOT RECOMMENDED) An AI instrument handle uses the ~cc- prefix: Instrument-tier envelopes are bound to a specific model version. Rotation of the model version produces a new ~cc- handle with a new envelope; the prior envelope remains verifiable over its active lifetime and is revoked by the IdentityLog reveal path when the model is retired.

Interoperability with Earlier Record Generations A domain that publishes only a v01 _mcp.<domain> record continues to work with all v01, v02, and v03 clients. Where that record carries a transport value in proto, a client conforming to this revision reads it under rule 3 of 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 v01 clients and is skipped by these. A domain that publishes _mcp.<domain> and _org-alter.<domain> (v02) continues to work with v02 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 (), so a conforming client should expect to find it absent and MUST NOT treat its absence as an error. A domain that publishes all three records benefits from:

Service discovery via _mcp.<domain> (v01).
Organisational identity bootstrap via _org-alter.<domain> (v02).
Individual identity recognition via _alter.<domain> (v03).
DNSSEC-authenticated envelope delivery ().
DANE TLSA binding on the MCP endpoint ().

A domain that publishes only _alter.<domain> (envelope-only, no MCP server, no organisational record) is permitted by the grammar. Revision 04 called it the appropriate configuration for a Sovereign-tier individual. That recommendation is WITHDRAWN, and the configuration is NOT RECOMMENDED per . 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.

Implementation Status This section records the status of known implementations at the time of publication, per . This section was materially wrong in revision 04, which described a deployment that does not exist. It is rewritten here against the zone as it actually resolves and the code as it is actually written. What follows is deployed, and nothing else is claimed. 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 . 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 requires. Revision 05 recorded this label as NXDOMAIN; it was provisioned after that revision was filed.

The zone is DNSSEC-signed, so the requirement of 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. Revision 05 stated the opposite, that the zone published no DNSKEY and the parent held no DS, and that statement was already wrong when it was filed: the zone was signed nine days earlier. The erroneous statement carried a consequence, that no Envelope Record could be relied upon in this zone until the zone was signed, and that consequence is withdrawn with it. 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 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 : 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, and this document does not claim otherwise.

NOT deployed, and stated plainly because revision 04 claimed otherwise:

_443._tcp.mcp.truealter.com does not resolve, so no DANE TLSA pin is published and the DANE binding of is untested in deployment.
There is no signed-tree-head federation and no witness-mirror network. Revision 04 described four independent witness surfaces including an on-chain anchor contract. None of them exist.
No inclusion proof is generated or checked anywhere. The ilr field of is published as a bare root with no proof attached. sets out what that permits.

The Envelope Record of 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 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 is new in revision 06. No implementation of it is claimed.

References Normative References Domain names - implementation and specification This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. DNS Security Introduction and Requirements The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] Resource Records for the DNS Security Extensions This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] Protocol Modifications for the DNS Security Extensions This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] Domain Name System (DNS) Case Insensitivity Clarification Domain Name System (DNS) names are "case insensitive". This document explains exactly what that means and provides a clear specification of the rules. This clarification updates RFCs 1034, 1035, and 2181. [STANDARDS-TRACK] The Base16, Base32, and Base64 Data Encodings This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] Augmented BNF for Syntax Specifications: ABNF Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. [STANDARDS-TRACK] Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby ADministrative Management Domains (ADMDs) can explicitly authorize the hosts that are allowed to use their domain names, and a receiving host can check such authorization. This document obsoletes RFC 4408. Guidelines and Registration Procedures for URI Schemes This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes. It obsoletes RFC 4395. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. SMTP MTA Strict Transport Security (MTA-STS) SMTP MTA Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers (SPs) to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate. Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA. The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services. JSON Canonicalization Scheme (JCS) Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. HTTP Message Signatures This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange. Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records) This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. Model Context Protocol Specification Agentic AI Foundation Informative References Agent Identity and Discovery (AID) Open Agent Registry, Inc. DNS for AI Discovery Infoblox, Inc. Infoblox, Inc. Deutsche Telekom Amazon Zero-Configuration Agent Discovery Cisco Systems Cisco Systems Agent Discovery Architecture CNNIC Jinan University China Mobile CNNIC SAIP: Signed Agent Identity Protocol SKGO Discovery of Model Context Protocol Servers via DNS TXT Records Alter Meridian Pty Ltd Discovery of Model Context Protocol Servers via DNS TXT Records Alter Meridian Pty Ltd The Domain Set Discovery Protocol (domain-set) EnCirca, Inc. EnCirca, Inc. EnCirca, Inc. DENIC eG Reserved Top Level DNS Names To reduce the likelihood of conflict and confusion, a few top level domain names are reserved for use in private testing, as examples in documentation, and the like. In addition, a few second level domain names reserved for use as examples are documented. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. DomainKeys Identified Mail (DKIM) Signatures DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK] DNSSEC Operational Practices, Version 2 This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC. The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies. This document obsoletes RFC 4641, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the DNSSEC operations. Domain-Based Message Authentication, Reporting, and Conformance (DMARC) This document describes the Domain-based Message Authentication, Reporting, and Conformance (DMARC) protocol. DMARC permits the owner of an email's Author Domain to enable validation of the domain's use to indicate the Domain Owner's or Public Suffix Operator's message handling preference regarding failed validation and to request reports about the use of the domain name. Mail-receiving organizations can use this information when evaluating handling choices for incoming mail. This document obsoletes RFCs 7489 and 9091. Specification for DNS over Transport Layer Security (TLS) This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. Improving Awareness of Running Code: The Implementation Status Section This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. DNS Queries over HTTPS (DoH) This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange. JSON Responses for the Registration Data Access Protocol (RDAP) This document describes JSON data structures representing registration information maintained by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses. This document obsoletes RFC 7483. MCP Server Cards n.d. .well-known/mcp Discovery Endpoint n.d. Identity Field Theory: Toward a Physics of Being Known Alter Meridian Pty Ltd

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

Document History 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 . 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 (). 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 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 unchanged.
Adopts the graded change-of-control signals of Section 6.3 for the pinned binding (), and adds and as informative references. 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 Section 6.4 is deliberate (). 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 , 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 .
Records in 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 defects in -04, and the completion of a document that had been claiming for two revisions to stand on its own while deferring half of itself to documents it cited by the wrong section number. No new mechanism is introduced in this revision.

Restores the citation of , which revision 01 carried and revisions 02 through 04 lost. It is the closest neighbour to the _mcp record and it published its shape first, and a reader of both documents should be told so by this one. also distinguishes it from , a different draft with the same acronym, and states how the two compose: is intentionally small and defers to protocol-specific mechanisms after discovery, and this document is what its mcp protocol token defers to.
Makes the stand-alone claim true. All three record formats are now given in full (, , ), as are all three procedures (, , ) and the caching rules (). Revisions 03 and 04 incorporated the first two records and their procedures by reference to revisions 01 and 02. Nothing is incorporated by reference now, and no reader of this document needs to fetch another one in the series.
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, transport names the binding, and transport is the term because the Model Context Protocol specification already calls this axis by that name. The alignment is with the neighbouring DNS agent-discovery drafts (), so an implementer reading two of them does not have to hold two meanings for one key.
States how to read an _mcp record published under revision 01 (), including the case revision 01 left unusable. A proto value that names neither the protocol family nor a known transport causes the record to be SKIPPED, exactly as revision 01 required, and is NOT read as a protocol family with the default transport applied. Widening the rule would newly accept records no client could ever use.
Reconciles the _mcp grammar with its prose. The grammar admits any token in proto and transport, because a resolver must parse a revision 01 record before it can decide what to do with it. Syntactic admissibility is not definition. proto has exactly one defined value and transport exactly three, the two sets are disjoint, and so the claim that no value is defined for both fields is now true, where in earlier drafting it was not.
Corrects a grammar defect inherited from revision 02. The _org-alter record defined org, entity and entity-type over 1*VCHAR, which excludes the space, so the grammar could not derive the values revision 02's own examples published. A text-value rule admitting SP, and excluding only the field separator, replaces it (). This is the first revision to carry that format as its own normative text, so it is the first that had to be able to derive its own examples.
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, and VCHAR includes the semicolon, so a single field could derive the whole rest of the record and consume the fields after it. Two character classes replace it, because the two kinds of value have different needs: qtext admits SP and excludes the semicolon, for a human-readable name; uri-char excludes both, for a URI, which carries no raw space and would otherwise run past its own end. A class that is right for a name is not thereby right for a URI.
States the exclusion that ABNF cannot express (). unknown-field matches only a field name this document does not define, so a defined field whose value is malformed is a malformed record and MUST be discarded, never re-read as an unknown field. Without the rule the alternation swallows every defect it exists to exclude, because token matches a defined name as readily as an undefined one. The split-on-semicolon parse in already behaved this way, so no implementation changes; the grammar now says what the parser was always doing.
Requires a publisher emitting transport to emit proto=mcp with it (). A revision 01 client ignores the transport field it does not know and reads proto, so transport=streamable-http; proto=sse was one record that resolved to two different transports depending on which revision read it.
Adds and , which situate this document against , , , and , and say why the payload here is carried in TXT rather than SVCB.
Corrects the IANA registry table (), which cited the three labels to sections of revisions 01, 02 and 03, by numbers that were wrong in any case. Each label is now cited to the section of this document that defines it.
Rewrites (Implementation Status). The -04 section was false on four counts. It claimed an _org-alter record that does not resolve, a DANE TLSA pin that does not resolve, an envelope record exercising the field set where the deployed record carries none of those fields, and a four-surface signed-tree-head witness federation, including an on-chain anchor contract, none of which exists. The section now states only what is deployed, and states plainly what is not.
Corrects defence (1). The -04 text claimed that ilr= defeats envelope substitution. It does not. ilr= is a bare root with no inclusion proof, so a forged envelope naming any genuinely witnessed root passes every specified check. The false claim is withdrawn and the limit is stated.
Fixes the signing input of , which no third party could have interoperated with. The keys are now the TXT field names, v is inside the signed object, and ts is a JSON string of the wire digits rather than a JSON number. The construction is now normative and exhaustive.
Derives signature_alg from the pk= algorithm prefix via the registry of , rather than injecting Ed25519 as an implicit constant into the signed bytes. Taken alone this change is byte-compatible, because for pk=ed25519: the derivation yields the string the constant supplied. The revision as a whole is NOT byte-compatible: the signing-input repair above changes the signed bytes deliberately, so an envelope signed under -04 does not verify under -05. No envelope signed under -04 exists.
Relaxes the multi-string rule of , which prohibited splitting within a key-value pair and thereby made any field longer than 255 octets unrepresentable in a TXT record. Resolvers already concatenate before parsing, so the prohibition bought nothing and cost the ability to carry a large signature at all.
Marks publication of a per-individual envelope in DNS as NOT RECOMMENDED (). A zone MUST NOT publish envelopes for more than one handle at one owner name, because a single query there returns the whole set, which is a membership roll that no one listed in it can consent to on behalf of the others. The envelope format, its signing input and its verification procedure are not implicated.
Withdraws the IdentityLog witness federation, everywhere it was asserted. Revision 04 defined it in the terminology, required it normatively in and , made it fatal at step 9 of the recognition procedure, and named four witness surfaces including an on-chain anchor contract. None of those surfaces exist. The ilr= field is retained, so the wire format does not break, but the cross-reference is now advisory and the document states plainly what the field can and cannot establish.
States, rather than papers over, the fact that a reader implementing from this document alone cannot check revocation. The surface that carries reveals is not specified here and is not published anywhere fetchable.
Repairs every internal cross-reference, and repairs the class rather than the instances. The -04 prose was written against an older section numbering and never renumbered, so a reader following a pointer to the Envelope Record landed on the DNSSEC section. Every reference to a section of this document is now a symbolic anchor that cannot go stale under renumbering. The only literal section numbers that remain in the prose point into other documents.
Corrects all four references into and . Every one of them named the wrong section. The _mcp record format is Section 5 of and was cited as Section 3; its discovery procedure is Section 6 and was cited as Section 4. The _org-alter record format is Section 6 of and was cited as Section 4; its bootstrap procedure is Section 7 and was cited as Section 6. A reader who followed any of them arrived at the wrong section of the right document.
Restates the discovery procedure (), the identity bootstrap procedure (), and the caching rules for both records () in full. Revisions 03 and 04 claimed to stand alone while deferring three procedures to documents they cited incorrectly. The record formats are restated in full as well, so nothing at all is now incorporated by reference, and both earlier revisions carry a reference entry, which neither had.
Gives the _alter record two ABNF grammars (), one for publisher emission and one for resolver acceptance. Revision 04 gave the publisher grammar alone, then required resolvers to accept orderings that grammar cannot derive. The field-cardinality rule, which ABNF cannot express, is stated normatively beside it, and the v-first rule is reconciled with the ordering freedom rather than contradicting it.
Reconciles with step 5 of . Revision 04 said the _mcp and _org-alter keys MAY differ, while the bootstrap procedure it incorporated by reference required them to MATCH and required a wizard to refuse on mismatch. The bootstrap rule stands. The envelope key of is the key that is genuinely distinct, and it alone MAY differ from the other two.
Removes two hand-written reference sections that duplicated the generated ones and cited five documents with no reference entry.
Corrects the field count throughout. Seven fields are REQUIRED; the -04 prose said five in three places.

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 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 ().
Defines v, h, pk, ilr, ts, rev, sig fields for the new record.
Introduces a mandatory DNSSEC validation requirement for _alter.<domain> responses ().
Introduces a mandatory DANE TLSA pin on the MCP endpoint () for envelope-triggered MCP sessions.
Adds the IdentityLog cross-reference requirement (). Revision 05 withdraws it; see the -05 entry above.
Adds a provisional alter: URI scheme cross-reference per ().
Adds the envelope recognition procedure (), a twelve-step algorithm.
Adds IANA registration for _alter underscore-prefixed label () and the independent v=alter1 envelope version namespace.
Adds a Signature Algorithm Registry () 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

cwhiteside.engineering@gmail.com