]> Alter Meridian Pty Ltd

Cronulla, NSW Australia blake@truealter.com

This document defines a DNS-based mechanism for the discovery of Model Context Protocol (MCP) servers and the identity properties of the organisations that operate them. Two TXT resource records are defined. The _mcp.<domain> record (defined in v01 of this document) 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 this revision) 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. Together, the two records provide both service discovery and identity bootstrap from a single canonical source -- the domain's own DNS zone. The mechanism complements HTTPS-based discovery (.well-known/mcp/server-card.json) by providing a lightweight, resolver-cached bootstrap that requires no HTTPS round-trip. The design follows the precedent established by DKIM , SPF , DMARC , and MTA-STS , all of which use DNS TXT records at underscore-prefixed labels to advertise domain-scoped policy and service metadata.

Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 7, 2026.

Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document.

Introduction Model Context Protocol (MCP) is an open protocol for structured interaction between AI agents and tool-providing servers. A complete agent-to-organisation interaction has two 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. 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 introduces via the new _org-alter.<domain> record.

The two questions are distinct. An MCP client may need to discover an endpoint without caring about the operator's identity. An onboarding wizard installing an org-alter instance may need to read the operator's identity without caring (yet) about the MCP endpoint. Conflating both into a single TXT record would force every consumer to parse fields it does not need and would crowd the 255-byte character-string limit. Splitting them across two 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. 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>. The org-identity layer is grounded in the identity field framework of . An organisation's identity is not a single boolean fact but a continuous field maintained across the social-spatial manifold. A DNS record provides a discrete checkpoint into that field. The _org-alter.<domain> record is the operator's own canonical declaration of their identity at a point in time, signed by their control of the DNS zone, and consumable by any bootstrap process -- including, critically, the operator's own org-alter instance reading its own record on first install.

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 is retained. Additional terms introduced in this revision are defined below.)

Org-Identity Record

A DNS TXT resource record published at the _org-alter label under a Policy Domain, conforming to the syntax defined in Section 4 of this document.

Identity Bootstrap

The procedure by which an org-alter implementation reads its own Org-Identity Record on first install to populate its canonical identity state without requiring manual operator entry.

Canonical Entity Identifier

A globally-unique, jurisdiction-issued identifier that names the legal entity behind the operator. Examples include the Australian Business Number (ABN), the Companies House number, the EIN, the CRO number, or the LEI.

Regulatory Refusal Marker

A declaration in the Org-Identity Record that the operator is bound by a named regulatory framework (e.g. DISP, ITAR, HIPAA) and that any automated access pathway crossing into the regulated boundary MUST be refused. This is a structural promise from the operator to the world: do not attempt to integrate, even with credentials.

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) This section defines the new Org-Identity Record introduced in v02.

DNS Location The Org-Identity Record is a DNS TXT resource record published at the label _org-alter prepended to the Policy Domain: _org-alter.<policy-domain>. IN TXT "<record-value>" 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 [RFC5234] defines the syntax: ``` orgalter-record = version *( ";" SP field ) version = "v=alter1" field = org-field / entity-field / entity-type-field / founded-field / regions-field / regulated-field / bootstrap-field / mcp-policy-field / epoch-field / pk-field / attest-field / ext-field / unknown-field org-field = "org=" 1VCHAR entity-field = "entity=" registry ":" 1VCHAR entity-type-field = "entity-type=" 1VCHAR founded-field = "founded=" date-fullyear regions-field = "regions=" region-csv regulated-field = "regulated=" framework-csv bootstrap-field = "bootstrap=" https-uri mcp-policy-field = "mcp-policy=" policy-token epoch-field = "epoch=" 1DIGIT pk-field = "pk=" algo ":" base64url attest-field = "attest=" attest-csv ext-field = "ext=" https-uri unknown-field = token "=" *VCHAR registry = "abn" / "acn" / "ein" / "ch" / "cro" / "lei" / token region-csv = region-token ( "," region-token ) region-token = 2ALPHA ; ISO 3166-1 alpha-2 framework-csv = framework-token *( "," framework-token ) framework-token = "disp" / "itar" / "ear" / "hipaa" / "gdpr" / "soc2" / "iso27001" / "iso42001" / "essential8" / "aprs" / token policy-token = "open" / "refuse-automated" / "refuse-tenant" / "refuse-all" / token date-fullyear = 4DIGIT [ "-" 2DIGIT [ "-" 2DIGIT ] ] algo = "ed25519" base64url = 1( ALPHA / DIGIT / "-" / "" ) https-uri = "https://" *VCHAR token = 1*( ALPHA / DIGIT / "-" / "" ) ```

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: org=Alter Meridian Pty Ltd org=Red Group Pty Ltd org=International Business Machines Corporation

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: entity=abn:54696662049 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: regions=AU,NZ,SG

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.

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.

