Actualizaste a macOS 26 y de repente tu entorno de desarrollo local dejó de funcionar. No es tu código. Es el sistema operativo. Un bug documentado en la versión 26 y 26.1 rompe la resolución de DNS personalizado —el mecanismo que hace que dominios como .internal, .test o .lan funcionen sin salir a internet. Y Apple todavía no ha publicado un parche.
El problema ya tiene varios repositorios de GitHub con reportes, y afecta a todo el stack habitual del desarrollo local moderno: Docker Desktop, Kubernetes, dnsmasq, y cualquier herramienta que dependa de /etc/resolver/ o perfiles .mobileconfig para redirigir dominios no estándar a servidores DNS locales.
¿Qué se rompe exactamente?
macOS tiene un mecanismo llamado resolución DNS suplementaria: los archivos dentro de /etc/resolver/ permiten decirle al sistema “para todo lo que termine en .test, pregúntale a este servidor DNS, no al de internet”. Es el fundamento de cómo Docker Desktop expone los contenedores con nombres legibles, cómo Kubernetes hace que los pods se hablen por nombre, y cómo muchos equipos usan dominios internos tipo api.miempresa.internal en staging.
Claude Desbloqueado
Mi curso avanzado para aprender a sacarle mucho más provecho a Claude en el trabajo y en el día a día, con funciones y usos más potentes. Comienza el 23 de marzo.
→ Inscríbete hoy 🚀En macOS 26, ese mecanismo falla para nuevas configuraciones. Los perfiles .mobileconfig con configuraciones DNS encriptadas —usados por soluciones como AdGuard Home, NextDNS y similares— no pueden instalarse ni actualizarse. Las entradas en /etc/resolver/ para TLDs personalizados dejan de resolverse correctamente. Lo que sí funciona son los perfiles que ya estaban instalados antes de la actualización, pero no pueden modificarse.
Hay un bug report en GitHub (gist.github.com) que documenta el comportamiento con precisión: la solución de dnsmasq en puerto alternativo (5300) puede ayudar en algunos casos, pero no resuelve el problema de fondo.
¿A quién golpea y cómo?
Si trabajas con un Mac y tu stack local usa alguna de estas cosas, probablemente ya lo notaste:
- Docker Desktop: los contenedores accesibles por nombre de dominio (no por IP) pueden fallar.
- Kubernetes local (Minikube, Kind, Rancher Desktop): la resolución intra-clúster puede romperse dependiendo de la configuración.
- dnsmasq con wildcard domains: la configuración clásica de
*.test → 127.0.0.1deja de funcionar en instalaciones nuevas. - Empresas con stagings privados por dominio interno: si el equipo tiene Macs que actualizaron, las conexiones a servicios internos pueden fallar silenciosamente.
El impacto no es solo molestia. Los pipelines de CI/CD que corren en Mac, los entornos de QA con dominios internos y los flujos de testing automatizado que dependen de esta resolución pueden simplemente romperse sin mensaje de error obvio. Lo que convierte este bug en particularmente traicionero es eso: no falla con un error claro, sino que los dominios simplemente no resuelven.
Workarounds mientras Apple no parchea
La recomendación más segura por ahora es no actualizar a macOS 26 si dependes de DNS personalizado en tu flujo de trabajo —algo que ya debería ser regla general para cualquier actualización mayor de sistema operativo en entornos de producción o desarrollo crítico.
Si ya actualizaste, estas son las opciones disponibles hoy:
- DNS manual sin cifrado: ir a Configuración del Sistema → Red → Detalles → DNS y agregar servidores como 8.8.8.8 o 1.1.1.1. Funciona, pero sin encriptación y sin resolución de dominios internos.
- NextDNS vía VPN local: usar la integración por VPN de NextDNS como alternativa a los perfiles .mobileconfig que no se pueden instalar.
- dnsmasq en puerto alternativo: configurar dnsmasq para escuchar en el puerto 5300 y apuntar el archivo en
/etc/resolver/a ese puerto. No funciona para todos los casos, pero resuelve algunos. - Verificar estado con:
scutil --dns | grep 'nameserver\[[0-9]*\]'para entender qué resolvers están activos realmente.
No hay parche oficial. La recomendación oficial de Apple es usar Feedback Assistant para reportar el problema.
Por qué importa más allá del bug
Este incidente evidencia algo que el ecosistema macOS raramente discute abiertamente: la infraestructura local de desarrollo en Mac lleva años acumulando capas de workarounds sobre un sistema de resolución DNS que no fue diseñado para los flujos de trabajo modernos. Docker, Kubernetes, dnsmasq y decenas de herramientas del stack actual usan mecanismos semi-documentados de macOS que Apple puede cambiar —o romper— con cualquier actualización.
La pregunta que deberían hacerse los equipos no es solo “¿cómo arreglamos esto?”, sino “¿cuánto de nuestro entorno local depende de comportamiento no documentado del sistema operativo?” Es el tipo de deuda técnica invisible que solo aparece cuando algo se actualiza.
Si tu equipo tiene Macs y depende de dominios internos, DNS custom o Docker con resolución de nombres: no actualices hasta que Apple publique un parche. Y si ya actualizaste, documenta lo que encontraste —la comunidad lo necesita.
