]> Alter Meridian Pty Ltd

Australia blake@truealter.com

This document defines a DNS-based mechanism for the discovery of Model Context Protocol (MCP) servers, the identity properties of the organisations that operate them, and (new in this revision) the cryptographic identity envelope bound to an individual Sovereign- tier ~handle published under the same zone. Three TXT resource records are defined. The _mcp.<domain> record (defined in v01) advertises the presence, endpoint URL, transport protocol, cryptographic identity, and capability profile of an MCP server associated with a domain name. The _org-alter.<domain> record (introduced in v02) advertises the canonical organisational identity of the domain operator: legal entity name, registry identifier, founding date, primary regions of operation, and any regulatory frameworks under which the operator is bound to refuse external automated access. The _alter.<domain> record (introduced in this revision) publishes an Ed25519-signed identity envelope binding a ~handle to a public key, an IdentityLog Signed Tree Head root, and a revocation commitment. Taken together, the three records provide service discovery, organisational identity bootstrap, and individual identity recognition from a single canonical source: the domain's own DNS zone. This revision additionally requires DNSSEC validation of envelope responses and a DANE TLSA pin binding the MCP endpoint's leaf certificate to the published zone. A companion URI scheme (alter:) is registered provisionally with IANA per for handle dispatch. The mechanism complements HTTPS-based discovery (.well-known/mcp/server-card.json and .well-known/alter-envelope.json) by providing a lightweight, resolver-cached bootstrap that requires no HTTPS round-trip. The design follows the precedent established by DKIM , SPF , DMARC , MTA-STS , and the existing _mcp. / _org-alter. labels of v01-v02.

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:

1. 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.
2. Organisational identity bootstrap. Who is the organisation operating the server? What is its legal entity? Where is it registered? Under what regulatory frameworks does it operate, and which automated access pathways must it refuse to participate in? This is the question v02 answers via the _org-alter.<domain> record.
3. Individual identity recognition. Who is the Sovereign-tier person bound to a ~handle hosted under the domain? What public key signs their statements? What append-only log anchors the lifecycle of their identity? How may their envelope be revoked? 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:~blake 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): each record serves a single semantic purpose. 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>. The envelope layer formalised in the new _alter.<domain> record is specified in full by a companion document, the ALTER DNS Publication specification , which pins the envelope JSON schema, the JSON Canonicalisation Scheme (JCS, ) serialisation, and the resolver-side verification algorithm. This document is the IETF-track surface for the underscore-prefixed DNS label registration and its DNSSEC / DANE / IdentityLog cross-references; it does not duplicate the envelope wire format beyond what is necessary to specify a conformant TXT grammar. 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, witnessed by the IdentityLog STH anchor surface , and consumable by any resolver with access to a DNSSEC-validating recursive resolver.

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

