DNS-AID: Wie KI-Agenten über DNS auffindbar werden sollen

Wer heute einen Webserver sucht, tippt eine Adresse in den Browser.. Wer sich dafür interessiert, findet im KI- und Produktivitäts-Zubehör passende Optionen. Den Rest erledigt das Domain Name System: Es übersetzt Namen in technische Endpunkte, verteilt Informationen dezentral und funktioniert seit Jahrzehnten mit erstaunlicher Robustheit. Genau diese Idee soll nun auf KI-Agenten übertragen werden. Mit DNS-AID hat die Linux Foundation ein Open-Source-Projekt angekündigt, das KI-Agenten und agentenbasierte Dienste über DNS veröffentlichen, auffinden und verifizieren will.

Das klingt zunächst nach einem sehr technischen Infrastrukturthema.. Wer sich dafür interessiert, findet im YubiKey und FIDO2-Security-Keys passende Optionen. Tatsächlich berührt DNS-AID aber eine zentrale Frage der nächsten KI-Welle: Wie finden autonome Systeme einander, ohne dass jeder Anbieter ein eigenes Verzeichnis, eine eigene API-Liste oder fest verdrahtete Endpunkte pflegt? Wenn Agenten künftig Termine buchen, Supportfälle bearbeiten, Rechnungen prüfen oder andere Agenten aufrufen sollen, brauchen sie eine Art Telefonbuch. DNS-AID schlägt vor, dafür nicht noch eine Plattform zu bauen, sondern die vorhandene Namensinfrastruktur des Internets zu nutzen.

Die Idee ist charmant, aber nicht automatisch ein Durchbruch.. Wer sich dafür interessiert, findet im OWASP- und Secure-Coding-Bücher passende Optionen. DNS ist stabil, weit verbreitet und dezentral. Es ist aber auch alt, langsam in der Standardisierung und nicht für jede Form dynamischer Metadaten bequem. Genau deshalb lohnt ein genauer Blick: Was verspricht DNS-AID, wie funktioniert es technisch, und was bedeutet das für Unternehmen, Entwickler und Betreiber eigener KI-Systeme?

Was DNS-AID eigentlich lösen will

Die Linux Foundation beschreibt DNS-AID als Projekt für sichere, dezentrale Auffindbarkeit und Kommunikation zwischen KI-Agenten.. Wer sich dafür interessiert, findet im Mini-PCs für Homelab und Security-Lab passende Optionen. Entwickelt wurde es ursprünglich bei Infoblox, nun läuft es unter dem Dach der Linux Foundation. Zu den frühen Unterstützern zählen laut Ankündigung unter anderem Cloudflare, CSC, Equinix, GoDaddy, IDC, Indeed, Infoblox, Internet Systems Consortium und WWT.

Das Problem dahinter ist leicht zu verstehen: Ein KI-Agent ist nur dann nützlich, wenn er relevante Dienste finden und deren Identität ausreichend prüfen kann. Bei klassischen Webdiensten ist das vergleichsweise klar. Es gibt Domains, TLS-Zertifikate, dokumentierte APIs und Suchmaschinen. Bei Agenten ist die Lage unübersichtlicher. Ein Agent kann ein Chatbot sein, ein MCP-Server, ein internes Automationssystem oder ein spezialisierter Dienst für Buchungen, Support, Analyse oder Code-Reviews.

Ohne gemeinsamen Discovery-Mechanismus entstehen drei schlechte Alternativen. Erstens: zentrale Registries, die schnell zu Plattform-Gatekeepern werden. Zweitens: hart codierte Endpunkte in Konfigurationen, die schwer aktuell zu halten sind. Drittens: proprietäre Verzeichnisse einzelner Anbieter, die Interoperabilität nur innerhalb ihres Ökosystems bieten. DNS-AID will diese Sackgassen vermeiden und stattdessen eine offene, vendor-neutrale Schicht schaffen.

