En macOS 26 no funcionan las configuraciones DNS personalizadas como `.internal`

• En macOS 26.3.1, las configuraciones DNS por dominio basadas en /etc/resolver/ quedan invalidadas para TLD no estándar, lo que interrumpe entornos locales de desarrollo ya existentes
• mDNSResponder procesa las solicitudes de TLD personalizados solo como mDNS y no consulta en absoluto los servidores de nombres unicast especificados
• .internal, .test, .home.arpa, .lan y, en general, los TLD que no están en la zona raíz de IANA fallan, mientras que los dominios estándar (google.com, etc.) funcionan normalmente
• La única solución temporal es registrarlos manualmente en /etc/hosts, pero en entornos dinámicos (Docker, Kubernetes, etc.) esto no es realista
• Se interrumpe por completo todo el flujo de trabajo de DNS local que la comunidad de desarrolladores de macOS ha usado durante años, con un impacto amplio en herramientas de desarrollo e integraciones con VPN

---

Regresión de DNS en macOS 26

• En macOS 26.3.1 (Darwin 25.3.0, Build 25D771280a), se rompe la función de configuración DNS por dominio mediante /etc/resolver/

  • Era una función que trabajaba normalmente hasta macOS 25.x, pero dejó de hacerlo tras actualizar a la versión 26
  • Aunque es una función documentada oficialmente por Apple (man 5 resolver), ya no funciona con TLD no estándar

• mDNSResponder intercepta todas las solicitudes para TLD personalizados como mDNS e ignora los servidores de nombres unicast configurados

  • Todas las aplicaciones que usan getaddrinfo() (ping, curl, python3 socket) muestran el error “Unknown host”
  • Según tcpdump, no se genera ningún tráfico hacia el DNS local (127.0.0.1:53)
  • En el comando dns-sd -G v4 aparece la respuesta “No Such Record” junto con un TTL anormalmente largo (aprox. 108,002 segundos)

Pruebas y pasos para reproducir

• Se configura dnsmasq instalado con Homebrew como resolvedor DNS local y se mapean dominios *.internal o *.example-private a 127.0.0.1

  • En el archivo /etc/resolver/example-private se especifica nameserver 127.0.0.1
  • El comando scutil --dns muestra que ese resolvedor está registrado correctamente
  • Sin embargo, al ejecutar ping probe.example-private aparece el error “Unknown host”

• dig @127.0.0.1 y el comando host devuelven respuestas normales, pero todas las apps que usan el resolvedor del sistema fallan

  • Esto se debe a que mDNSResponder bloquea internamente las consultas y no invoca el DNS unicast

Lista de TLD afectados

TLD	Estado	Nota
.internal	Falla	TLD de uso especial en borrador del IETF; funcionaba en macOS 25
.test	Falla	Reservado para pruebas locales según RFC 6761 §6.2
.home.arpa	Falla	Reservado para redes domésticas según RFC 8375
.lan	Falla	No oficial, pero ampliamente usado
Otros TLD no registrados	Falla	Cualquier TLD que no esté en la zona raíz de IANA

• En el caso de .test, aunque debería resolverse mediante DNS normal según lo especificado en la RFC 6761, macOS 26 lo trata como exclusivo de mDNS
• En cambio, dominios registrados en IANA como google.com y bbc.co.uk siguen funcionando normalmente

Impacto en entornos y herramientas de desarrollo

• Se rompe por completo todo el flujo de trabajo de DNS para desarrollo local

  • Desarrolladores que usan la combinación dnsmasq + /etc/resolver/ con *.test, *.internal, etc.
  • La resolución de nombres de contenedores en Docker Desktop y herramientas similares
  • Vagrant, Tailscale y clientes VPN que generan automáticamente archivos /etc/resolver/
  • Herramientas de desarrollo local para Kubernetes (minikube, kind, k3d, etc.) para resolver *.cluster.local

• Como el sistema muestra la configuración del resolvedor como correcta en scutil --dns, para el usuario es difícil detectar el problema y no hay registros ni mensajes de error

Solución temporal y limitaciones

• La única forma que funciona es agregar manualmente el mapeo de dominios en /etc/hosts
  • Este método evita por completo mDNSResponder
  • Pero no es realista en Docker ni en entornos con DNS dinámico, y además requiere privilegios sudo cada vez que hay cambios

Especificaciones técnicas y entorno de validación