Terminology (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. Its full JSON schema, canonical serialisation rule, and verification procedure are pinned by . This document specifies only the TXT grammar that carries the five load-bearing envelope fields across DNS.

~handle

A Sovereign-tier identifier, leading tilde mandatory (e.g. ~blake). Bot-tier handles carry a .bot suffix (e.g. ~alice.bot); Instrument-tier handles use the prefix ~cc- (e.g. ~cc-opus-4-7).

IdentityLog

The append-only transparency log anchoring envelope lifecycle events (mint, caveat-add, revocation, key-rotation). A Signed Tree Head ("STH") is emitted per-minute and cross-anchored to Cloudflare R2, IPFS, a federation of independent mirrors, and the Base L2 chain via the IdentityLogAnchor contract. Protocol details are in .

Organ

A broadcast surface for the envelope. The three organs are: DNS publication (this document), the local alter-runtime L3 daemon, and the Patent-N HAD silicon 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 . Full registration body and handler guidance are specified in Section 7; a normative cross- reference is given in Section 9 of this document.

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

Record Format: _mcp.<domain> (Service Discovery) Section 3 of v01 of this document defines the _mcp.<domain> record, its ABNF grammar, field definitions (v, url, proto, pk, epoch, cap, attest, scope, priority, ttl, ext), forward-compatibility rules, and multi-string concatenation behaviour. These definitions are unchanged in this revision and are incorporated here by reference. Implementations MUST treat any existing _mcp.<domain> record as conformant to the v01 specification.

Record Format: _org-alter.<domain> (Identity Bootstrap) Section 4 of v02 of this document defines the _org-alter.<domain> record, its ABNF grammar, field definitions (v, org, entity, entity-type, founded, regions, regulated, bootstrap, mcp-policy, epoch, pk, attest, ext), identity bootstrap procedure, and registry cross-checks. These definitions are unchanged in this revision and are incorporated here by reference. Implementations MUST treat any existing _org-alter.<domain> record as conformant to the v02 specification.

Record Format: _alter.<domain> (Envelope Publication) This section defines the new Envelope Publication record introduced in v03. The record publishes the five load-bearing fields of the ALTER identity envelope (binding a ~handle to its Ed25519 public key, IdentityLog root, inception timestamp, revocation commitment, and detached signature) at an underscore-prefixed label under the handle's hosting zone. The full envelope JSON schema and wire format, including fields not carried over DNS (the implicit signature_alg constant and the optional caveats array), is pinned by .

DNS Location The Envelope Record is a DNS TXT resource record published at the label _alter prepended to the hosting zone: _alter.<zone>. IN TXT "<record-value>" The underscore prefix conforms to the conventions established in for globally scoped, underscore-prefixed DNS node names. A zone MAY host more than one ~handle (one envelope per handle); in that case the zone MUST publish multiple TXT RRs at the same owner name. Resolvers MUST disambiguate returned records by the h= field and select the record matching the requested handle. 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). The recommended pattern for an operator running an org-alter instance that hosts the operator's own principal handle (e.g. ~blake at truealter.com) is to publish all three.

ABNF Grammar The record value is a semicolon-delimited sequence of key-value pairs. The following ABNF (per ) defines the syntax: ``` alter-record = version ";" SP handle-field ";" SP pubkey-field ";" SP ilr-field ";" SP ts-field ";" SP rev-field ";" SP sig-field *( ";" SP unknown-field ) version = "v=alter1" handle-field = "h=" handle pubkey-field = "pk=" algo ":" base64url ilr-field = "ilr=" base64url ; SHA-256 of IdentityLog root ts-field = "ts=" 1*DIGIT ; inception_ts, Unix seconds rev-field = "rev=" base64url ; SHA-256 of revocation pre-image sig-field = "sig=" base64url ; Ed25519 detached signature unknown-field = token "=" *VCHAR handle = "~" 1( ALPHA / DIGIT / "-" / "_" ) [ "." "bot" ] / "~cc-" 1( ALPHA / DIGIT / "-" / "." ) algo = "ed25519" base64url = 1( ALPHA / DIGIT / "-" / "_" ) token = 1( ALPHA / DIGIT / "-" / "_" ) ``` The seven keys above are REQUIRED and MUST appear in the order shown. Publishers MUST NOT omit or reorder them. Resolvers MUST tolerate additional (unknown) fields appended after the seven required fields and MUST ignore them per the forward-compatibility rule (Section 6.4 below). Resolvers MUST tolerate arbitrary inter-field ordering on parse (publishers-emit-ordered, parsers- accept-unordered); canonicalisation for signature verification is specified in Section 6.3.

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. The h= value is the sole field resolvers MAY use to disambiguate multiple envelope TXT RRs sharing an owner name.

pk (REQUIRED) An Ed25519 public key prefixed by its algorithm namespace and encoded in base64url without padding per Section 5: pk=ed25519:<base64url-no-pad-32-bytes> 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 the IdentityLog root witnessed at envelope creation. Resolvers MUST cross-reference this value against the IdentityLog witness surface to confirm the envelope was minted within a recognised tree state. Failure to cross-reference renders the envelope unverified.

