Ein Beitrag von Mario Gersbach, Application Security Engineer bei Sidarion
KI-Agenten sind kleine Programme, die eigenständig Aufgaben übernehmen, beispielsweise eine Wetterprognose abrufen, einen Kalender verwalten oder eine Kundenanfrage bearbeiten. Wer so einen Agenten ansprechen will, muss heute aber meistens schon vorher wissen, wo er steckt: Adresse, Protokoll, Anmeldeverfahren. Das ist ungefähr so, als müsste man vor jeder E-Mail persönlich nachfragen, welchen Mailserver das Gegenüber benutzt. Umständlich, und schlecht skalierbar.
Genau diesen Umweg will DNS-AID loswerden – die Abkürzung steht für «DNS for AI Discovery». Der Vorschlag kommt von Infoblox und liegt inzwischen als offener Standard bei der Linux Foundation. Das DNS soll Agenten auffindbar machen, so wie es Webserver und Postfächer auffindbar macht.
Der Vergleich mit dem Mailversand trifft es recht gut: Kein Mailprogramm weiss von sich aus, auf welcher Maschine das Postfach der Gegenseite liegt. Es fragt den MX-Record ab und liefert dann dorthin. Für Agenten fehlt dieser Zwischenschritt bislang.
Ein DNS-Lookup, danach ein HTTPS-Aufruf
Das DNS wird bei DNS-AID ausschliesslich zum Auffinden benutzt. Gesprochen wird anschliessend woanders.
Der Client fragt einen Namen wie _agent.example.com ab und bekommt einen SVCB- oder HTTPS-Record zurück. Darin steht der Einstiegspunkt: Hostname und Port, über ALPN zusätzlich die Verbindungsart, etwa HTTP/2. Diese Record-Typen sind in RFC 9460 definiert und stammen aus dem Web-Routing. Neue DNS-Eintragstypen braucht DNS-AID also keine.
Mit dieser Adresse baut der Client eine gewöhnliche HTTPS-Verbindung auf und holt sich die Beschreibung des Agenten, üblicherweise unter /.well-known/agent.json. Hier ein konstruiertes Beispiel, wie das aussehen kann:
{
„name“: „weather-agent“,
„protocols“: [„MCP“, „A2A“],
„authentication“: { „type“: „oauth2“ },
„capabilities“: [„forecast“, „temperature“, „alerts“]
}
Damit weiss der Client, was der Agent kann, wie er sich anmeldet und über welches Protokoll die eigentliche Unterhaltung läuft.
Für die Aufteilung gibt es einen handfesten Grund: DNS-Antworten sollen kurz sein und lange im Cache liegen dürfen. Eine Fähigkeitsliste, die sich mit jedem Deployment verschiebt, gehört dort nicht hinein. Vom Caching profitiert die Konstruktion trotzdem, denn nur der erste Lookup muss bis zum autoritativen Server; alle weiteren Clients bedienen sich unterwegs.
Um die Echtheit kümmert sich DNSSEC. Sind die Antworten signiert, kann sich nicht beliebig jemand als Agent einer fremden Domain ausgeben. Was DNSSEC nicht leistet: eine Aussage darüber, ob der Agent hinter der Adresse vertrauenswürdig ist. Das bleibt Sache der Authentisierung auf HTTPS-Ebene.
Der Haken für die breite Masse
SVCB-Records und DNSSEC sind Pflicht, und daran scheitert es momentan bei den grossen Massenhostern. Im Kundenpanel eines typischen Shared-Hosting-Pakets lassen sich A-, MX- und TXT-Einträge pflegen, SVCB in vielen Fällen nicht. Wer DNS-AID ausprobieren möchte, landet deshalb schnell bei Anbietern wie Cloudflare oder verwaltet die Zone gleich selbst in der Cloud.
Dass Infoblox hinter dem Vorschlag steht, passt zu diesem Bild. Infoblox verkauft DNS-, DHCP- und IPAM-Systeme an Grossunternehmen, also an Organisationen, die ihre Zonen ohnehin selbst betreiben und einen SVCB-Record ohne Rückfrage beim Hoster anlegen können. Der Standard ist offen und die Governance liegt bei der Linux Foundation, die erste Zielgruppe sitzt aber erkennbar im Rechenzentrum und nicht im WordPress-Blog.
Öffentlich auflösbare Beispiele findet man bis dato kaum. Wer damit experimentiert, tut es vorerst in der eigenen Zone.
Was noch fehlt
Ob DNS-AID sich durchsetzt, entscheidet sich weniger an der Technik als daran, ob Protokolle wie MCP oder Googles A2A (Agent to Agent) auf Dauer tragen. Autonome Multi-Agenten-Systeme sind bisher mehr Ankündigung als Alltag, und eine Auskunftsschicht braucht es erst, wenn genügend Teilnehmer da sind, die sich gegenseitig suchen müssen.
Für den Vorschlag spricht, wie wenig er verlangt: keinen neuen Eintragstyp, keine zusätzliche Software im Auflösungspfad, lediglich etwas Disziplin beim Pflegen der Zone. Im DNS-Umfeld ist das kein Nachteil.
