Foundry und private Search: DNS oder Auth?

Das Wichtigste in Kürze

Name or service not known beim Auflisten der Search-MCP-Tools ist ein Fehler bei DNS oder Netzwerkpfad, bis das Gegenteil bewiesen ist.
Gesunde Indexer, eine korrekte MCP-URL und RBAC für die Managed Identity des Projekts können alle in Ordnung aussehen, während die Datenebene des Agents das privatelink-DNS nicht auflösen kann.
Repariere Verknüpfungen der Private DNS Zone, VNet-Injection und den ausgehenden Pfad des Agents, bevor du Keys oder 403-Fehlern hinterherjagst.
Ein öffentliches MCP, das vom Laptop aus funktioniert, beweist nicht, dass die Agent-Laufzeit von Foundry den privaten Search-Hostnamen auflösen kann.
Hybrides Networking plus das Umschreiben des Search-Hostnamens durch den Private Endpoint ist die übliche Falle.
Trenne die Symptome: DNS-Fehler zuerst, 403 Forbidden erst, wenn die Namensauflösung funktioniert.

Ich sehe immer wieder dieselbe falsche Fährte. Azure AI Search liegt hinter einem Private Endpoint und dient als MCP-Tool für eine Wissensbasis. Die Indexer sind grün. Die MCP-URL sieht richtig aus. Die Managed Identity des Microsoft Foundry Projekts hat Search-Rollen. Das Auflisten der Tools bricht trotzdem mit Name or service not known ab. Teams öffnen Entra, rotieren Keys und streiten über RBAC, während die Datenebene des Agents den privatelink-Namen nie aufgelöst hat.

Behandle diesen Fehler als DNS, bis überhaupt ein Paket die Authentifizierung erreicht haben könnte.

Benanntes Modell: DNS vor RBAC

DNS: Kann der Datenpfad des Foundry Agents den Search-Hostnamen auflösen, den der Private Endpoint umgeschrieben hat? Die Private DNS Zone privatelink.search.windows.net muss mit dem VNet verknüpft sein, das der Agent tatsächlich nutzt.
Erreichbarkeit: Kommt dieser Pfad nach der Auflösung beim Private Endpoint an (Managed VNet, BYO VNet-Injection oder ein gepeerter hybrider Pfad)?
RBAC: Erst dann sind die Rollen der Managed Identity des Projekts, Berechtigungen der Knowledge Base und 403 Forbidden die ehrliche nächste Ebene.
Symptom trennen: Name or service not known heißt: vor Entra anhalten. 403 Forbidden heißt: Die Namensauflösung hat funktioniert, als Nächstes kommen Authentifizierung oder Netzwerkrichtlinie.
Vertrag: Ein curl vom Laptop auf einen öffentlichen MCP-Endpunkt ist kein Beweis für Staging einer privaten Agent-Laufzeit.

Abbildung 1. Benanntes Modell: DNS vor RBAC. Belege die Namensauflösung und den privaten Pfad, bevor du Rollen der Managed Identity oder Keys hinterherjagst.

Kontext und Rahmenbedingung

Die Rahmenbedingung ist bewusst hybrid und privat. Search hat einen Private Endpoint. Der öffentliche Hostname wird auf privatelink-DNS umgeschrieben. Das Auflisten der Tools für Microsoft Foundry Agents (MCP für die Wissensbasis) läuft über einen Pfad in der Datenebene, der nicht dein Laptop ist und oft nicht einmal derselbe Resolver, den deine Portal-Sitzung nutzt.

Community-Threads auf Microsoft Q&A beschreiben denselben Wechsel: Öffentliche oder halb offene Setups zeigen eventuell 403 Forbidden. Sobald Search auf Private Endpoints beschränkt ist, wird daraus Name or service not known, selbst wenn die Rollen korrekt aussehen. Das ist das Signal. Die Auflösung ist gescheitert, bevor die Authentifizierung überhaupt eine Rolle gespielt hat.

Die Hinweise zu Private Link in Foundry und die Notizen zur Erreichbarkeit über den Daten-Proxy des Agents zeigen in dieselbe Richtung: Die Laufzeit braucht einen VNet-Pfad, der den privaten Search-Endpunkt auflösen und erreichen kann. Häkchen für vertrauenswürdige Dienste und grüne Lampen im Portal ersetzen diesen Pfad nicht.

Design

1. Den Fehler wörtlich lesen

Name or service not known bedeutet, dass getaddrinfo fehlschlägt. Der Prozess hat nie eine IP bekommen. RBAC spielt noch keine Rolle. Fang nicht mit Rollenzuweisungen an, wenn der Name nicht aufgelöst wurde.

2. Den Vertrag für das private DNS erfassen

Für Private Endpoints von Azure AI Search brauchst du die privatelink-Zone, verknüpft mit jedem VNet, das den Dienstnamen auflösen muss. Dazu gehört das Netzwerk, über das Microsoft Foundry Agents tatsächlich nach außen gehen (Managed Network, injiziertes BYO VNet oder gepeerter Hub). Die vergessene VNet-Verknüpfung bei privatelink.search.windows.net ist ein Klassiker: Von einer Jumpbox in einem anderen VNet sieht das DNS im Portal gut aus, während das Subnetz des Agents noch die öffentliche Auflösung nutzt, die den gesperrten Dienst nicht mehr erreicht.