ts (REQUIRED) Envelope inception timestamp, expressed as decimal Unix seconds (integer). Resolvers MAY use this field to detect clock skew, evaluate caveat maturity, or reject envelopes with implausibly future inception.

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 load-bearing.

sig (REQUIRED) Base64url-no-pad Ed25519 detached signature over the JCS- canonicalised envelope JSON with the signature field absent. Canonicalisation is specified by . The signing input is the envelope JSON reconstructed from the parsed TXT fields plus the implicit constant signature_alg: "Ed25519" and an empty caveats array; caveats, when present, ride the HTTPS .well-known organ and do not appear in the DNS record. The canonical envelope schema, including JCS input construction, is pinned in Section 4.

Unknown fields Fields not enumerated above MUST be ignored by v03 resolvers per the forward-compatibility rule (Section 6.4). 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 Section 10.

Canonical Serialisation The sig input is constructed as follows:

1. Parse the TXT RR character-strings into key-value pairs.
2. Construct the envelope JSON object: json { "handle": "<h>", "pubkey": "<pk>", "identitylog_root": "<ilr>", "inception_ts": <ts>, "revocation_hash": "<rev>", "signature_alg": "Ed25519", "caveats": [] } Values are typed per Section 6.2 (inception_ts as JSON integer; all other values as JSON strings; caveats as JSON array, empty unless a companion .well-known fetch supplies content). The signature field MUST be absent from the signing input.
3. Apply JSON Canonicalisation Scheme to the object.
4. The resulting byte stream is the Ed25519 signing input.

Verification reverses this construction and checks the detached signature in the sig field against the derived byte stream. Publishers MUST emit TXT fields in the order given in Section 6.2, 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 Section 10.

Multi-String Reassembly Where the serialised envelope exceeds the 255-octet character-string limit of Section 3.3.14, publishers MUST split at ; boundaries between complete key-value pairs. Splitting within a key-value pair is prohibited. 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.

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 (Section 11). 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: _443._tcp.mcp.<zone>. IN TLSA <usage> <selector> <matching-type> <cert-association-data> Recommended parameters:

• Usage field. 3 (DANE-EE), pin the end-entity certificate directly, with no CA chain reliance. A publisher that explicitly requires CA-chain validation MAY use 1 (PKIX-EE) instead. Publishers MUST NOT use 0 (PKIX-TA) or 2 (DANE-TA) for the envelope 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 Signed Tree Head (STH) root witnessed at envelope creation. The IdentityLog protocol (leaf hashing, Merkle-tree construction, STH cadence, witness federation, Cloudflare R2 / IPFS / Base L2 anchor path) is specified in full by ; this document does not duplicate that specification. Resolvers verifying an envelope from DNS MUST cross-reference the ilr= value against at least one IdentityLog witness surface (federation mirror, R2 canonical read, IPFS content address, or Base L2 IdentityLogAnchor contract). The specific surface is a matter of deployment preference; Section 6 gives conforming client profiles. Failure to cross-reference renders the envelope unverified and it MUST NOT be admitted to any recognition-gated decision. The revocation check also crosses the IdentityLog: a resolver MUST consult the IdentityLog revocation-witness surface for any reveal whose SHA-256 equals the rev= field of the envelope. If a matching pre-image has been revealed, the envelope is revoked and MUST NOT be honoured regardless of the freshness of the TXT RRset.

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 and verifies the envelope through the organ chain defined in (DNS first, with fallback to the HTTPS .well-known surface and, where available, the local alter-runtime L3 daemon). Registration is provisional per Section 3. The full registration body, scheme syntax, semantics, encoding considerations, interoperability and security considerations, author and change controller, is published in Section 7 and 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 (Section 7), DANE TLSA binding (Section 8) when establishing any HTTPS session, IdentityLog cross- reference (Section 9), and the eleven-step verification algorithm of Section 8, before acting on any content or directive derived from the envelope.

Discovery and Bootstrap Procedures

Discovery Procedure: _mcp.<domain> The discovery procedure defined in Section 4 of v01 is unchanged in this revision. Clients querying _mcp.<domain> follow the v01 algorithm exactly.