Der Name steht für DNS for AI Discovery. Gemeint ist nicht, dass DNS plötzlich KI versteht. Gemeint ist: Agenteninformationen werden dort veröffentlicht, wo auch heute schon viele Informationen über Dienste einer Domain liegen – in DNS-Zonen und begleitenden Metadaten.

Veröffentlichung wie bei Webseiten, aber für Agenten

Im Kern registriert ein Betreiber seine Agenten unter strukturierten DNS-Namen. Heise nennt als Schema beispielsweise _<agentname>._<protokoll>._agents.<domain>, etwa _chatbot._mcp._agents.example.com für einen MCP-basierten Chatbot. Andere Systeme können diese Einträge abfragen und daraus ableiten, welche Agenten eine Domain anbietet, welches Protokoll sie sprechen und wo der eigentliche Dienst erreichbar ist.

DNS-AID führt dafür nach bisherigen Beschreibungen keinen komplett neuen DNS-Record-Typ ein. Stattdessen stützt es sich auf bestehende Mechanismen wie SVCB-Records, TXT-Records, DNSSEC und optional DANE/TLSA. Das ist wichtig, weil neue DNS-Typen in der Praxis oft langsam ausgerollt werden. Bestehende Record-Typen haben bessere Chancen, von Registraren, DNS-Providern und Resolvern unterstützt zu werden.

SVCB steht für Service Binding und ist in RFC 9460 standardisiert. Der Record-Typ wurde ursprünglich dafür entworfen, zusätzliche Verbindungsinformationen zu Netzwerkdiensten zu veröffentlichen. DNS-AID nutzt diese Idee, um Agenten-Endpunkte, Protokollhinweise und Verweise auf weitere Metadaten bereitzustellen. Fähigkeiten eines Agenten können je nach Implementierung direkt über DNS oder über verlinkte Capability-Dokumente beschrieben werden.

Die Referenzimplementierung im GitHub-Projekt dns-aid-core zeigt, wie das aussehen kann. Dort finden sich CLI-Beispiele zum Veröffentlichen eines Agenten mit Namen, Domain, Protokoll, Endpunkt und Fähigkeiten wie chat oder code-review. Neuere Beispiele ergänzen Transport- und Authentifizierungsinformationen, etwa streamable-http oder bearer. Das macht klar: DNS-AID ist nicht nur eine Namensliste, sondern soll genügend Kontext liefern, damit ein anderer Agent eine Verbindung sinnvoll vorbereiten kann.

ki tools praxis – Illustration 2

Drei Wege zur Auffindung

Heise beschreibt drei Suchwege: nach Namen, nach Fähigkeiten oder über einen Katalog aller Agenten einer Domain. Die Namenssuche ist die einfachste Variante. Ein System weiß, dass es den Agenten billing einer bestimmten Organisation braucht, und fragt den passenden DNS-Namen ab.

Spannender ist die Suche nach Fähigkeiten. Ein Agent könnte etwa innerhalb einer Organisation nach einem Dienst suchen, der Rechnungsprüfung, Terminplanung oder Support kann. DNS allein ist für komplexe semantische Suche allerdings nur begrenzt geeignet. Deshalb arbeitet DNS-AID mit zusätzlichen Metadaten und Indexmechanismen. Die Referenzimplementierung beschreibt unter anderem einen Index-Eintrag wie _index._agents.example.com, der eine Liste veröffentlichter Agenten einer Domain enthalten kann.

Der dritte Weg ist der Domain-Katalog. Ein Client fragt ab, welche Agenten eine Organisation überhaupt veröffentlicht hat. Das ist für Crawling, Inventarisierung und Governance interessant. Unternehmen könnten so intern sichtbar machen, welche Agenten offiziell betrieben werden. Externe Partner könnten prüfen, ob ein bestimmter Dienst wirklich zur Domain gehört oder nur so tut.