Identity Bootstrap Procedure This section defines the procedure by which an org-alter implementation reads its own DNS records on first install to populate its canonical identity state.

Inputs The procedure takes a single input: the operator's primary domain name (the Policy Domain under which the operator publishes records).

Algorithm

1. Query _org-alter.<domain> TXT. Issue a DNS query for the Org-Identity Record.
2. If found, parse and load. Extract org, entity, entity-type, founded, regions, regulated, mcp-policy into the org-alter's identity state. These become the canonical identity declaration the org-alter will use in all subsequent self-reports, brief generation, and external attestation.
3. 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.
4. Honour regulated= and mcp-policy= as immutable structural constraints on the org-alter instance: a. If regulated includes any framework token, set the org-alter's boundary_policy to refuse and disable all L5/L6 ingester layers. 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 if credentials are subsequently provided. c. The wizard SHOULD display these constraints to the operator for confirmation but 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.
5. Cross-check _mcp.<domain>. Query the v01 service-discovery record. If both records exist and both publish pk fields, the values MUST match. A mismatch indicates either a configuration error or a key compromise; the wizard MUST refuse to bootstrap under such conditions and MUST surface the discrepancy to the operator.
6. Verify against public registries. If the entity field declares a known registry namespace (e.g., abn:), the wizard SHOULD query the corresponding free public registry (e.g., the ABR Lookup MatchingNames API) and verify that the declared entity identifier resolves to the declared org name. A mismatch is not necessarily fatal -- names change, registries lag -- but the wizard MUST surface the discrepancy and require operator confirmation before proceeding.
7. Persist canonical state. Write the resolved identity into the org-alter's state/identity.json, source-citing each field to its DNS or HTTPS origin.

The bootstrap procedure is designed to make first-run org-alter installation a single command: mcp-org-alter onboard --domain redgroup.com.au with the wizard reading every other field from DNS and the public record before asking the operator a single question.

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

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.

Caching Caching of _mcp.<domain> records follows v01. _org-alter.<domain> records SHOULD be cached for the duration of the DNS TTL. Onboarding wizards typically read the record once at install time and persist the resolved state to local storage; the DNS record need not be re-read on every subsequent invocation. Wizards MAY re-read the record on operator request, on epoch change detection (via periodic background poll), or on identity verification failure.

Security Considerations (Security considerations from v01 are retained. Additional considerations introduced by the org-identity layer are below.)

Identity Impersonation A domain operator can publish any org and entity value they wish. Verification of the declared identity against a public registry (Section 6 step 6) is the structural defence against impersonation: a domain that claims to be Red Group Pty Ltd with entity=abn:00000000000 (a non-existent ABN) will be detected as fraudulent the first time any verifier cross-checks the registry. Operators with a legitimate identity SHOULD publish their canonical entity field to opt into this verification path. Operators without a legitimate identity (or who publish a wrong one) become detectably non-conformant.

Regulatory Refusal as a Detectable Promise The regulated and mcp-policy fields are not enforcement mechanisms in themselves -- they are structural promises by the operator to the world. An attacker who controls a domain's DNS can publish a regulated field they have no intention of honouring, or omit it when they should publish it. These misrepresentations are detectable in two directions:

• An operator who publishes regulated=disp and then permits automated access to a DISP-accredited tenant is in violation of their own published declaration, which is a public, archivable, attributable record. This creates a stronger compliance artefact than any internal policy document.
• An operator who omits regulated=disp despite being a DISP member creates a discoverable inconsistency: their public Defence Industry Portal listing is one source, their DNS record is another, and any verifier can detect the discrepancy.