3. Den Pfad des Agents zeichnen, nicht den des Admins

Admins testen über VPN oder Bastion. Agents listen ihre Tools über die Datenebene von Foundry beziehungsweise den Pfad des Daten-Proxys auf. Diese Resolver unterscheiden sich. Abbildung 2 zeigt den vereinfachten privaten Pfad für Search MCP: Search PE, privatelink-DNS, Agent-Laufzeit von Foundry. Für die Form braucht es keine echten Hostnamen.

Abbildung 2. Privater Pfad für Search MCP. Die Datenebene des Agents muss das privatelink-DNS auflösen und den Private Endpoint von Search erreichen. Ein gesunder Indexer und eine vom Laptop aus bewiesene URL beweisen diesen Pfad nicht.

4. Erst DNS beweisen, dann Erreichbarkeit, dann RBAC

Reihenfolge der Beweise:

Löse von einem Host auf derselben Netzwerkebene wie die Agent-Laufzeit den FQDN von Search auf und prüfe, dass die Adresse des Private Endpoints zurückkommt und kein öffentlicher Rest.
Prüfe die TCP-Erreichbarkeit dieser privaten IP auf dem HTTPS-Port von Search.
Erst dann prüfst du die Rollen der Managed Identity des Projekts auf Search und den Wissensressourcen und testest das Auflisten der MCP-Tools erneut.

Wenn Schritt 1 scheitert, hör auf. Repariere Zonenverknüpfungen, VNet-Injection, Peering oder die Weiterleitung im eigenen DNS. Rotiere keine API-Keys.

5. DNS-Symptome von 403-Symptomen trennen

Abbildung 3 zeigt die Trennung der Symptome. Nutze sie im Incident-Chat, damit niemand die falsche Ebene "repariert".

Abbildung 3. Trennung der Symptome. Bei Name or service not known bleibst du bei DNS und Pfad. 403 Forbidden heißt, dass die Auflösung funktioniert hat. Jetzt prüfst du Identität, Rollen und Allowlists.

6. Den Erfolg vom Laptop aus nicht in die MVP-Checkliste aufnehmen

Ein öffentliches MCP von einem Entwicklerrechner beweist die Wissensbasis und die Form der URL. Es beweist keine privaten DNS-Verknüpfungen, keine VNet-Injection des Agents und keine hybriden Resolver-Ketten. Kennzeichne diesen Test im Runbook als reinen POC-Test.

Häufige Fehler

DNS als 403 missverstehen. Teams kopieren Doku zu Rollen in den Thread, während getaddrinfo weiter fehlschlägt.

Keys reparieren, während der Private Endpoint bleibt. Neue Keys helfen nie bei einem Namen, der sich nicht auflösen lässt.

Öffentliches MCP funktioniert vom Laptop, die Agent-Laufzeit scheitert. Anderer Resolver, andere Netzwerkebene, dieselbe falsche Sicherheit.

Die VNet-Verknüpfung bei privatelink.search.windows.net vergessen. Die Zone existiert, das VNet des Agents ist nicht verknüpft, die Symptome wirken zufällig.

Das Häkchen für vertrauenswürdige Dienste als Ersatz für den PE. Nützlich in manchen Mustern mit eingeschränktem öffentlichem Zugriff, aber kein Ersatz für privates DNS, wenn Search nur über Private Endpoints erreichbar ist.

Nach dem Umschreiben durch den PE Tippfehlern in der MCP-URL nachjagen. Saubere URLs zählen, aber nach einer Umstellung auf PE ist der häufigste Fehler Auflösung und Pfad, nicht ein fehlender Schrägstrich.

So übernehmen oder anpassen

So übernehmen

Eine ausdrückliche Reihenfolge: DNS, Erreichbarkeit, dann RBAC für privates Search MCP hinter Foundry Agents.
Ein Inventar der Private DNS Zones mit VNet-Verknüpfungen für jedes Netzwerk, über das Agents nach außen gehen.
Eine Zeile im Runbook, die öffentliches MCP vom Laptop als Beweis für Staging eines privaten MVP ablehnt.
Eine Sprache für Symptome, die Name or service not known aus der Entra-Spur heraushält.
Abgleich mit der Übersicht zu Private Link und Networking in Foundry, bevor eigene Proxy-Legenden entstehen.

Vor dem Einsatz anpassen

Privates Search plus Foundry Agents verlangt Verantwortung für das Networking: DNS, Peering und manchmal Vorlagen für Managed Networks. Wer diese Verantwortung auslässt, hat schnelle Demos und leere Tool-Listen bei den Agents. Search "nur für Foundry" öffentlich zu öffnen macht die Entscheidung für den PE rückgängig. Repariere lieber den privaten Pfad (Vorlagen für BYO VNet, Managed VNet oder dokumentiertes hybrides DNS), statt die Angriffsfläche wieder zu vergrößern.

Foundry + private Suche: Ist "Name or service not known" ein DNS- oder Auth-Problem?