Diese drei Suchwege sind praktisch, lösen aber nicht alle Probleme. DNS-AID beantwortet vor allem: „Welche Agenten behauptet diese Domain zu betreiben, und wo finde ich sie?“ Es beantwortet nicht automatisch: „Ist dieser Agent qualitativ gut, rechtlich zulässig, sicher implementiert oder für meine konkrete Aufgabe geeignet?“ Dafür braucht es weiterhin Policies, Authentifizierung, Protokollverträge und Monitoring.

Warum DNS als Basis sinnvoll ist

DNS hat für diesen Zweck mehrere Stärken. Es ist global verteilt, hochverfügbar, hierarchisch organisiert und an Domain-Eigentum gekoppelt. Wer eine Domain kontrolliert, kann in der Regel auch deren DNS-Zone verwalten. Das passt gut zur Frage, welche Organisation einen Agenten betreibt.

Außerdem ist DNS nicht an einen einzelnen Anbieter gebunden. Ein offenes Agentenverzeichnis bei einem Cloudanbieter hätte immer das Risiko, zum Engpass zu werden. DNS dagegen ist bereits die gemeinsame Infrastruktur, auf der Websites, Mailserver und viele Service-Discovery-Mechanismen aufbauen. Für ein offenes Agenten-Ökosystem ist das ein starkes Argument.

Ein weiterer Vorteil: Viele Sicherheitsmechanismen existieren bereits. DNSSEC kann DNS-Antworten kryptografisch absichern, sodass Clients prüfen können, ob Einträge unterwegs manipuliert wurden. DANE/TLSA kann TLS-Zertifikate mit DNS-Einträgen verknüpfen. Das ersetzt keine vollständige Anwendungssicherheit, gibt Agenten aber eine robuste Grundlage für Identitätsprüfung.

Gerade im Unternehmensumfeld ist diese Kopplung an Domains attraktiv. Ein interner Agent, der angeblich zu example.com gehört, sollte nicht nur eine URL besitzen, sondern über die DNS-Zone der Organisation auffindbar sein. Das schafft eine klarere Verantwortlichkeit als lose Links in Konfigurationsdateien.

Was DNS-AID nicht ist

Wichtig ist die Abgrenzung: DNS-AID ist kein Agenten-Marktplatz, kein Bewertungssystem und kein Ersatz für Autorisierung. Es sagt nicht, ob ein Agent vertrauenswürdig handelt. Es liefert eine Infrastruktur, mit der Agenten veröffentlicht, entdeckt und technisch verifiziert werden können.

Das ist ein Unterschied, der in der KI-Debatte leicht untergeht. Discovery ist nur die erste Stufe. Danach folgen Authentifizierung, Berechtigungen, Protokollkompatibilität, Datenschutz, Logging, Kostenkontrolle und Missbrauchsschutz. Ein Agent, der gefunden wurde, darf noch lange nicht alles tun.

Auch die Sicherheit hängt stark von der konkreten Umsetzung ab. DNSSEC ist nicht überall konsequent aktiviert. DANE wird in vielen Umgebungen noch zurückhaltend eingesetzt. TXT-Records sind flexibel, aber nicht besonders elegant. Capability-Dokumente können veralten. Und wer Domain- oder DNS-Zugang kompromittiert, kann potentiell auch Agenteninformationen manipulieren.

DNS-AID reduziert also bestimmte Risiken, schafft aber keine magische Vertrauensschicht. Es macht vor allem sichtbar, wer was veröffentlicht. Die eigentliche Zugriffskontrolle bleibt Aufgabe der Agentenplattformen.

Bedeutung für MCP und agentische Systeme

Besonders interessant ist DNS-AID im Zusammenhang mit dem Model Context Protocol, kurz MCP. MCP hat sich als ein wichtiger Ansatz etabliert, um KI-Systeme mit Werkzeugen, Datenquellen und Diensten zu verbinden. Heute müssen MCP-Server häufig manuell konfiguriert werden. Ein offener Discovery-Mechanismus könnte diesen Schritt vereinfachen.