The structural value of these fields is therefore in the combination of public commitment and public verifiability, not in DNS-layer enforcement.

Entity Identifier Privacy Publishing a registry-issued entity identifier (ABN, EIN, Companies House number) makes the operator's legal entity discoverable. In most jurisdictions, this information is already public via the respective registries. The DNS record reduces the friction of discovery from "search a registry" to "dig a TXT record", but does not disclose anything that was not already obtainable. Operators with legitimate privacy concerns about linking their domain to their legal entity SHOULD NOT publish the entity field. A wizard reading an _org-alter record without an entity field MUST treat the org name as a self-declaration without registry verification, and MUST display this absence to the operator during bootstrap.

Bootstrap Document Risks The HTTPS bootstrap document (bootstrap= field) extends the identity surface beyond the DNS record's 255-byte limit. The document is fetched over HTTPS with TLS validation, but its content is operator-controlled. Wizards parsing the bootstrap document MUST apply the same forward-compatibility rules (ignore unknown fields) and MUST treat the document as untrusted input until cross-validated against DNS and registry sources. Wizards SHOULD NOT execute any code from a bootstrap document and MUST NOT load JavaScript or any active content. The document is a structured data file, not a runtime payload.

Privacy Considerations (Privacy considerations from v01 are retained. Additional considerations introduced by the org-identity layer are below.)

Organisational Privacy vs Individual Privacy The _org-alter record is a domain-level declaration about an organisation, not an individual. No per-user information appears in the record. The fields describe the legal entity, its registry identifier, its founding date, its operational regions, and its regulatory framework -- all of which are properties of the organisation. Individual identity, where the org-alter chooses to expose it, is mediated by the MCP server behind the endpoint, subject to application-level consent and access control mechanisms outside the scope of this document.

DNS Query Metadata A client resolving _org-alter.example.com reveals to its resolver that it intends to bootstrap an org-alter identity for example.com. The privacy considerations of v01 (DoH/DoT preference) apply identically.

IANA Considerations

Underscored DNS Node Name Registration This document requests IANA to register the following entries in the "Underscored and Globally Scoped DNS Node Names" registry established by : +--------+--------------+-----------------------------+ | RR Type| _NODE NAME | Reference | +--------+--------------+-----------------------------+ | TXT | _mcp | [this document], v01 Sec.3 | | TXT | _org-alter | [this document], v02 Sec.4 | +--------+--------------+-----------------------------+ The _org-alter label is used to publish Org-Identity Records as defined in Section 4 of this document.

Org-Alter Version Registry This document defines the version tag v=alter1 for the _org-alter record. Future versions (e.g., v=alter2) SHOULD be coordinated with the org-alter implementation community. Until a formal IETF working group is chartered for org-identity discovery, this document recommends that the version registry be maintained by the authors and that all extensions be documented in successor revisions of this draft.

Registry Namespace Registry This document defines an initial set of entity field registry namespaces (abn, acn, ein, ch, cro, lei). Future registries MAY be added by successor documents. Implementations MUST treat unknown registry namespaces as opaque identifiers and MUST NOT reject records solely on the basis of an unknown namespace.

Framework Token Registry This document defines an initial set of regulated framework tokens (disp, itar, ear, hipaa, gdpr, soc2, iso27001, iso42001, essential8, aprs). Future tokens MAY be added by successor documents. Implementations MUST treat unknown tokens conservatively (assume strictest defensible refusal) rather than ignoring them.

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

Minimal Record (Public Operator) The simplest valid Org-Identity Record contains only the version, canonical org name, and entity identifier: _org-alter.alter.com.au. IN TXT "v=alter1; org=Alter Meridian Pty Ltd; entity=abn:54696662049" A wizard reading this record knows the legal entity behind the domain, can verify the ABN against ABR Lookup, and treats the operator as unregulated (no regulated field present).