Identity Bootstrap Procedure: _org-alter.<domain> The identity bootstrap procedure defined in Section 6 of v02 is unchanged in this revision. Onboarding wizards reading _org-alter.<domain> follow the v02 algorithm exactly.

Envelope Recognition Procedure: _alter.<domain> Given an alter:~<handle> reference, a zone hint, or a raw _alter.<zone>. query, a resolver MUST execute the following steps in order. Any failure terminates recognition and the envelope MUST be treated as unverified.

1. Query. Issue a DNS TXT query for _alter.<zone>.. Use DoH or DoT in preference to UDP/53 where operationally feasible.
2. DNSSEC validation. Validate the RRSIG chain from the root trust anchor to the TXT RRset (Section 7). 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.
3. Chunk reassembly. Concatenate character-strings in RR order; parse ; -separated key-value pairs.
4. Handle disambiguation. Select the record whose h= field matches the requested ~handle. If no record matches, abort.
5. 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.
6. Envelope reconstruction. Build the envelope JSON per Section 6.3, inserting the implicit signature_alg: "Ed25519" constant and an empty caveats array.
7. JCS canonicalisation. Apply JCS to the envelope with the signature field absent.
8. Ed25519 verification. Verify the detached sig over the JCS byte stream using the public key in pk. On failure, abort.
9. IdentityLog cross-reference. Confirm ilr= corresponds to a STH recognised in the IdentityLog witness set at or after ts (Section 9; ). On failure, abort.
10. 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 (Section 8). On mismatch, abort.
11. Caveats evaluation. Fetch the HTTPS .well-known companion surface and evaluate any caveats on the envelope per . Caveats that cannot be satisfied bound the subsequent use of the envelope but are not grounds to abort recognition.
12. Revocation check. Consult the IdentityLog revocation- witness surface. If a pre-image whose SHA-256 equals rev= has been revealed, the envelope is revoked; abort.

Only after all twelve steps succeed is the envelope considered verified. A verified envelope is the sole admissible input to a recognition-over-qualification gate; unverified envelopes MUST be refused upstream of any authorisation or trust decision. The twelve-step procedure above is the IETF-surface summary of the eleven-step verification algorithm in Section 8; they differ only in that this document splits caveats and revocation into distinct steps for clarity.

Caching Caching of _mcp.<domain> records follows v01. Caching of _org-alter.<domain> records follows v02. _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, but MUST re-run the revocation check (Section 11.12) on each recognition event, not on each cache refresh.

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 Section 7 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 Section 8 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 revocation via the revocation_hash reveal path (Section 9) rather than silent cert replacement.

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 three structural defences are:

1. IdentityLog witness. The ilr= cross-reference constrains the envelope to STHs witnessed by the IdentityLog federation; substitution of a locally-minted envelope that has not been witnessed will fail Section 11.9. An attacker who wishes to substitute must also corrupt at least one IdentityLog mirror, which is a detectable equivocation per design.
2. 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 (Section 9) is the residual mitigation.
3. DNSSEC. Section 7 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. 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. Pre-image reveal is a low-friction operation, a single authenticated POST to any IdentityLog mirror, but it requires the rightful holder to act. 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. The authoritative ordering anchor is the IdentityLog STH tree position, not the inception timestamp.

Cross-Record Key Consistency When all three records (_mcp, _org-alter, _alter) are published under the same zone and each carries a pk field, the values MUST be evaluated for consistency. The _mcp.pk and _org-alter.pk fields are v01/v02 service and organisational keys respectively; the _alter.pk field is the Sovereign-tier envelope key. These are structurally distinct purposes, and the keys MAY differ. However, where a zone operator deliberately binds all three to the same Ed25519 key (a common pattern for a single-operator deployment), a mismatch across records indicates either rotation-in-progress or compromise; resolvers SHOULD surface the discrepancy.

