DNS-AID: Das Telefonbuch für KI-Agenten

Mit der massenhaften Verbreitung autonomer Softwaresysteme im Jahr 2026 stehen Unternehmen vor einer neuen infrastrukturellen Herausforderung: Wie können KI-Agenten von Drittanbietern, Partnern oder Kunden vollautomatisch erkennen, welche Dienste, Schnittstellen und Werkzeuge eine Domain bereitstellt?

Bisherige Ansätze stützen sich primär auf die HTTP-Anwendungsschicht: Webmaster hinterlegen Dateien wie /.well-known/agent-card.json oder Dokumentationen wie /auth.md. Doch dieser Prozess ist für vernetzte Multi-Agenten-Systeme ressourcenintensiv. Bevor ein Agent erfährt, ob eine Domain ein bestimmtes Werkzeug anbietet, muss er DNS-Zonen auflösen, TCP- und TLS-Handshakes durchführen, HTTP-GET-Requests absenden und JSON-Dokumente parsen.

Mit DNS-AID (DNS-based Agent Identification and Discovery) etabliert sich eine zukunftsweisende Spezifikation der Internet Engineering Task Force (IETF), die diesen Prozess radikal beschleunigt und dezentralisiert. Sie verwandelt das bewährte Domain Name System in ein globales, latenzarmes Telefonbuch für die Agent-Economy.

Jörg Zimmer

Senior SEO & AI Search Consultant

„Wer glaubt, AI-Readiness ende bei einer agent-card.json oder robots.txt auf dem Webserver, unterschätzt autonome Systeme fundamental. Echte Agenten verhandeln nicht sekundenlang über HTTP, wenn sie Schnittstellen und kryptografische Identitäten per DNS-AID in 15 Millisekunden direkt auf Infrastruktur-Ebene verifizieren können. DNS ist das Fundament des maschinellen Webs.“

Was ist DNS-AID?

DNS-AID ist ein offener Standard-Entwurf (spezifiziert als draft-mozleywilliams-dnsop-dnsaid), der von Netzwerk- und Cloud-Schwergewichten wie Infoblox, Deutsche Telekom und Amazon im IETF-Arbeitskreis vorangetrieben wird. Ziel ist es, die Entdeckung von Agenten und deren Protokollen (wie dem Model Context Protocol (MCP) oder dem A2A-Protocol) direkt im DNS zu verankern.

Anstatt ein neues, isoliertes Protokoll oder proprietäre Plattform-Register zu erfinden, nutzt DNS-AID die vorhandenen, seit Jahrzehnten bewährten Kerntechnologien des Internets:

1. SVCB-Records (RFC 9460): Service-Binding-Records transportieren Endpunkt-Informationen, Portnummern und unterstützte Transportprotokolle direkt in der DNS-Antwort.
2. TXT-Records: Dienen als strukturierter Metadaten-Container für Parameter, API-Versionen und Fallback-Verweise auf die Web-Ebene.
3. DNS-SD (DNS-Based Service Discovery): Ermöglicht die kaskadierende Auflösung ganzer Dienstkataloge innerhalb einer Unternehmens-Domain.
4. DNSSEC & DANE (TLSA): Schützen die Identität der Agenten gegen Spoofing und Manipulation durch kryptografische Zertifikatsbindungen.

Wie funktioniert DNS-AID in der Praxis?

Wenn ein autonomer Recherche- oder Einkaufs-Agent auf eine Domain stößt, startet er keinen blinden Web-Crawl, sondern sendet eine DNS-Anfrage an den zuständigen Nameserver.

Der Ablauf gliedert sich in vier Phasen:

1. DNS-Discovery-Request: Der Agent fordert den SVCB-Record unter einem standardisierten Prefix an (z. B. _agent._tcp.teleschmie.de).
2. Resource Record Evaluation: Der Nameserver antwortet mit den hinterlegten Parametern. Der Agent liest Zieladresse, Port, Protokolltyp (z. B. alpn=mcp) und Authentifizierungs-Endpunkte aus.
3. Kryptografische Signaturprüfung: Über DNSSEC stellt der Agent sicher, dass die DNS-Antwort nicht manipuliert wurde und vom rechtmäßigen Domaininhaber stammt.
4. Direkte Verbindungsaufnahme: Der Agent verbindet sich ohne Umwege mit dem Ziel-Endpoint, authentifiziert sich gemäß den DNS-Vorgaben und führt den gewünschten Task aus.

Vergleichstabelle: HTTP-Discovery vs. DNS-AID

Die Verlagerung der Dienst-Entdeckung von der HTTP-Schicht in das DNS bringt fundamentale Vorteile hinsichtlich Geschwindigkeit, Skalierbarkeit und Sicherheit:

Universelles Konfigurations-Beispiel: DNS-Zone

Um eine Domain mit DNS-AID auszustatten, werden standardisierte Resource-Records in der DNS-Zonendatei (z. B. bei BIND, Cloudflare oder modernen DNS-Hostern) eingetragen. Die folgenden neutralen Snippets zeigen die saubere Syntax:

; ============================================================
; DNS-AID Konfiguration für eine universelle Domain
; ============================================================

; 1. Service Binding Record (SVCB) für den primären MCP-Agenten
_agent._tcp.teleschmie.de.    3600 IN SVCB 1 mcp.api.teleschmie.de. (
                                alpn="mcp"
                                port="443"
                                key65300="v=dns-aid1"
                              )

