Discovery of Model Context Protocol Servers via DNS TXT Records
draft-morrison-mcp-dns-discovery-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Author | Blake Morrison | ||
| Last updated | 2026-04-08 (Latest revision 2026-04-07) | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-morrison-mcp-dns-discovery-02
Network Working Group B. Morrison
Internet-Draft Alter Meridian Pty Ltd
Intended status: Informational April 2026
Expires: 10 October 2026
Discovery of Model Context Protocol Servers via DNS TXT Records
draft-morrison-mcp-dns-discovery-02
Abstract
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
[RFC6376], SPF [RFC7208], DMARC [RFC7489], and MTA-STS [RFC8461], 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 3 October 2026.
Morrison Expires 10 October 2026 [Page 1]
Internet-Draft MCP DNS Discovery April 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.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Status of This Memo . . . . . . . . . . . . . . . . . . . . . 3
2. Copyright Notice . . . . . . . . . . . . . . . . . . . . . . 3
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Record Format -- _mcp.<domain> (Service Discovery) . . . . . 5
6. Record Format -- _org-alter.<domain> (Identity Bootstrap) . . 5
6.1. DNS Location . . . . . . . . . . . . . . . . . . . . . . 6
6.2. ABNF Grammar . . . . . . . . . . . . . . . . . . . . . . 6
6.3. Field Definitions . . . . . . . . . . . . . . . . . . . . 7
6.3.1. v (REQUIRED) . . . . . . . . . . . . . . . . . . . . 7
6.3.2. org (REQUIRED) . . . . . . . . . . . . . . . . . . . 7
6.3.3. entity (RECOMMENDED) . . . . . . . . . . . . . . . . 7
6.3.4. entity-type (OPTIONAL) . . . . . . . . . . . . . . . 8
6.3.5. founded (OPTIONAL) . . . . . . . . . . . . . . . . . 8
6.3.6. regions (OPTIONAL) . . . . . . . . . . . . . . . . . 8
6.3.7. regulated (OPTIONAL but STRUCTURALLY SIGNIFICANT) . . 8
6.3.8. bootstrap (OPTIONAL) . . . . . . . . . . . . . . . . 9
6.3.9. mcp-policy (OPTIONAL) . . . . . . . . . . . . . . . . 10
6.3.10. epoch (OPTIONAL) . . . . . . . . . . . . . . . . . . 10
6.3.11. pk (OPTIONAL) . . . . . . . . . . . . . . . . . . . . 10
6.3.12. attest (OPTIONAL) . . . . . . . . . . . . . . . . . . 11
6.3.13. ext (OPTIONAL) . . . . . . . . . . . . . . . . . . . 11
6.4. Forward Compatibility . . . . . . . . . . . . . . . . . . 11
7. Identity Bootstrap Procedure . . . . . . . . . . . . . . . . 11
7.1. Inputs . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 11
7.3. First-Run Cold Start . . . . . . . . . . . . . . . . . . 13
8. Discovery Procedure -- _mcp.<domain> . . . . . . . . . . . . 13
9. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10.1. Identity Impersonation . . . . . . . . . . . . . . . . . 13
Morrison Expires 10 October 2026 [Page 2]
Internet-Draft MCP DNS Discovery April 2026
10.2. Regulatory Refusal as a Detectable Promise . . . . . . . 14
10.3. Entity Identifier Privacy . . . . . . . . . . . . . . . 14
10.4. Bootstrap Document Risks . . . . . . . . . . . . . . . . 14
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15
11.1. Organisational Privacy vs Individual Privacy . . . . . . 15
11.2. DNS Query Metadata . . . . . . . . . . . . . . . . . . . 15
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
12.1. Underscored DNS Node Name Registration . . . . . . . . . 15
12.2. Org-Alter Version Registry . . . . . . . . . . . . . . . 16
12.3. Registry Namespace Registry . . . . . . . . . . . . . . 16
12.4. Framework Token Registry . . . . . . . . . . . . . . . . 16
13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16
13.1. Minimal Record (Public Operator) . . . . . . . . . . . . 16
13.2. Full Public Record . . . . . . . . . . . . . . . . . . . 16
13.3. Regulated Operator (DISP Refusal) . . . . . . . . . . . 17
13.4. Multi-Region Operator with Multiple Regulators . . . . . 17
14. Interoperability with v01 . . . . . . . . . . . . . . . . . . 17
15. Implementation Status . . . . . . . . . . . . . . . . . . . . 18
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
16.1. Normative References . . . . . . . . . . . . . . . . . . 18
16.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Discovery and Bootstrap Pseudocode . . . . . . . . . 20
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 22
Appendix C. Normative References . . . . . . . . . . . . . . . . 23
Appendix D. Informative References . . . . . . . . . . . . . . . 23
Appendix E. Authors' Addresses . . . . . . . . . . . . . . . . . 23
1. 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.
2. Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Morrison Expires 10 October 2026 [Page 3]
Internet-Draft MCP DNS Discovery April 2026
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.
3. Introduction
Model Context Protocol (MCP) [MCP] is an open protocol for structured
interaction between AI agents and tool-providing servers. A complete
agent-to-organisation 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
[MORRISON-IFT]. 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.
Morrison Expires 10 October 2026 [Page 4]
Internet-Draft MCP DNS Discovery April 2026
3.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.
4. 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.
5. 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.
6. Record Format -- _org-alter.<domain> (Identity Bootstrap)
This section defines the new Org-Identity Record introduced in v02.
Morrison Expires 10 October 2026 [Page 5]
Internet-Draft MCP DNS Discovery April 2026
6.1. DNS Location
The Org-Identity Record is a DNS TXT resource record [RFC1035]
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
[RFC8552] 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.
6.2. 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=" 1_VCHAR entity-field = "entity=" registry ":"
1_VCHAR entity-type-field = "entity-type=" 1_VCHAR founded-field =
"founded=" date-fullyear regions-field = "regions=" region-csv
regulated-field = "regulated=" framework-csv bootstrap-field =
"bootstrap=" https-uri mcp-policy-field = "mcp-policy=" policy-token
epoch-field = "epoch=" 1_DIGIT pk-field = "pk=" algo ":" base64url
attest-field = "attest=" attest-csv ext-field = "ext=" https-uri
unknown-field = token "=" *VCHAR
Morrison Expires 10 October 2026 [Page 6]
Internet-Draft MCP DNS Discovery April 2026
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 / "-" / "_" )
```
6.3. Field Definitions
6.3.1. 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.
6.3.2. 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
6.3.3. 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).
Morrison Expires 10 October 2026 [Page 7]
Internet-Draft MCP DNS Discovery April 2026
* 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.
6.3.4. 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.
6.3.5. 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.
6.3.6. 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
6.3.7. 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.
Morrison Expires 10 October 2026 [Page 8]
Internet-Draft MCP DNS Discovery April 2026
* 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.
6.3.8. 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.
Morrison Expires 10 October 2026 [Page 9]
Internet-Draft MCP DNS Discovery April 2026
6.3.9. 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.
6.3.10. 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.
6.3.11. 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.
Morrison Expires 10 October 2026 [Page 10]
Internet-Draft MCP DNS Discovery April 2026
6.3.12. 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.
6.3.13. 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.
6.4. 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.
7. 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.
7.1. Inputs
The procedure takes a single input: the operator's primary domain
name (the Policy Domain under which the operator publishes records).
7.2. 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.
Morrison Expires 10 October 2026 [Page 11]
Internet-Draft MCP DNS Discovery April 2026
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.
Morrison Expires 10 October 2026 [Page 12]
Internet-Draft MCP DNS Discovery April 2026
7.3. 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.
8. 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.
9. 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.
10. Security Considerations
(Security considerations from v01 are retained. Additional
considerations introduced by the org-identity layer are below.)
10.1. 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.
Morrison Expires 10 October 2026 [Page 13]
Internet-Draft MCP DNS Discovery April 2026
10.2. 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.
10.3. 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.
10.4. 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.
Morrison Expires 10 October 2026 [Page 14]
Internet-Draft MCP DNS Discovery April 2026
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.
11. Privacy Considerations
(Privacy considerations from v01 are retained. Additional
considerations introduced by the org-identity layer are below.)
11.1. 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.
11.2. 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.
12. IANA Considerations
12.1. 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 [RFC8552]:
+--------+--------------+-----------------------------+ | 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.
Morrison Expires 10 October 2026 [Page 15]
Internet-Draft MCP DNS Discovery April 2026
12.2. 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.
12.3. 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.
12.4. 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.
13. Examples
This section provides non-normative examples of Org-Identity Records
for common deployment scenarios.
13.1. 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).
13.2. Full Public Record
A complete record including founding date, regions, and key:
Morrison Expires 10 October 2026 [Page 16]
Internet-Draft MCP DNS Discovery April 2026
_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.
13.3. 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.
13.4. 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.
14. 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.
Morrison Expires 10 October 2026 [Page 17]
Internet-Draft MCP DNS Discovery April 2026
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.
15. 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.
16. References
16.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>.
Morrison Expires 10 October 2026 [Page 18]
Internet-Draft MCP DNS Discovery April 2026
[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>.
[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>.
[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>.
[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>.
[RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP
Message Signatures", RFC 9421, DOI 10.17487/RFC9421,
February 2024, <https://www.rfc-editor.org/info/rfc9421>.
[MCP] Agentic AI Foundation, "Model Context Protocol
Specification", 2026, <https://modelcontextprotocol.io>.
16.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>.
[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>.
Morrison Expires 10 October 2026 [Page 19]
Internet-Draft MCP DNS Discovery April 2026
[RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
and Parameter Specification via the DNS (SVCB and HTTPS
Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
November 2023, <https://www.rfc-editor.org/info/rfc9460>.
[SEP-1649] "MCP Server Cards", n.d.,
<https://github.com/modelcontextprotocol/
modelcontextprotocol/issues/1649>.
[SEP-1959] "DNS-Based MCP Server Identity Verification", n.d.,
<https://github.com/modelcontextprotocol/
modelcontextprotocol/issues/1959>.
[SEP-1960] ".well-known/mcp Discovery Endpoint", n.d.,
<https://github.com/modelcontextprotocol/
modelcontextprotocol/issues/1960>.
[SEP-2127] "MCP Server Cards (PR)", n.d.,
<https://github.com/modelcontextprotocol/
modelcontextprotocol/pull/2127>.
[AID] "Agent Identity & Discovery", n.d.,
<https://datatracker.ietf.org/doc/draft-nemethi-aid-agent-
identity-discovery/>.
[SERRA] "MCP Discovery URI", n.d.,
<https://datatracker.ietf.org/doc/draft-serra-mcp-
discovery-uri/02/>.
[MORRISON-IFT]
Morrison, B., "Identity Field Theory: Toward a Physics of
Being Known", 2026,
<https://doi.org/10.6084/m9.figshare.31951383>.
Appendix A. 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)
Morrison Expires 10 October 2026 [Page 20]
Internet-Draft MCP DNS Discovery April 2026
record = parse_orgalter_record(txt)
if record.version != "alter1":
return interactive_first_run(domain)
# Step 2: Load core fields
state = {
"org": record.org,
"entity": record.entity,
"founded": record.founded,
"regions": record.regions,
"regulated": record.regulated or [],
"mcp_policy": record.mcp_policy or "open",
}
# Step 3: Honour regulated promise
if state["regulated"]:
state["boundary_policy"] = "refuse"
state["disabled_layers"] = ["L5", "L6"]
if state["mcp_policy"] == "refuse-tenant":
state["disabled_layers"] = list(set(state.get("disabled_layers", []) + ["L5", "L6"]))
# Step 4: Fetch optional bootstrap document
if record.bootstrap:
doc = https_get(record.bootstrap, validate_tls=domain)
if doc and is_valid_bootstrap_doc(doc):
state["roster"] = doc.get("roster", [])
state["logo_url"] = doc.get("logo_url")
state["public_website"] = doc.get("public_website")
# Step 5: Cross-check _mcp record key
mcp_record = parse_mcp_record(dns_query("_mcp." + domain, type=TXT))
if mcp_record and mcp_record.pk and record.pk:
if mcp_record.pk != record.pk:
raise IdentityMismatch("_mcp.pk and _org-alter.pk diverge")
# Step 6: Verify against registry
if record.entity:
registry, identifier = record.entity.split(":", 1)
if registry == "abn":
verified = abr_lookup(identifier)
if verified.name != state["org"]:
state["registry_warning"] = f"Declared org='{state['org']}' but ABN resolves to '{verified.name}'"
# Step 7: Persist canonical state
write_json("state/identity.json", state, source_cite="DNS+registry")
return state ```
Morrison Expires 10 October 2026 [Page 21]
Internet-Draft MCP DNS Discovery April 2026
Appendix B. 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.
Morrison Expires 10 October 2026 [Page 22]
Internet-Draft MCP DNS Discovery April 2026
* Registers _mcp in the underscored DNS node name registry.
Appendix C. Normative References
(References from v01 are retained.)
Appendix D. Informative References
(References from v01 are retained.)
Appendix E. Authors' Addresses
Blake Morrison Alter Meridian Pty Ltd Cronulla, NSW 2230 Australia
Email: blake@truealter.com URI: https://truealter.com
Morrison Expires 10 October 2026 [Page 23]