• macOS 26.3.1 (Build 25D771280a), Apple Silicon (arm64)
• dnsmasq instalado mediante Homebrew y escuchando en 127.0.0.1:53
• Los comandos dig y host responden correctamente; ping, curl y python3 socket.getaddrinfo fallan
• Documentación y estándares relacionados:
  • man 5 resolver — documentación del mecanismo /etc/resolver/ en macOS
  • RFC 6761 — define dominios de uso especial como .test, .localhost, .invalid y .example
  • RFC 8375 — define el dominio home.arpa
  • IETF draft-ietf-dnsop-interneti-mdn — borrador del dominio de uso especial .internal

[lidar]

Por esto no he podido usar Tailscale MagicDNS durante varios días..

[minhoryang]

Esperemos que tailscale ayude a sortear este problema.

[GN⁺]

Opiniones de Hacker News

• Me fui de macOS por este tipo de molestias pequeñas (papercuts)
  Usar un LLM para redactar reportes de bugs está bien si luego se revisan, pero si deja pasar errores obvios como “funcionaba en macOS 25”, eso le quita credibilidad
  Si este tipo de reportes aumenta, creo que la gente va a empezar a descartar sin más los reportes escritos por IA por la carga que implica verificarlos

  • Creo que usar contenido generado por IA sin indicarlo explícitamente es totalmente inaceptable
    Poner a la IA a escribir en mi nombre es una falta de respeto que da la impresión de “mi tiempo vale más que el tuyo”
    Si te pondría en una situación incómoda admitir públicamente que usaste IA, eso en sí mismo ya debería hacerte replantear para qué la estás usando
  • Todos los sistemas operativos tienen este tipo de molestias pequeñas
    En Linux o Windows se pueden contar ejemplos igual de dolorosos. Al final es cuestión de “elegir qué veneno prefieres”
  • Este tipo de problemas lleva décadas siendo una tradición de Apple
    Microsoft era famosa por mantener la compatibilidad hacia atrás, mientras que Apple lo era por romper sin miedo funciones existentes
    Hoy en día Microsoft ya no es tan conservadora como antes, y Apple incluso da la impresión de haberse vuelto más estable que en el pasado
  • De todos modos, Apple ya tiene desde hace tiempo fama de ser una empresa que no lee mucho los reportes, así que aunque tiren a la basura reportes hechos con LLM, probablemente no cambie nada
  • He sufrido este tipo de molestias en todos los sistemas operativos, pero en Linux hacer rollback es fácil
    En NixOS, por ejemplo, eliges una versión anterior desde el menú de arranque y todo el sistema vuelve atrás
    En la laptop uso macOS, pero el trabajo real lo hago casi siempre dentro de contenedores Linux

• macOS 26 es, hasta ahora, la versión que más rompe compatibilidad
  Varias modificaciones intencionales han hecho que desarrollar apps sea muy difícil
  Por ejemplo, la app Lunar ya no puede ajustar arbitrariamente los niveles de nits SDR, así que el control de brillo quedó bloqueado,
  y la app YellowDot dejó de servir porque ya no puede ajustar el brillo del indicador del micrófono
  Además, hay varios bugs como problemas con eventos del mouse en ventanas sin título, imposibilidad de aplicar tablas gamma,
  y pérdida de la ruta del archivo original al arrastrar en apps como Clop

  • Hay rumores de que iOS 27 será una versión de estabilización al estilo Snow Leopard
    Ojalá macOS 27 también lo sea (fuente)
  • Como alguien que produce música por hobby, el indicador del micrófono me parece realmente innecesario y molesto
    La filosofía de macOS se siente demasiado terca y unilateral, y eso frustra
  • Me pregunto si el problema de YellowDot no podría rodearse usando una LUT para mapear el color del punto de grabación a negro
    No uso macOS directamente, pero en teoría parece posible
  • Con razón en M1 llegaba bien hasta 1600 nits, pero en M5 no pasa de 600 nits
    Parece que por ahora no queda más que resignarse
  • La limitación del brillo del punto del micrófono existe por motivos de privacidad
    La idea es impedir que el malware oculte el acceso a la cámara o al micrófono
    Además, el límite de brillo SDR podría estar pensado para prevenir con anticipación los problemas de batería de las pantallas OLED que saldrán pronto