Passive-Stream Coupling The _alter.<domain> record carries only the five load-bearing envelope fields and the protocol version. No inferred trait, no passive-stream derivative, and no provenance-tagged attribute rides this record. This is a structural property, not a recommendation: the ABNF of Section 6.2 enumerates every field the resolver accepts, and the forward-compatibility rule only permits future named extensions, not arbitrary attribute carriage. The privacy implications of passive inference are addressed at the envelope semantic layer and its caveats surface, not in DNS.

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. For a Sovereign-tier handle this is by design: the envelope is intended to be publicly verifiable. Handle-holders who require concealment MUST NOT publish an _alter.<domain> record; alternative organs (the local alter-runtime daemon for local-only recognition, or the Patent-N HAD silicon 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 to reflect v03: +--------+--------------+----------------------------------+ | RR Type| _NODE NAME | Reference | +--------+--------------+----------------------------------+ | TXT | _mcp | [this document], v01 Sec.3 | | TXT | _org-alter | [this document], v02 Sec.4 | | TXT | _alter | [this document], v03 Sec.6 | +--------+--------------+----------------------------------+ The _alter label is used to publish envelope records as defined in Section 6 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 published in Section 7 and is submitted to IANA separately. This document does not duplicate the registration body; it refers to the sibling specification and notes that recognition verifiers invoked via alter: URIs MUST follow Section 11.12 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 A zone hosting a single Sovereign-tier handle publishes its envelope at _alter.<zone>.: _alter.truealter.com. 3600 IN TXT ( "v=alter1; h=~blake; " "pk=ed25519:<EXAMPLE-pubkey-32B-base64url>; " "ilr=<EXAMPLE-sth-root-32B-base64url>; " "ts=1729123456; " "rev=<EXAMPLE-revocation-hash-32B-base64url>; " "sig=<EXAMPLE-ed25519-signature-64B-base64url>" ) 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 zone hosting more than one handle publishes multiple envelope TXT RRs at the same owner name. Resolvers disambiguate by the h= field: _alter.example.org. 3600 IN TXT "v=alter1; h=~alice; pk=ed25519:..." _alter.example.org. 3600 IN TXT "v=alter1; h=~bob; pk=ed25519:..." _alter.example.org. 3600 IN TXT "v=alter1; h=~carol.bot; pk=ed25519:..." A resolver asked to verify ~bob at example.org selects the second RR.

Full ALTER Zone (All Three Records) A zone operator running an org-alter instance for their own principal handle publishes all three records: _mcp.truealter.com. IN TXT "v=mcp1; url=https://mcp.truealter.com/ ..." _org-alter.truealter.com. IN TXT "v=alter1; org=Alter Meridian Pty Ltd; ..." _alter.truealter.com. IN TXT "v=alter1; h=~blake; pk=ed25519:...; ilr=...; ts=...; rev=...; sig=..." _443._tcp.mcp.truealter.com. IN TLSA 3 1 1 <sha256-of-spki> 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 ~blake (_alter); and the DANE TLSA pin on the MCP endpoint. A resolver may consume any subset according to its recognition requirement.

Instrument-Tier Handle An AI instrument handle uses the ~cc- prefix: _alter.truealter.com. 3600 IN TXT ( "v=alter1; h=~cc-opus-4-7; " "pk=ed25519:...; ilr=...; ts=...; rev=...; sig=..." ) 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 v01 and v02 A domain that publishes only a v01 _mcp.<domain> record continues to work with all v01, v02, and v03 clients. A domain that publishes _mcp.<domain> and _org-alter.<domain> (v02) continues to work with v02 and v03 clients unchanged. v03 clients gain the ability to additionally query _alter.<domain> and gracefully handle its absence. 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 (Section 7).
• DANE TLSA binding on the MCP endpoint (Section 8).
• IdentityLog-anchored envelope lifecycle (Section 9).

A domain that publishes only _alter.<domain> (envelope-only, no MCP server, no organisational record) is permitted. This is the appropriate configuration for a Sovereign-tier individual who wishes to be recognisable under their own zone without operating an MCP server endpoint or declaring an organisational identity. The three records are orthogonal along their semantic axes but share the zone's DNSSEC trust root. A v03-compliant resolver that successfully 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 . ALTER (https://truealter.com) maintains a reference implementation of all three records:

• _mcp.truealter.com exercising the v01 field set including pk, epoch, attest, and ext.
• _org-alter.truealter.com exercising the v02 field set including entity, regulated, mcp-policy, and bootstrap.
• _alter.truealter.com exercising the v03 envelope field set (h, pk, ilr, ts, rev, sig) for the ~blake handle.
• _443._tcp.mcp.truealter.com publishing a DANE-EE / SPKI / SHA-256 TLSA pin on the MCP endpoint leaf.
• An IdentityLog STH anchor federation with four independent witness surfaces (Cloudflare R2 canonical, IPFS content- addressed, two federation mirrors, Base L2 IdentityLogAnchor contract).
• A standalone L0 discovery and recognition library (alter_discover) that resolves all three records, validates DNSSEC locally, fetches and verifies the DANE TLSA pin, cross- references the IdentityLog witness surface, and produces a structured recognition report.
• An alter: URI handler registered via xdg-mime on Linux/BSD and the corresponding platform registration paths on macOS, Windows, iOS, and Android.
• An onboarding wizard tool (mcp-org-alter onboard) that bootstraps a new org-alter instance from the published records with no manual data entry beyond the domain name.

The reference implementation targets MCP specification version 2025-11, uses streamable-http as the default transport, and treats DNSSEC + DANE + IdentityLog as a mandatory verification chain for any _alter.<domain>-derived recognition.

References Normative References This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. 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] 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] 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] 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] 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] 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] 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. 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. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. SMTP MTA Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers (SPs) to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate. Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA. The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services. 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. Agentic AI Foundation Informative References DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK] 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) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling. Originators of Internet Mail need to be able to associate reliable and authenticated domain identifiers with messages, communicate policies about messages that use those identifiers, and report about mail using those identifiers. These abilities have several benefits: Receivers can provide feedback to Domain Owners about the use of their domains; this feedback can provide valuable insight about the management of internal operations and the presence of external domain name abuse. DMARC does not produce or encourage elevated delivery privilege of authenticated email. DMARC is a mechanism for policy distribution that enables increasingly strict handling of messages that fail authentication checks, ranging from no action, through altered delivery, up to message rejection. This document 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. 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. 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. This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. Alter Meridian Pty Ltd Alter Meridian Pty Ltd Alter Meridian Pty Ltd