; 2. TXT-Record Fallback mit Metadaten und Auth-Verweis
_agent._tcp.teleschmie.de.    3600 IN TXT "v=dns-aid1; id=company-agent; auth=https://teleschmie.de/auth.md; mcp=https://teleschmie.de/.well-known/mcp.json"

; 3. DANE TLSA-Record zur kryptografischen Authentifizierung
_443._tcp.mcp.api.teleschmie.de. 3600 IN TLSA 3 1 1 d2ab65...deine_hash_signatur...

Die 3 häufigsten Fehler bei der Implementierung von DNS-AID

Da DNS-Einträge bei Fehlern weltweite Auswirkungen auf die Namensauflösung haben können, müssen Administratoren folgende Fallstricke meiden:

1. Fehlende oder inkorrekte DNSSEC-Signierung: Wird DNS-AID ohne aktives DNSSEC betrieben, stufen sicherheitsorientierte Agenten-Netzwerke die Einträge als nicht vertrauenswürdig ein und verweigern autonome Handlungen (Zero-Trust-Prinzip).
2. Überlange TXT-Records ohne String-Splitting: DNS-TXT-Records dürfen nach RFC 1035 pro Text-Segment maximal 255 Bytes enthalten. Wer Metadaten-Strings ungeteilt einfügt, riskiert Parsing-Fehler bei strikten Resolvern.
3. Diskrepanz zwischen DNS-Endpunkten und HTTP-Manifesten: Wenn der DNS-Record auf einen Server verweist, dessen MCP Server Card oder auth.md nicht aktuell ist, schlägt der Verbindungsaufbau nach dem DNS-Lookup fehl.

Terminal-Test: DNS-AID Records mit dig validieren

Systemadministratoren können die publizierten Einträge mit Standard-Netzwerk-Tools aus dem Terminal heraus überprüfen:

# Abfrage des SVCB-Records für den Agenten (Domain anpassen)
dig +short SVCB _agent._tcp.teleschmie.de

# Prüfung des TXT-Metadaten-Records inklusive DNSSEC-Validierung
dig +dnssec TXT _agent._tcp.teleschmie.de

Liefert die Abfrage die deklarierten Ports, Protokolle und das ad-Flag (Authenticated Data) für DNSSEC zurück, ist die Domain lückenlos für dezentrale Agent-Discovery gerüstet.

Automatisierte DNS-AID-Bereitstellung in CI/CD-Pipelines

In modernen Cloud- und Enterprise-Infrastrukturen werden DNS-Einträge selten manuell gepflegt. Da sich Microservices, API-Versionen und Agenten-Endpunkte dynamisch ändern, muss auch DNS-AID automatisiert in Deployment-Pipelines integriert werden.

Unternehmen setzen hierbei auf Infrastructure-as-Code (IaC) wie Terraform oder OpenTofu sowie spezialisierte DNS-Management-APIs:

1. Terraform-Integration: Über standardisierte DNS-Provider werden SVCB- und TXT-Records deklarativ als Code definiert. Ändert sich der Endpunkt des MCP-Servers, aktualisiert die CI/CD-Pipeline den DNS-Record zeitgleich mit dem Rollout des neuen Container-Images.
2. API-gestützte Synchronisation (z. B. via Linux Foundation Open Source Tools oder Cloudflare API): Das Open-Source-Ökosystem bietet fertige SDK-Schnittstellen, um beim Start eines neuen Agenten-Services selbstständig einen DNS-AID-Eintrag im internen oder öffentlichen Nameserver zu registrieren.
3. Health-Checks und automatisches Failover: Fortgeschrittene DNS-Load-Balancer überwachen den HTTP-Status des registrierten Agenten. Antwortet ein MCP-Server nicht mehr mit HTTP 200, wird der SVCB-Record automatisch deaktiviert oder auf einen Ausweich-Endpunkt umgeschaltet.

Diese Automatisierung verhindert „tote“ Agenten-Einträge im globalen Namensraum und garantiert anfragenden Systemen maximale Zuverlässigkeit bei geschäftskritischen Transaktionen.

Strategische Einordnung im Zeitalter der Agent Readiness

DNS-AID markiert die Speerspitze der Agent Readiness. Während die Basisanforderungen (Level 1 bis 5) den Schutz und die Bereitstellung von Inhalten auf Web-Ebene regeln, verankert DNS-AID die maschinelle Identität eines Unternehmens unlösbar in seiner Kern-Domain. In Kombination mit standardisierten Schnittstellen nach dem A2A-Protocol stellen Sie sicher, dass Ihre Marke von der nächsten Generation autonomer Systeme nicht nur gefunden, sondern als maßgebliche Entität anerkannt wird.

Welche Analysewerkzeuge Ihnen helfen, Ihre digitale Präsenz im KI-Ökosystem zu messen, erfahren Sie in unserem Vergleich der Top 9 AI Visibility Tools. Zur wirtschaftlichen Planung Ihrer technischen SEO- und API-Architektur steht Ihnen unser SEO-Tool Kostenrechner zur Verfügung.

Verwandte Glossar-Begriffe

• DNS-Sovereignty
• Agent Readiness
• Model Context Protocol (MCP)
• A2A-Protocol
• MCP Server Card
• RFC 8288 Link-Header
• auth.md