Discovery of Model Context Protocol Servers via DNS TXT Records

1.1. Requirements Language

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

5.1. DNS Location

The Envelope Record is a DNS TXT resource record [RFC1035] 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 [RFC8552] 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.¶

5.2. ABNF Grammar

The record value is a semicolon-delimited sequence of key-value pairs. The following ABNF (per [RFC5234]) 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.¶

5.3. Field Definitions

5.4. 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 [RFC8785] 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.¶

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

5.6. Multi-String Reassembly

Where the serialised envelope exceeds the 255-octet character-string limit of [RFC1035] 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.¶

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

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

10.3. 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 [RFC8785] 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; [ALTER-STH]). 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 [ALTER-DNS-PUB]. 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 [ALTER-DNS-PUB] Section 8; they differ only in that this document splits caveats and revocation into distinct steps for clarity.¶

12.1. 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 [RFC6781] for best-current practice on rollover).¶

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

12.3. 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 [RFC9162] 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.¶

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

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

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

12.7. 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 [ALTER-DNS-PUB] and its caveats surface, not in DNS.¶

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

13.2. 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 ([RFC8484]) or DoT ([RFC7858]) 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.¶

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

14.1. 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 [RFC8552] 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).¶

14.2. alter: URI Scheme Registration

This document cross-references the provisional URI scheme registration of alter: per [RFC7595] Section 3. The full registration body is published in [ALTER-DNS-PUB] 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.¶

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

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

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

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

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

15.1. 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 [RFC4648] Section 5 without padding.¶

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

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

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

18.1. Normative References

[RFC1035]

Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC4033]

Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/info/rfc4033>.

[RFC4034]

Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <https://www.rfc-editor.org/info/rfc4034>.

[RFC4035]

Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, <https://www.rfc-editor.org/info/rfc4035>.

[RFC4648]

Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.

[RFC5234]

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

[RFC6698]

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

[RFC7208]

Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, <https://www.rfc-editor.org/info/rfc7208>.

[RFC7595]

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

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8461]

Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A., and J. Jones, "SMTP MTA Strict Transport Security (MTA-STS)", RFC 8461, DOI 10.17487/RFC8461, September 2018, <https://www.rfc-editor.org/info/rfc8461>.

[RFC8552]

Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, <https://www.rfc-editor.org/info/rfc8552>.

[RFC8785]

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

[MCP]

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

18.2. Informative References

[RFC6376]

Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, <https://www.rfc-editor.org/info/rfc6376>.

[RFC6781]

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

[RFC7489]

Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, <https://www.rfc-editor.org/info/rfc7489>.

[RFC7858]

Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/info/rfc7858>.

[RFC7942]

Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, <https://www.rfc-editor.org/info/rfc7942>.

[RFC8484]

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

[RFC9162]

Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, December 2021, <https://www.rfc-editor.org/info/rfc9162>.

[MORRISON-IFT]

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

[ALTER-DNS-PUB]

Morrison, B., "ALTER DNS Publication, v1", 2026, <https://truealter.com/docs/protocol/alter-dns-publication-v1>.

[ALTER-STH]

Morrison, B., "IdentityLog STH Anchor, v1", 2026, <https://truealter.com/docs/protocol/identitylog-sth-anchor-v1>.