Recognition Pseudocode The following pseudocode illustrates the combined recognition procedure defined in Section 11.3. It is non-normative; the normative procedure is the twelve-step algorithm in the body of the document and the eleven-step algorithm in Section 8 to which it cross-references. ``` function recognise_envelope(handle, zone): # Step 1-2: Query + DNSSEC response = dns_query("_alter." + zone, type=TXT, prefer=DoH) if not response.ad_bit and not local_rrsig_validate(response): raise UnauthenticatedResponse

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

• Adds the _alter.<domain> Envelope Record (Section 6).
• Defines v, h, pk, ilr, ts, rev, sig fields for the new record, mirroring the canonical envelope fragment pinned by .
• Introduces a mandatory DNSSEC validation requirement for _alter.<domain> responses (Section 7).
• Introduces a mandatory DANE TLSA pin on the MCP endpoint (Section 8) for envelope-triggered MCP sessions.
• Adds the IdentityLog STH cross-reference requirement (Section 9), pointing at for the log protocol specification.
• Adds a provisional alter: URI scheme cross-reference per (Section 10).
• Adds the envelope recognition procedure (Section 11.3), a twelve-step algorithm that cross-refers to the eleven-step algorithm of Section 8.
• Adds IANA registration for _alter underscore-prefixed label (Section 13.1) and the independent v=alter1 envelope version namespace.
• Adds a Signature Algorithm Registry (Section 13.8) 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.
• v01 _mcp.<domain> and v02 _org-alter.<domain> record specifications are incorporated by reference and remain unchanged.

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.