mDNSResponder zombie: curl falla pero nslookup sí
Si estás corriendo curl o un script en Python en macOS y te salta “Could not resolve host”, pero nslookup te devuelve la IP sin chistar, el culpable casi seguro es el mDNSResponder zombie. El daemon de resolución DNS de Apple mantiene su PID activo, pero dejó de responder consultas del sistema. La solución —y no es joda— es un simple sudo killall -9 mDNSResponder. No toques API keys ni configuraciones de red que no tienen nada que ver.
mDNSResponder zombie es el estado en el que el daemon mDNSResponder de macOS —el proceso encargado de resolver nombres de dominio para curl, Python, navegadores y prácticamente cualquier app que use getaddrinfo()— puede mantener su PID vivo mientras se niega a responder consultas. El sistema operativo lo da por vivo, así que no lo reinicia solo, y vos perdés horas debugueando código que está perfecto.
En pocos segundos
- nslookup funciona, curl y Python fallan porque macOS tiene dos caminos DNS separados: nslookup consulta servidores DNS directo, mientras que curl pasa por mDNSResponder.
- El diagnóstico toma 10 segundos con
dscacheutil -q host -a name ejemplo.com: si devuelve vacío y nslookup devuelve una IP, confirmás el zombie. - La solución es reiniciar el daemon con
sudo killall -9 mDNSResponder; el sistema lo levanta solo de nuevo en segundos. - No es un problema de red, API keys ni SDKs: rotar claves, cambiar configuraciones o downgradear librerías no soluciona el problema.
- El bug sigue presente en macOS según lo reportado hasta junio de 2026.
¿Qué es el estado zombie de mDNSResponder?
mDNSResponder es el daemon que macOS usa para resolver nombres de dominio desde hace años —Multicast DNS, Bonjour, consultas DNS tradicionales, todo pasa por ahí. El estado zombie describe una situación particularmente difícil de diagnosticar: el proceso sigue corriendo, su PID aparece en ps aux y launchd lo reporta como activo, pero internamente dejó de procesar consultas. No crashea, no loguea errores, no se reinicia. Simplemente se queda ahí, ocupando memoria y haciendo absolutamente nada.
El síntoma principal es que cualquier herramienta que dependa de la syscall getaddrinfo() —curl, Python con requests o socket, navegadores, ping, ssh— falla con variantes de “Could not resolve host”. Pero nslookup, que por diseño bypassea el daemon y consulta los servidores DNS directo, te devuelve la IP como si nada. (¿Quién mierda diseñó esta arquitectura asimétrica? Habría que preguntarle al equipo de ingeniería de Apple allá por 2015, pero bueno, acá estamos.) Lo explicamos a fondo en nuestra comparativa de CI/CD 2026.
¿Cómo diagnosticar si mDNSResponder está en estado zombie?
El diagnóstico es rápido y no requiere herramientas externas. La clave es probar la resolución por los dos caminos y comparar resultados. Si el camino del sistema falla y el directo funciona, tenés un zombie confirmado.
Probá primero la ruta del daemon, que es la que usan curl y Python:
dscacheutil -q host -a name google.comSi el daemon está zombie, este comando devuelve vacío o un error. Ahora probá la ruta directa, que bypassea mDNSResponder:
nslookup google.com¿Ves una IP? Listo. Acabás de confirmar que el daemon está en estado zombie. (Podés hacer una tercera prueba con curl -v https://google.com para verificar que el problema no es de conectividad, pero si ya tenés el diagnóstico positivo, no hace falta.)
¿Por qué nslookup funciona pero curl y Python fallan?
La arquitectura de resolución DNS en macOS tiene dos caminos independientes. Es una decisión de diseño que viene de las épocas de Mac OS X y que nadie tocó en más de una década. La asimetría genera este tipo de dolores de cabeza porque a simple vista todo parece indicar que la red anda bien, tu código está bien, y sin embargo las conexiones fallan. Tema relacionado: la comparativa real entre OrbStack y Multipass.
| Característica | Ruta directa (nslookup) | Ruta del sistema (curl, Python, ping) |
|---|---|---|
| ¿Pasa por mDNSResponder? | No — consulta servidores DNS directo | Sí — depende completamente del daemon |
| Syscall usada | Envía consultas DNS propias | getaddrinfo() |
| Resultado si el daemon está zombie | Resuelve correctamente (IP válida) | Falla: “Could not resolve host” |
| Apps que usan este camino | nslookup, dig, host | curl, Python, Ruby, Node.js, navegadores, ssh |
| ¿Se rompe cuando el daemon muere? | No se entera | Se rompe todo |
El punto es que cuando ves “Could not resolve host” en curl y una IP limpia en nslookup, no estás frente a un problema de red, de API keys ni de código. Estás ante un daemon enfermo.
¿Cómo solucionar el problema sin tocar código ni API keys?
La solución es un comando de una línea, pero requiere sudo y te va a cortar la resolución DNS por un par de segundos mientras el sistema levanta el proceso de nuevo:
sudo killall -9 mDNSResponderEl flag -9 (SIGKILL) es importante porque el daemon en estado zombie a veces no responde a señales normales de terminación. launchd detecta que el proceso murió y lo reinicia automáticamente en menos de cinco segundos. Después de eso, curl, Python y cualquier otra app vuelven a resolver nombres sin problemas.
¿Y qué no tenés que hacer? No rotes API keys. No downgradees SDKs. No edites /etc/hosts ni configuraciones de red. No reinstales Python ni curl. Todo eso es ruido. El problema es un proceso de sistema que se colgó y necesita un golpe de gracia para que launchd lo levante limpio. Para más detalles técnicos, mirá nuestra guía sobre Jenkins y GitHub Actions.
¿Qué otros síntomas acompañan al mDNSResponder zombie?
Además de curl y Python, fallan prácticamente todas las apps que usan getaddrinfo(): navegadores, ping a nombres de dominio, ssh, herramientas de línea de comandos como wget, y cualquier script en Node.js, Ruby o Go que resuelva hosts. Las conexiones a IPs directas funcionan perfecto, así que si tenés un ping a 8.8.8.8 que anda y un ping a google.com que no, el patrón es clarísimo.
Lo más frustrante es que no hay logs visibles. Console.app no muestra nada raro, syslog no registra errores de mDNSResponder, y el sistema reporta que el daemon está corriendo sin problemas. Perdés horas debugueando, probás cambiar DNS, reiniciás la interfaz de red, y nada funciona porque el problema está en una capa que ni se te ocurre mirar.
¿Cómo prevenir que mDNSResponder entre en estado zombie?
No hay una solución permanente documentada, y el bug es conocido en foros de desarrolladores y en Stack Overflow desde hace años, sin una solución definitiva.
Lo que sí podés hacer es mantener macOS actualizado a la última versión estable, evitar matar el daemon manualmente con señales que no sean las recomendadas (algunos scripts de “limpieza” de DNS hacen más daño que bien), y si querés ir un paso más allá, armarte un script de monitoreo que cada hora compare la salida de dscacheutil -q host -a name google.com con nslookup google.com. Si divergen, que te mande una alerta y reinicie el daemon automáticamente. Sobre eso hablamos en el secreto del hreflang para SEO internacional.
Errores comunes
- Rotar API keys o cambiar configuraciones de red: El error “Could not resolve host” en curl engaña porque parece un problema de conectividad o autenticación. Si nslookup funciona, el problema no es la red ni las claves. No toques nada de eso hasta haber diagnosticado el daemon.
- Reinstalar Python o las librerías HTTP: requests, urllib, httpx y cualquier otra librería usan getaddrinfo() por debajo. Reinstalarlas no arregla el daemon del sistema operativo. Es como cambiar las bujías cuando el tanque está vacío.
- Editar /etc/hosts manualmente: Agregar entradas estáticas a hosts te puede sacar del apuro para un par de dominios, pero no arregla el problema de fondo y te genera deuda técnica. El día que necesités resolver un dominio nuevo, vas a estar en la misma.
- Usar killall sin -9 cuando el daemon está zombie: El estado zombie a veces implica que el proceso no responde a SIGTERM. Si usás
sudo killall mDNSRespondersin el flag -9, puede que no pase nada y sigas atascado.
Preguntas Frecuentes
¿Qué es mDNSResponder en macOS?
mDNSResponder es el daemon del sistema operativo macOS que maneja la resolución de nombres de dominio. Administra consultas DNS tradicionales, Multicast DNS (usado por Bonjour para descubrir dispositivos en la red local) y es el backend de la syscall getaddrinfo() que usan la mayoría de las aplicaciones. Si se cuelga, todo lo que dependa de resolución de nombres deja de funcionar.
¿Cómo reiniciar mDNSResponder en macOS?
Con el comando sudo killall -9 mDNSResponder. El flag -9 envía SIGKILL, que fuerza la terminación del proceso incluso si está en estado zombie. launchd lo reinicia automáticamente en segundos. También podés usar sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist seguido de sudo launchctl load -w con la misma ruta, pero killall es más rápido y directo.
¿Por qué nslookup resuelve pero curl no en macOS?
Porque nslookup consulta servidores DNS de forma directa, sin pasar por el daemon mDNSResponder. Curl, en cambio, usa getaddrinfo(), que depende completamente de mDNSResponder. Cuando el daemon entra en estado zombie, la ruta del sistema falla mientras la ruta directa sigue funcionando. Esta asimetría es la que hace que el problema sea tan difícil de diagnosticar a simple vista.
¿El mDNSResponder zombie afecta a todos los Mac?
El bug puede afectar a cualquier Mac con macOS, independientemente del modelo o la versión del sistema operativo. No hay un patrón claro de qué lo dispara: algunos reportes lo asocian con cambios de red (cambiar de Wi-Fi a Ethernet, despertar la máquina del sleep), otros con alta carga de consultas DNS, y en muchos casos simplemente aparece sin motivo aparente. El problema sigue sin una solución definitiva.
¿Puedo diagnosticar el mDNSResponder zombie sin usar la terminal?
No hay una herramienta gráfica nativa de macOS que muestre el estado del daemon con ese nivel de detalle. La forma más confiable de diagnosticarlo es con los comandos de terminal dscacheutil -q host -a name ejemplo.com y nslookup ejemplo.com. Si preferís una interfaz visual, podés usar aplicaciones como Little Snitch o herramientas de monitoreo de red que muestren consultas DNS, pero ninguna te va a dar un diagnóstico tan directo como comparar esos dos comandos en 10 segundos.
Conclusión
El mDNSResponder zombie es uno de esos bugs que te hacen perder horas de debugging por un problema que se arregla con un comando de una línea. La arquitectura de dos caminos DNS en macOS es cómoda para ciertos casos de uso, pero genera una asimetría de diagnóstico que confunde incluso a desarrolladores con experiencia. Si te encontrás con “Could not resolve host” en curl mientras nslookup funciona, ya sabés: no toques código, no revises API keys, no reinstales nada. sudo killall -9 mDNSResponder y listo.