• Sigo esperando el día en que Apple separe hardware y software
  Quiero Apple Silicon, pero no su sistema operativo
  Si no puedo ejecutar mi propio kernel y mis propios módulos, entonces ese equipo no es mío
  La laptop de al lado arranca con coreboot, y eso refleja mi filosofía

  • ¿En una Mac no se puede ejecutar tu propio kernel? ¿El problema no es más bien el soporte de drivers?
  • macOS no es perfecto, pero llamarlo en conjunto “terrible” me parece una valoración exagerada
  • A mí tampoco me disgusta macOS. Pero afirmar de forma tajante que es “terrible” no resulta muy convincente

• Para desarrollo web local uso *.localhost
  Todos los navegadores modernos lo resuelven automáticamente a 127.0.0.1, así que no hace falta configurar DNS ni modificar hosts
  Eso sí, no aplica a programas fuera del navegador (python, wget, etc.)

  • *.*.localhost también está soportado, así que ahora se puede replicar localmente la misma estructura de dominios de producción
    ArchiveBox usa esta función para aislar dominios por snapshot y así reducir riesgos de seguridad
  • En Tahoe funciona bien incluso con python o wget
  • Lo probé en Chrome, y supongo que en Safari funcionará igual
  • Yo también uso este método. Aunque .localhost se me hace un poco largo
    Antes usaba .local, pero daba muchos conflictos
  • Nosotros usamos dev.our-root-domain.com mapeado a 127.0.0.1 en el DNS público

• En una vieja máquina con Yosemite he usado una configuración que ofrece varios TLD locales
  El método de /etc/resolver ya estaba marcado para deprecación desde alrededor de 2014, y parece que ahora por fin lo quitaron por completo
  En su lugar, lo correcto es guardar la configuración usando directamente scutil

  • Pero con scutil solo no alcanza
    Algunas consultas de macOS todavía pasan por mDNSResponder, que ignora o sobrescribe esa configuración
    Por eso, al final usar unbound o dnsmasq termina siendo más simple

• Yo también uso varios TLD con la combinación de /etc/resolver/X y dnsmasq, y no tengo problemas
  En el archivo de configuración siempre incluyo la directiva domain
  En la práctica, casi siempre ha sido necesaria esa configuración
  Quizás agregar la entrada domain resuelva el problema

• Uso Linux principalmente, pero no entiendo muy bien por qué la gente dice que el diseño de macOS es malo
  Si solo miras la UX, macOS siempre me pareció bastante pulido
  Incluso muchos temas populares de Gnome imitan el estilo de macOS

  • En internet hay un sesgo que hace más visibles a quienes más se quejan
    Sobre todo en HN, eso me parece aún más cierto
  • La versión Tahoe también me ha parecido bastante buena en general
    Ajustar las esquinas de las ventanas es incómodo, pero en conjunto me deja satisfecho
    Al final, todos los sistemas operativos tienen bugs
  • La cultura de Apple de agregar funciones sin parar (feature creep) hace que la UX cambie de formas innecesarias una y otra vez
    Un ejemplo claro son los cuadros de diálogo de notificaciones
  • A mí también me gusta la estética de macOS
    Lo que sí extraño es la falta de personalización
    Extrañar interfaces antiguas como Windows 98 quizá solo sea una cuestión generacional
  • En general me gusta la UX
    La forma de pasar a pantalla completa es peculiar, pero cuando te acostumbras resulta cómoda
    Lo que sí molesta es la falta de window tiling
    Aun así sigo prefiriendo Linux, aunque suspend y la gestión de energía lleven 8 años siendo un problema

• Hubo una época en que Apple bloqueó en iOS los certificados autofirmados, y eso volvió casi imposible el desarrollo local con HTTPS
  Cuesta entender por qué tocaron algo así

• A mí me gusta macOS
  Trae zsh por defecto, y puedo hacer en una computadora personal casi todo lo que hacía en Linux

• *.localhost funciona por defecto
  Incluso sin dnsmasq se pueden apuntar varios nombres de host a 127.0.0.1

  • Pero este método se queda corto cuando necesitas mapear una IP privada interna a otra dirección
  • Dominios como *.example-private hacen falta para distinguir varios dispositivos mediante IP privadas
    Si solo vas a usar localhost, entonces basta con usar 127.0.0.1
    En lo personal, uso *mDNS con .local para aprovechar la configuración automática basada en DHCP