Das GitHub-Projekt zu DNS-AID enthält selbst einen MCP-Server. Dieser soll es Agenten erlauben, andere Agenten über DNS zu veröffentlichen, zu entdecken, deren Tools aufzulisten oder DNS-AID-Records zu verifizieren. Das ist noch kein Beweis für breite Adoption, zeigt aber die Richtung: Discovery soll nicht nur von Menschen, sondern von Agenten selbst genutzt werden.

Für Entwickler könnte das langfristig bedeuten: Ein Agent fragt nicht mehr in einer proprietären Plugin-Liste nach einem Dienst, sondern ermittelt über die Domain, welche MCP-Server oder Agenten offiziell angeboten werden. Für Unternehmen könnte es bedeuten: Offizielle Agenten werden über die eigene Domain publiziert, interne Richtlinien werden in Metadaten verlinkt, und Partner können maschinell prüfen, ob ein Endpunkt dazugehört.

Kurzfristig bleibt das aber Zukunftsmusik. DNS-AID ist frisch angekündigt, die technische Spezifikation läuft laut Berichten parallel als IETF-Internet-Draft, und die Implementierungen müssen erst reifen. Wer heute produktive Agenten betreibt, sollte DNS-AID beobachten, aber nicht erwarten, dass damit sofort alle Integrationsprobleme verschwinden.

ki tools praxis – Illustration 3

Chancen für Unternehmen

Für Unternehmen liegt die größte Chance in Standardisierung und Governance. Wenn Agenten nur als einzelne URLs, Docker-Container oder SaaS-Integrationen existieren, verliert man schnell den Überblick. DNS-AID könnte ein offizielles Veröffentlichungsmodell schaffen: Alles, was über die Unternehmensdomain publiziert ist, gilt als registrierter Agent. Alles andere ist nicht offiziell.

Das passt zu bestehenden Betriebsmodellen. DNS-Zonen werden ohnehin kontrolliert, Änderungen können über Freigabeprozesse laufen, und Security-Teams kennen die Infrastruktur. Ein Agentenverzeichnis auf DNS-Basis lässt sich daher leichter in bestehende Abläufe integrieren als ein neues, isoliertes Portal.

Auch für Partnerintegrationen ist das spannend. Statt Endpunkte per E-Mail auszutauschen, könnte ein Partner maschinell feststellen, welche Agenten eine Organisation anbietet. In Kombination mit signierten Einträgen, TLS-Prüfung und klaren Authentifizierungsmechanismen wäre das ein Schritt zu verlässlicher Agent-zu-Agent-Kommunikation.

Ein weiterer Vorteil ist Portabilität. Wenn ein Unternehmen den Cloudanbieter wechselt, kann es DNS-Einträge ändern, ohne dass alle Clients eine neue zentrale Registry kennen müssen. Diese Entkopplung ist ein klassischer DNS-Vorteil.

Grenzen und offene Fragen

Trotzdem gibt es offene Fragen. Die erste betrifft Semantik. Fähigkeiten wie chat, support oder billing sind leicht zu veröffentlichen, aber schwer eindeutig zu interpretieren. Was genau kann ein Support-Agent? Welche Daten darf er sehen? Welche Aktionen darf er ausführen? Ohne gemeinsame Vokabulare und Policies bleibt Discovery oberflächlich.

Die zweite Frage betrifft Aktualität. DNS arbeitet mit Caching und Time-to-Live-Werten. Das ist gut für Skalierung, kann aber bei häufig wechselnden Agenteninformationen stören. Wenn Endpunkte, Fähigkeiten oder Policies dynamisch sind, muss DNS-AID sorgfältig entscheiden, welche Daten direkt in DNS gehören und welche besser in verlinkte Dokumente ausgelagert werden.