Full Public Record A complete record including founding date, regions, and key: _org-alter.alter.com.au. IN TXT ( "v=alter1; " "org=Alter Meridian Pty Ltd; " "entity=abn:54696662049; " "entity-type=Pty Ltd; " "founded=2026-03-29; " "regions=AU,NZ; " "epoch=1; " "pk=ed25519:dGhpcyBpcyBhIHNhbXBsZSBrZXk; " "attest=employ,contract,member; " "bootstrap=https://alter.com.au/.well-known/org-alter-bootstrap.json" ) This is the canonical declaration for ALTER itself.

Regulated Operator (DISP Refusal) A defence contractor running an org-alter at the unclassified meta-layer alongside a DISP-accredited M365 tenant: _org-alter.redgroup.com.au. IN TXT ( "v=alter1; " "org=Red Group Pty Ltd; " "entity=abn:XXXXXXXXXXX; " "entity-type=Pty Ltd; " "regions=AU; " "regulated=disp,essential8; " "mcp-policy=refuse-tenant; " "bootstrap=https://redgroup.com.au/.well-known/org-alter-bootstrap.json" ) Any onboarding wizard, external agent, or compliance verifier reading this record knows three things instantly: (1) Red Group is an Australian Pty Ltd entity registered in the ABR; (2) it operates under the DISP framework and Essential Eight Maturity Level 2; and (3) any automated access into the operator's regulated tenant is declared refused at the DNS layer. An agent that receives this record and proceeds to attempt tenant integration commits an attributable, publicly recorded violation.

Multi-Region Operator with Multiple Regulators A globally regulated operator: _org-alter.bigcorp.example. IN TXT ( "v=alter1; " "org=BigCorp Inc; " "entity=ein:12-3456789; " "regions=US,CA,GB,DE,SG,AU; " "regulated=hipaa,gdpr,soc2,iso27001; " "mcp-policy=refuse-tenant" ) The wizard treats this operator as bound by the strictest applicable framework and refuses any L5/L6 ingester layer touching healthcare, EU personal, or audited security systems.

Interoperability with v01 A domain that publishes only a v01 _mcp.<domain> record continues to work with all v01 and v02 clients. v02 clients additionally attempt to query _org-alter.<domain> and gracefully handle its absence. A domain that publishes both records benefits from:

• Service discovery via _mcp.<domain> (v01).
• Identity bootstrap via _org-alter.<domain> (v02).
• Cryptographic key consistency: if both records publish a pk field, the values MUST match, and a wizard reading both MUST verify the match before proceeding.

A domain that publishes only _org-alter.<domain> (identity-only, no MCP server) is permitted. This is the appropriate configuration for an organisation that wishes to publish a verifiable identity declaration without operating an MCP server endpoint.

Implementation Status This section records the status of known implementations at the time of publication, per [RFC7942]. ALTER (https://truealter.com) maintains a reference implementation of both 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.
• A standalone L0 discovery library (orgalter_discover) that resolves both records, validates against the Australian Business Register, and produces a structured discovery report ready for org-alter onboarding.
• 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 and uses streamable-http as the default transport.

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. 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] 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. 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. 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. 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] 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 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. n.d. n.d. n.d. n.d. n.d. n.d. Alter Meridian Pty Ltd

Discovery and Bootstrap Pseudocode The following pseudocode illustrates the combined discovery and bootstrap procedure defined in Section 6. It is non-normative. ``` function bootstrap_org_alter(domain): # Step 1: Read identity record txt = dns_query("_org-alter." + domain, type=TXT, prefer=DoH) if txt is None: return interactive_first_run(domain)

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

• Adds the _org-alter.<domain> Org-Identity Record (Section 4).
• Defines org, entity, entity-type, founded, regions, regulated, bootstrap, mcp-policy, epoch, pk, attest, ext fields for the new record.
• Adds the Identity Bootstrap procedure (Section 6).
• Adds IANA registration for _org-alter underscore-prefixed label.
• Adds version tag v=alter1 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.

Normative References (References from v01 are retained.)

Informative References (References from v01 are retained.)

Authors' Addresses Blake Morrison Alter Meridian Pty Ltd Cronulla, NSW 2230 Australia Email: blake@truealter.com URI: https://truealter.com