Robocikowo>ROBOCIKOWO

DNSid

2026EksperymentalnyOpublikowano: 30 kwietnia 2026Aktualizacja: 16 lipca 2026Opublikowany
Protokol IETF wiazacy agenta AI z odpowiedzialna organizacja poprzez DNS. Kazdy agent otrzymuje FQDN, a jego klucze, log cyklu zycia i status sa opublikowane jako strukturowany rekord DNS TXT `_dnsid.<agent-fqdn>` podpisany przez accountable entity. Zaproponowany przez Identity Digital, kwiecien 2026 (draft-ihsanullah-dnsid-00).
Kluczowa innowacja
Wykorzystanie globalnie delegowanej przestrzeni nazw DNS jako trwalej kotwicy tozsamosci agentow AI, wiazac kazdy agent z accountable entity przez FQDN i strukturowany rekord TXT (`_dnsid.<agent-fqdn>`) — z podpisem accountable entity nadrzednym wobec DNSSEC.
Kategoria
Poziom abstrakcji
Wzorzec
Poziom operacji
Środowisko agentoweSystemAplikacjaWdrożenie
Zastosowania
Enterprise deployments agentow AI — powiazanie kazdego agenta z odpowiedzialna organizacja dla celow audytu, compliance i post-incident forensicsCross-organizational agent-to-agent transactions — weryfikacja tozsamosci obcego agenta przed podpisaniem umowy lub transakcjiProvenance dziel wygenerowanych przez agentow (kod, raporty, decyzje) — content signing z zapisem w ledgerze, weryfikowalny po latachRevocation propagation — kiedy agent zostanie skompromitowany, updating status endpoint i wpisu REVOCATION w ledgerze automatycznie unieway wnia go dla wszystkich verifierowDelegation chains — sledzenie ktora agent nadal komu autorytet, na jaki zakres i do kiedyAI Bill of Materials — laczenie agentow, ich modeli, danych treningowych i providerow do audytu governance

Jak działa

1) Accountable entity rejestruje FQDN agenta (np. `billing-agent-acme.example`). 2) Publikuje rekord TXT pod `_dnsid.<fqdn>` z tagami: v=DNSid1, oi (governance identifier), ku (URI JWKS), lr (referencja ledgera), su (URI statusu), sg (podpis rekordu). 3) Agent posiada JWKS endpoint pod `.well-known/jwks.json` z aktualnymi kluczami. 4) Immutable ledger (blockchain, CT-log, SCITT) zapisuje wszystkie zdarzenia cyklu zycia (ISSUANCE, KEY_ROTATION, REVOCATION, RETIREMENT, MIGRATION, optional DELEGATION i CONTENT_SIG), sygnowane kluczem accountable entity. 5) Verifier: rezolwuje `_dnsid.<fqdn>`, pobiera JWKS, weryfikuje podpis rekordu, sprawdza status endpoint, ustanawia HTTPS/mTLS z FQDN agenta. Dla operacji wysokiego zaufania: dodatkowo pyta ledger o zdarzenie ISSUANCE oraz brak REVOCATION.

Rozwiązany problem

Zaden istniejacy standard identyfikacji (OAuth 2.1, OIDC, SPIFFE/SPIRE, SCIM, NGAC, MCP) nie odpowiada na pytanie: kto jest odpowiedzialny za tego agenta AI i czy dowolny system moze zweryfikowac to niezaleznie. Autonomicznie dzialajace agenty AI negocjuja, transaktuja, deleguja i tworza artefakty pozostajace po zakonczeniu ich runtime. Wymaga to trwalej, governance-backed kotwicy wlasnosci — czego istniejacy stack IAM nie zapewnia.

Komponenty