Die dritte Frage betrifft Missbrauch. Ein offenes Discovery-System kann auch Angreifern helfen, interessante Agenten zu finden. Das ist bei Webservern nicht anders, aber bei autonomen Agenten kann die Angriffsfläche sensibler sein. Unternehmen müssen also abwägen, welche Agenten öffentlich sichtbar sein sollen und welche nur intern aufgelöst werden dürfen.

Die vierte Frage betrifft Adoption. DNS-AID ist nur dann nützlich, wenn DNS-Provider, Toolhersteller, Agentenframeworks und Unternehmen es tatsächlich unterstützen. Die Liste früher Unterstützer ist prominent, aber Standards gewinnen nicht durch Pressemitteilungen. Sie gewinnen durch robuste Implementierungen, gute Developer Experience und klare Sicherheitsmodelle.

Einordnung: sinnvoller Baustein, kein fertiges Ökosystem

DNS-AID ist deshalb am besten als Infrastrukturbaustein zu verstehen. Es nimmt eine bewährte Idee des Internets – dezentrale Namensauflösung – und überträgt sie auf agentische Systeme. Das ist vernünftig, weil die Alternative häufig noch mehr Plattformabhängigkeit wäre.

Gleichzeitig darf man die Erwartungen nicht überziehen. Ein Telefonbuch macht noch keine sichere Zusammenarbeit. Es hilft, jemanden zu finden und seine Zugehörigkeit besser zu prüfen. Ob man ihm vertraut, welche Rechte er bekommt und ob die Kommunikation zuverlässig ist, bleibt eine eigene Schicht.

Für Entwickler von KI-Tools ist DNS-AID ein Signal: Die Branche bewegt sich von Einzelintegrationen hin zu offenen Discovery-Standards. Für Unternehmen ist es ein Hinweis, Agenten nicht nur als Chatfenster, sondern als Infrastrukturkomponenten zu betrachten. Wer Agenten produktiv betreibt, braucht Namensräume, Identitäten, Richtlinien und Inventarisierung.

Für Nutzerinnen und Nutzer wird DNS-AID vermutlich unsichtbar bleiben, falls es sich durchsetzt. So wie kaum jemand DNS bewusst wahrnimmt, obwohl es jede Website-Nutzung ermöglicht. Genau das wäre im Erfolgsfall die Pointe: Agenten finden einander über offene Internetstandards, ohne dass Menschen ständig Endpunkte kopieren müssen.

Fazit

DNS-AID ist kein spektakuläres KI-Modell und keine neue Chatbot-Oberfläche. Es ist Infrastruktur. Aber gerade deshalb könnte es wichtig werden. Wenn KI-Agenten tatsächlich stärker miteinander kommunizieren sollen, brauchen sie eine offene Methode, um Dienste zu finden und deren Herkunft zu prüfen. DNS ist dafür nicht perfekt, aber naheliegend: dezentral, bewährt und an Domainkontrolle gekoppelt.

Der praktische Nutzen hängt nun von der Umsetzung ab. Die Referenzimplementierung, die IETF-Arbeit und die Unterstützung durch große Infrastrukturakteure sind gute Startpunkte. Entscheidend wird sein, ob DNS-AID in Agentenframeworks, MCP-Tools, DNS-Provider-Oberflächen und Enterprise-Sicherheitsprozesse einzieht.

Bis dahin bleibt die nüchterne Einordnung: DNS-AID löst nicht das Vertrauensproblem der KI-Agenten. Es löst einen Teil des Auffindbarkeitsproblems. Und dieser Teil ist wichtig genug, um genau beobachtet zu werden.

Passende Produktrecherchen

Wenn du die praktische Seite vertiefen möchtest, findest du hier passende Suchpfade zum Vergleichen. Keine Kaufpflicht, keine Rangliste, sondern thematisch passende Produktrecherchen:

Hinweis: Als Amazon-Partner verdient kalika.de an qualifizierten Verkäufen. Für dich ändert sich der Preis nicht.