Foundry + búsqueda privada: ¿"Name or service not known" es un problema de DNS o de autenticación?

Veo una y otra vez la misma pista falsa. Azure AI Search está detrás de un private endpoint como herramienta MCP de una base de conocimiento. Los indexadores están en verde. La URL del MCP parece correcta. La identidad administrada del proyecto de Microsoft Foundry tiene roles de Search. Aun así, la enumeración de herramientas muere con Name or service not known. Los equipos abren Entra, rotan claves y discuten sobre RBAC mientras el plano de datos del agente nunca llegó a resolver el nombre de privatelink.

Trata ese error como DNS hasta que un paquete haya podido llegar a la autenticación.

Figura 1. Modelo con nombre: DNS antes que RBAC. Demuestra la resolución de nombres y la ruta privada antes de perseguir roles de la identidad administrada o claves.

Contexto y restricción

La restricción es híbrida y privada por diseño. Search tiene un private endpoint. El nombre de host público se reescribe hacia el DNS de privatelink. La enumeración de herramientas de Microsoft Foundry Agent (MCP de la base de conocimiento) se ejecuta en una ruta del plano de datos que no es tu portátil y que a menudo ni siquiera usa el mismo resolvedor que tu sesión del portal.

Los hilos de la comunidad en Microsoft Q&A describen el mismo cambio: las configuraciones públicas o semiabiertas pueden mostrar 403 Forbidden; al restringir Search a private endpoints, el error pasa a ser Name or service not known aunque los roles parezcan correctos. Esa es la pista. La resolución falló antes de que la autenticación importara.

La guía de private link de Foundry y las notas sobre el alcance del proxy de datos del agente apuntan en la misma dirección: el runtime necesita una ruta de VNet que pueda resolver el endpoint privado de Search y llegar a él. Las casillas de servicios de confianza y las luces verdes del portal no sustituyen a esa ruta.

Diseño

1. Lee el error al pie de la letra

Name or service not known es getaddrinfo fallando. El proceso nunca obtuvo una IP. El RBAC todavía no entra en juego. No empieces por las asignaciones de roles cuando el nombre no se resolvió.

2. Haz inventario del contrato de DNS privado

Para los private endpoints de Azure AI Search necesitas la zona de privatelink vinculada a cada VNet que tenga que resolver el nombre del servicio, incluida la red por la que salen de verdad los agentes de Microsoft Foundry (red administrada, VNet propia inyectada o hub emparejado). Olvidar el vínculo de VNet en privatelink.search.windows.net es un clásico: el DNS del portal se ve bien desde un jump box en otra VNet mientras la subred del agente sigue usando una resolución pública que ya no llega al servicio bloqueado.

3. Dibuja la ruta del agente, no la del administrador

Los administradores prueban desde la VPN o un bastion. Los agentes enumeran herramientas a través del plano de datos de Foundry o de la ruta del proxy de datos. Esos resolvedores son distintos. La figura 2 es la ruta privada simplificada del MCP de Search: el PE de Search, el DNS de privatelink y el runtime de agentes de Foundry. No hacen falta nombres de host reales para enseñar la forma.

Figura 2. Ruta privada del MCP de Search. El plano de datos del agente tiene que resolver el DNS de privatelink y llegar al private endpoint de Search. Un indexador sano y una URL probada desde un portátil no demuestran esa ruta.

4. Demuestra el DNS, después el alcance de red y después el RBAC

Orden de las pruebas:

1. Desde un host en el mismo plano de red que el runtime del agente, resuelve el FQDN de Search y confirma que devuelve la dirección del private endpoint, no un resto público.
2. Confirma que llegas por TCP a esa IP privada en el puerto HTTPS de Search.
3. Solo entonces valida los roles de la identidad administrada del proyecto en Search y en los recursos de conocimiento, y vuelve a probar la enumeración de herramientas MCP.

Si el paso 1 falla, para. Arregla los vínculos de zona, la inyección en la VNet, el emparejamiento o el reenvío del DNS personalizado. No rotes las claves de API.

5. Separa los síntomas de DNS de los síntomas de 403

La figura 3 es la separación de síntomas. Úsala en el chat del incidente para que nadie "arregle" la capa equivocada.

Figura 3. Separación de síntomas. Con Name or service not known te quedas en el DNS y la ruta. 403 Forbidden significa que la resolución funcionó; ahora revisa la identidad, los roles y las listas de permitidos.

6. Deja el éxito desde un portátil fuera de la checklist del MVP

Un MCP público desde la máquina de un desarrollador demuestra la base de conocimiento y la forma de la URL. No demuestra los vínculos del DNS privado, la inyección del agente en la VNet ni las cadenas de resolvedores híbridos. Marca esa prueba en el runbook como solo para el POC.

Errores comunes

Confundir DNS con un 403. Los equipos pegan documentación de roles en el hilo mientras getaddrinfo sigue fallando.

Arreglar las claves mientras el private endpoint sigue ahí. Las claves nuevas nunca ayudan con un nombre que no se resuelve.

El MCP público funciona desde un portátil y el runtime del agente falla. Otro resolvedor, otro plano de red, la misma falsa confianza.

Olvidar el vínculo de VNet en privatelink.search.windows.net. La zona existe, la VNet del agente no está vinculada y los síntomas parecen aleatorios.

La casilla de servicios de confianza como sustituto del PE. Útil en algunos patrones con acceso público restringido, pero no sustituye al DNS privado cuando Search solo es accesible por private endpoint.

Perseguir errores tipográficos en la URL del MCP tras la reescritura del PE. La higiene de las URL importa, pero tras pasar a PE el fallo dominante es la resolución y la ruta, no una barra que falta.

Úsalo tal cual o adáptalo

Úsalo tal cual

• Un orden explícito: DNS, alcance de red y después RBAC para el MCP privado de Search detrás de agentes de Foundry.
• Un inventario de zonas DNS privadas con vínculos de VNet para cada red de salida de los agentes.
• Una fila del runbook que rechace el MCP público desde un portátil como prueba de staging para un MVP privado.
• Un lenguaje de síntomas que mantenga Name or service not known fuera del carril de Entra.
• Alineación con la introducción a private link y redes de Foundry antes de que aparezca folclore de proxies propios.

Adáptalo antes de usarlo

Search privado más agentes de Foundry exige que alguien se responsabilice de la red: DNS, emparejamiento y a veces plantillas de red administrada. Saltarse esa responsabilidad mantiene las demos rápidas y las listas de herramientas de los agentes vacías. Abrir Search al público "solo para Foundry" deshace la decisión del PE. Es mejor arreglar la ruta privada (plantillas de VNet propia, VNet administrada o un DNS híbrido documentado) que volver a ampliar la superficie de ataque.

Relacionado

• Apps de agentes: ¿puedes poner un Fabric Data Agent en una app web pública? (POC público frente a MVP privado en staging)
• Microsoft Foundry: ¿basta con Deploy as Web App o necesitas un proxy de backend? (primero identidad y salida)
• Shells de IA seguras: ¿el navegador habla con Foundry o solo a través de un proxy? (frontera del proxy seguro)

Fuentes (de la comunidad): Unable to connect Foundry to Azure AI Search knowledge base, Foundry Agent Service data proxy cannot reach resources, Configurar private link para Microsoft Foundry.

Demuestra el DNS. Después el alcance de red. Después el RBAC. El agente no te va a agradecer unas asignaciones de roles preciosas sobre un nombre que nunca resolvió.