DNSid TXT RecordStrukturowany rekord DNS TXT pod `_dnsid.<agent-fqdn>` z tagami tozsamosci (v, oi, ku, lr, su, sg + opcjonalne fl/ka/cu). Wpis wskaznikowy do endpointow HTTPS i ledgera.
Agent FQDNGlobalnie unikalny Fully Qualified Domain Name agenta (np. billing-agent-acme.example) — primary identifier niesiony w wiadomosciach protokolow, max 246 oktetow.
JWKS Key EndpointSerwis HTTPS w formacie RFC 7517 zwracajacy aktywne klucze podpisujace agenta z metadanymi `kid` i `alg`. Konwencja: `https://<fqdn>/.well-known/jwks.json`.
Status EndpointSerwis HTTPS zwracajacy aktualne state agenta (PENDING/PROVISIONING/VERIFYING/ACTIVE/RETIRED/REVOKED), timestamp ostatniej zmiany i reason code dla REVOKED.
Immutable LedgerAppend-only verifiable log zdarzen cyklu zycia (ISSUANCE, KEY_ROTATION, REVOCATION, RETIREMENT, MIGRATION + optional DELEGATION, CONTENT_SIG). Ledger-neutral: blockchain, Merkle tree, CT log, SCITT.
Entity Signature (sg tag)Podpis base64url calego rekordu TXT (poza samym tagiem sg) kluczem accountable entity. Algorytmy: ES256 (MUST), Ed25519 (SHOULD), ML-DSA (post-quantum, SHOULD).

Implementacja

Implementacje referencyjne
Identity Digital DNSid
dnsid-ai-ecosystem (GitHub)
DNSid Ecosystem Landscape v2
Pułapki implementacyjne
Krytyczna
Rozwiązanie:Zawsze wymagaj i weryfikuj tag `sg` — accountable-entity-controlled signature jest architekturalnym wymaganiem DNSid, nie opcja.
Wysoka
Rozwiązanie:TTL rekordu DNSid TXT powinien byc krotki (300–3600 s). Verifier MUST rowniez pytac status endpoint dla operacji interactive.
Średnia
Rozwiązanie:Deploy zarzadzany przez pojedynczy tool DNS management; monitor duplikatow.
Wysoka
Rozwiązanie:Preferuj publicznie zapytywalne ledgery (blockchain, CT log). Dla prywatnych — wymagaj SLA durability i procedur exportu.
Średnia
Rozwiązanie:Uzywaj DNSid jako fundamentu dla OAuth/OIDC/SPIFFE — do runtime authentication, nie zamiast nich.

Hiperparametry (konfigurowalne osie)

Ledger technologyKrytyczna

Wybor implementacji ledgera: blockchain (Algorand, Ethereum), Merkle-tree CT-style log, SCITT transparency service, prywatny append-only log. DNSid jest ledger-neutral.

Signing algorithmWysoka

ES256 (MUST, ECDSA P-256), Ed25519 (SHOULD), ML-DSA (post-quantum, SHOULD po zarejestrowaniu z JWS). Wyrazane w polu `alg` JWK.

Key age limit (ka tag)Średnia

24h / 7d / 30d / 90d / unbounded. Kompromis miedzy security (czestszy rotation) a operational overhead.

Policy flags (fl tag)Średnia

mtls (wymus mutual TLS), logchk (wymus ledger inclusion check przed operacja high-value). Rozszerzalny slownik.

Domain deployment modeWysoka

Dedicated registrable domain per agent (max pseudonimowosc + governance separation) vs shared organizational subdomain (operational simplicity + shared accountability scope).

DNSSEC deploymentWysoka

Bez DNSSEC (verifier polega tylko na sg — obnizone assurance) vs z DNSSEC (strongest — DNS transport integrity + entity signature).

Paradygmat wykonania

Tryb główny
Warunkowy

Verifikacja jest warunkowa — flags (`fl=logchk,mtls`) i `ka=<age>` decyduja o skali sprawdzen (samego rekordu, JWKS, statusu, ledgera). Wiele ciezkich krokow (ledger lookup) uruchamia sie tylko dla operacji wysokiego zaufania.

Wzorzec aktywacji
Zależne od wejścia

Równoległość

Poziom równoległości
W pełni równoległy

Weryfikacja DNSid jest w pelni rownoleglosowalna — kazdy verifier moze niezaleznie resolvowac DNS, pobierac JWKS, weryfikowac podpisy i pytac ledger, bez wspoldzielonego stanu.

Zakres
InferencjaPomiędzy urządzeniami

Wymagania sprzętowe

Podstawowe