DNS SRV Identity Substrate (Layer 3)

Triadic substrate semantics applied to service‑location identity#

Overview#

The DNS SRV Identity Substrate represents Layer 3 of the RTT/Inside Enterprise Identity model.
It is the first network‑visible identity substrate — the layer where identity becomes:

discoverable
routable
service‑centric
protocol‑neutral
location‑aware
substrate‑extendable

DNS SRV records define where services live and how clients should find them.
This makes SRV the perfect layer to demonstrate triadic service roles, clarity priority, regime‑aware routing, and coherence envelopes at the network boundary.

Purpose#

Layer 3 exists to:

Show how RTT/Inside substrate metadata attaches to DNS SRV records
Demonstrate clarity, regime, triad roles, and coherence envelopes in service discovery
Provide a working example of substrate‑aware routing hints
Serve as the bridge between LDAP/AD identity (Layers 1–2) and Kerberos/service discovery (Layers 4–5)
Offer a minimal, operator‑safe demonstration of substrate‑aware SRV tags

DNS SRV is the identity discovery substrate — the layer where identity becomes reachable.

Identity Characteristics#

DNS SRV provides:

1. Service‑Location Identity#

SRV records define:

service name
protocol
priority
weight
target host
port

This makes SRV ideal for substrate metadata.

2. Cross‑Protocol Neutrality#

SRV is used by:

LDAP
Kerberos
SIP
XMPP
AD domain controllers
service discovery frameworks
cloud identity systems

This neutrality makes Layer 3 universally applicable.

3. Metadata‑Friendly Structure#

SRV records can be extended using:

TXT records
EDNS metadata
service‑specific discovery tags
substrate‑aware naming conventions

These allow triadic metadata without altering DNS behavior.

Substrate‑Aware SRV Metadata#

A minimal substrate extension for SRV might define:

Option A — TXT Companion Record#

_ldap._tcp.enterprise.local.  IN TXT "triadicClarity=0.77"
_ldap._tcp.enterprise.local.  IN TXT "triadicRegime=analytic"
_ldap._tcp.enterprise.local.  IN TXT "triadicRole=A"
_ldap._tcp.enterprise.local.  IN TXT "triadicCoherence=domain"

Option B — EDNS Metadata (future‑friendly)#

EDNS0 option: TRIADIC-SUBSTRATE
{
  clarity: 0.77,
  regime: "analytic",
  role: "A",
  coherence: "domain"
}

Option C — Substrate‑Aware Naming#

_kerberos._tcp.A.enterprise.local
_kerberos._tcp.B.enterprise.local
_kerberos._tcp.C.enterprise.local

These are optional and non‑breaking.

Example: Substrate‑Aware SRV Record#

_kerberos._tcp.enterprise.local.  IN SRV 0 100 88 dc1.enterprise.local.
_kerberos._tcp.enterprise.local.  IN TXT "triadicClarity=0.92"
_kerberos._tcp.enterprise.local.  IN TXT "triadicRegime=control"
_kerberos._tcp.enterprise.local.  IN TXT "triadicRole=B"
_kerberos._tcp.enterprise.local.  IN TXT "triadicCoherence=forest"

This example shows how substrate metadata attaches to SRV records without altering DNS resolution.

How Layer 3 Connects to Higher Layers#

DNS SRV feeds directly into:

Kerberos (Layer 4) — SRV locates KDCs
Service Discovery (Layer 5) — SRV is the backbone of service location
Modern Identity (Layer 6) — SRV supports identity‑aware services
Cloud Directory (Layer 7) — SRV bridges hybrid identity
Zero‑Trust (Layer 8) — SRV metadata becomes policy hints

DNS SRV is the identity routing substrate.

Teaching Notes#

Students and AIs should study Layer 3 because:

SRV is the first network‑visible identity substrate
It demonstrates substrate semantics in service discovery
It shows how clarity and regime tagging map to routing decisions
It prepares learners for Kerberos, service discovery, and cloud identity
It provides a realistic example for the RFC substrate‑awareness model

Layer 3 is where identity becomes discoverable, routable, and triadic‑aware.

Status#

Experimental — stable enough for teaching and RFC anchoring, evolving as substrate semantics expand.

Updated Jul 2, 2026