WSL2 y DNS: la solución de resolv.conf que resiste reinicios

Qué sucede realmente cuando WSL2 “pierde DNS”

WSL2 no es una capa de compatibilidad. Es un kernel Linux real que se ejecuta en una VM gestionada.
Tu distro obtiene una interfaz de red virtual en un vSwitch privado; Windows está al otro lado haciendo el trabajo de “uplink”.
El DNS dentro de WSL2, por defecto, es una cadena de confianza:

• Las aplicaciones Linux llaman al resolvedor libc (o a systemd-resolved, dependiendo de la configuración de tu distro).
• El resolvedor lee /etc/resolv.conf (directa o indirectamente).
• Por defecto, WSL2 genera automáticamente /etc/resolv.conf al arrancar a partir de la visión de DNS de Windows.
• La visión de DNS de Windows cambia cuando te conectas a Wi‑Fi, cambias de red, conectas/desconectas la VPN o obtienes una nueva concesión DHCP.
• Algunas VPN instalan proxies DNS, reglas de DNS dividido, o políticas “NRPT”, y Windows las aplica sin problema.
• WSL2 puede no actualizar su configuración generada en caliente de la forma que intuitivamente esperarías.

Cuando las cosas fallan, suele ser una de estas:

• IP de servidor DNS obsoleta en /etc/resolv.conf (común tras suspensión, alternar VPN, cambio de red).
• Servidor DNS inalcanzable porque el DNS del lado de Windows es un proxy local que solo Windows puede alcanzar.
• Desajuste de DNS dividido: Windows sabe resolver dominios internos por política; WSL2 no.
• Rarezas con IPv6: Windows prefiere DNS IPv6, el resolvedor de WSL2 prefiere IPv4, o al revés.
• Dominios de búsqueda rotos: dependes de nombres cortos (git, jenkins) que requieren un sufijo search.
• Raza del resolvedor / caching: un resolvedor local cachea la información errónea y te hace pensar que la red está embrujada.

Editar /etc/resolv.conf “funciona” hasta el reinicio porque WSL2 lo sobrescribe. Eso no es un bug.
Es el contrato por defecto: Windows es la fuente de verdad a menos que explícitamente tomes el control.

Realidad seca: el DNS es la dependencia que olvidas hasta que falla, y cuando falla lo hace todo.
La solución es aburrida. Y lo aburrido es bueno.

Datos históricos y contexto interesante (lo que explica el dolor)

1. resolv.conf viene de hace décadas: el formato del archivo proviene de implementaciones tempranas del resolvedor en Unix y sobrevivió porque todo depende de él.
2. WSL1 y WSL2 son fundamentalmente distintos: WSL1 traducía llamadas al sistema de Linux; WSL2 ejecuta un kernel real en una VM, lo que cambia el comportamiento de la red drásticamente.
3. WSL2 originalmente usó un modelo NAT por diseño: está aislado detrás de un switch virtual, así que Windows actúa efectivamente como gateway y a menudo como “consejero” DNS.
4. systemd no siempre estuvo habilitado en WSL: en distros antiguas de WSL se ejecutaba sin systemd, por lo que el comportamiento del DNS dependía mucho de los valores predeterminados y scripts de la distro.
5. El DNS corporativo puede ser impulsado por políticas: Windows soporta políticas de resolución de nombres y comportamientos por dominio que no se mapean fácilmente a un huésped Linux sin trabajo adicional.
6. Los dominios de búsqueda son una conveniencia heredada: los nombres cortos dependen de reglas search; también son una fuente frecuente de fallos “funciona en mi laptop”.
7. Los clientes VPN suelen implementar “protección” DNS: muchos enrutan el DNS a resolvedores solo por túnel para evitar fugas, lo que puede hacer que las VMs huésped parezcan externos no confiables.
8. El caching de DNS cambió expectativas: las pilas modernas cachean agresivamente (systemd-resolved, nscd, caches del navegador). Puedes arreglar el DNS y aún ver resultados obsoletos.
9. Windows y Linux prefieren herramientas distintas: Windows se apoya en servicios del sistema y políticas; Linux espera servidores explícitos en resolv.conf. WSL2 queda incómodamente entre ambos.

Guion de diagnóstico rápido (primero/segundo/tercero)

Cuando la producción está en llamas no “exploras”. Haces una bisectriz. Aquí está la ruta más rápida hacia la verdad.

Primero: ¿es DNS, enrutamiento o la aplicación?

• Prueba accesibilidad por IP cruda (ping a gateway / IP conocida).
• Prueba la resolución DNS de un dominio público y de uno interno.
• Compara la resolución en Windows frente a WSL2.

Segundo: ¿WSL2 está usando un servidor de nombres obsoleto o inalcanzable?

• Lee /etc/resolv.conf.
• Intenta contactar la IP del servidor de nombres en el puerto 53 (pruebas UDP/TCP).
• Comprueba si el servidor de nombres es una dirección proxy local de Windows que WSL2 no puede alcanzar.

Tercero: ¿es esto DNS dividido / política de VPN?

• Resuelve nombres internos con herramientas de Windows y compara.
• Revisa dominios de búsqueda y expectativas por dominio.
• Decide: ¿necesitas un resolvedor local en WSL2, o puedes apuntar directamente a los resolvedores corporativos?

Regla de decisión: si el servidor de nombres en /etc/resolv.conf es inalcanzable u obsoleto, deja de luchar contra los síntomas.
Toma el control de cómo se genera resolv.conf. Ese es el punto de palanca.

Tareas prácticas: comandos, salida esperada y decisiones

Estas son las comprobaciones que realmente ejecuto. No porque disfrute escribir, sino porque adivinar es caro.
Cada tarea incluye: comando, qué significa la salida y qué decisión impulsa.

Tarea 1: Confirma que estás realmente en WSL2 (no WSL1)

cr0x@server:~$ uname -r
5.15.133.1-microsoft-standard-WSL2

Significado: Si ves microsoft-standard-WSL2, estás en WSL2.
WSL1 se comporta de forma diferente y no tiene los mismos casos límite de DNS con VM.
Decisión: Si no estás en WSL2, detente y ajusta expectativas; este artículo se dirige a WSL2.

Tarea 2: Comprueba la configuración actual del resolvedor

cr0x@server:~$ cat /etc/resolv.conf
# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:
# [network]
# generateResolvConf = false
nameserver 172.26.112.1
search corp.example

Significado: Ese comentario te dice que WSL está generando el archivo automáticamente. El nameserver suele ser una dirección de gateway virtual.
Decisión: Si el DNS falla tras reinicios o alternar la VPN, necesitas desactivar la generación y controlar tú ese archivo.

Tarea 3: Resuelve rápidamente un nombre público (¿funciona el DNS en absoluto?)

cr0x@server:~$ getent ahosts example.com | head
93.184.216.34    STREAM example.com
93.184.216.34    DGRAM
93.184.216.34    RAW

Significado: getent prueba la ruta del resolvedor del sistema (NSS), no solo una herramienta aislada.
Decisión: Si esto falla, el DNS está roto en general. Si funciona pero los nombres internos fallan, piensa en DNS dividido / dominios de búsqueda.

Tarea 4: Confirma que un nombre interno falla como crees

cr0x@server:~$ getent hosts git

Significado: Ninguna salida típicamente significa “no resuelto”, no “red caída”.
Decisión: Si git falla pero git.corp.example funciona, falta o está mal la línea search.

Tarea 5: Usa dig para ver la opinión del resolvedor (timeouts vs NXDOMAIN)

cr0x@server:~$ dig +time=2 +tries=1 git.corp.example

; <<>> DiG 9.18.24-1ubuntu1.4-Ubuntu <<>> +time=2 +tries=1 git.corp.example
;; connection timed out; no servers could be reached

Significado: Timeout significa que no puedes alcanzar el servidor(es) DNS configurado(s). Eso es distinto de NXDOMAIN.
Decisión: Los timeouts te empujan hacia “nameserver inalcanzable/obsoleto”. NXDOMAIN te empuja hacia “servidor DNS equivocado para ese dominio”.

Tarea 6: Identifica la IP del nameserver que usa WSL2

cr0x@server:~$ awk '/^nameserver/{print $2}' /etc/resolv.conf
172.26.112.1

Significado: Quieres la IP exacta para probar conectividad.
Decisión: Si es una dirección privada 172/10/192, probablemente sea el gateway WSL2/Windows o un resolvedor del lado de la VPN.

Tarea 7: Prueba la conectividad al servidor DNS (UDP y TCP)

cr0x@server:~$ NS=$(awk '/^nameserver/{print $2; exit}' /etc/resolv.conf); echo $NS
172.26.112.1
cr0x@server:~$ nc -vz -w2 $NS 53
nc: connect to 172.26.112.1 port 53 (tcp) failed: Connection timed out

Significado: Timeout en TCP 53 es una fuerte pista de que el servidor no es alcanzable desde el huésped.
UDP es más difícil de probar con nc, pero el fallo en TCP ya huele mal.
Decisión: Si el puerto 53 no es alcanzable, deja de perseguir la configuración de resolvedores dentro de las apps. Arregla la ruta al DNS.

Tarea 8: Verifica que tienes enrutamiento básico (¿es DNS o red?)

cr0x@server:~$ ip route
default via 172.26.112.1 dev eth0
172.26.112.0/20 dev eth0 proto kernel scope link src 172.26.121.45

Significado: Ruta por defecto vía la misma IP que tu nameserver es común en WSL2. Si falta esta ruta, tienes problemas mayores que DNS.
Decisión: Si el enrutamiento está roto, reiniciar WSL o la pila de red es el paso cero.

Tarea 9: Comprueba si systemd-resolved está activo y cómo está conectado

cr0x@server:~$ ps -ef | grep -E 'systemd-resolved|named|dnsmasq' | grep -v grep
root         330       1  0 09:12 ?        00:00:00 /lib/systemd/systemd-resolved

Significado: Si systemd-resolved está en ejecución, tu resolvedor puede no estar leyendo /etc/resolv.conf como asumes.
Decisión: Decide si usar correctamente systemd-resolved (recomendado si necesitas DNS dividido), o mantenerlo simple con un resolv.conf estático.

Tarea 10: Inspecciona el objetivo actual de /etc/resolv.conf (archivo vs enlace simbólico)

cr0x@server:~$ ls -l /etc/resolv.conf
-rw-r--r-- 1 root root 188 Feb  5 09:40 /etc/resolv.conf

Significado: Si es un enlace simbólico al archivo stub de systemd, solucionas de forma diferente.
Decisión: Archivo plano significa que WSL lo escribió (o tú lo hiciste). Enlace simbólico suele significar que systemd-resolved lo posee.

Tarea 11: Compara el comportamiento de DNS en Windows (desde dentro de WSL)

cr0x@server:~$ cat /etc/resolv.conf | sed -n '1,5p'
# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:
# [network]
# generateResolvConf = false
nameserver 172.26.112.1

Significado: No podemos ejecutar PowerShell en este bloque bash por las restricciones de formato, pero aún puedes razonar:
si Windows está usando un proxy DNS (común con VPN), WSL podría apuntar a algo que solo Windows alcanza de forma fiable.
Decisión: Si hay una VPN corporativa involucrada, planifica una configuración DNS explícita y estable.

Tarea 12: Reinicia WSL2 limpiamente (pruebas de regeneración forzada)

cr0x@server:~$ wsl.exe --shutdown
The operation completed successfully.

Significado: Esto apaga todas las instancias WSL. El siguiente lanzamiento será un arranque en frío.
Decisión: Usa esto como tu ciclo de prueba “¿mi arreglo sobrevive al reinicio?”.

Tarea 13: Prueba que el archivo se sobrescribe (antes de deshabilitarlo)

cr0x@server:~$ sudo sh -c 'echo "# test-marker" >> /etc/resolv.conf'
cr0x@server:~$ tail -n 3 /etc/resolv.conf
search corp.example
# test-marker

Significado: Ahora apaga WSL y reinicia. Si el marcador desaparece, WSL lo regeneró.
Decisión: Si se sobrescribe, debes desactivar la generación. Cualquier otra cosa es teatro.

Tarea 14: Valida que el DNS funciona tras cambiar de resolvedores

cr0x@server:~$ dig +short example.com
93.184.216.34
cr0x@server:~$ dig +short git.corp.example
10.40.12.23

Significado: Quieres que la resolución pública e interna tenga éxito de forma consistente.
Decisión: Si la pública funciona pero la interna falla, tu elección de servidor DNS es incorrecta para necesidades de DNS dividido.

Una cita para mantenerte honesto: “La esperanza no es una estrategia” — idea común en cultura de operaciones (parafraseada).
El diagnóstico de DNS es exactamente donde la “esperanza” aparece disfrazada de “quizá funcione si reconecto la VPN”.

La solución de resolv.conf que resiste reinicios (rutas recomendadas)

Hay tres estrategias viables. Elige una. Mezclarlas es cómo creas un sistema “a veces”, y “a veces” es el peor SLA.

Estrategia A (recomendada para la mayoría): Desactivar la generación automática y escribir un resolv.conf estático

Esta es la solución más simple cuando puedes apuntar directamente a servidores DNS estables (resolvedores públicos, tu router, o resolvedores corporativos alcanzables en tu red/VPN).
También sobrevive a reinicios porque evitas que WSL reescriba el archivo.

Paso 1: Evitar que WSL genere resolv.conf

cr0x@server:~$ sudo tee /etc/wsl.conf >/dev/null <<'EOF'
[network]
generateResolvConf = false
EOF

Significado: WSL lee /etc/wsl.conf al iniciar. Esto le indica que deje /etc/resolv.conf intacto.
Decisión: Si necesitas estabilidad más que “auto-adaptarse a redes aleatorias”, este es tu movimiento.

Paso 2: Crea tu propio resolv.conf

cr0x@server:~$ sudo rm -f /etc/resolv.conf
cr0x@server:~$ sudo tee /etc/resolv.conf >/dev/null <<'EOF'
nameserver 10.10.0.53
nameserver 10.10.0.54
search corp.example
options timeout:2 attempts:2 rotate
EOF
cr0x@server:~$ sudo chmod 644 /etc/resolv.conf

Significado: Dos nameservers, un dominio de búsqueda y timeouts conservadores para que los fallos fallen rápido en vez de atascar builds.
Decisión: Si no tienes IPs DNS internas estables, no adivines. Consíguelas del equipo de red/VPN o de los detalles del adaptador de Windows.

Paso 3: Reinicia WSL para aplicar

cr0x@server:~$ wsl.exe --shutdown
The operation completed successfully.

Inicia la distro de nuevo y vuelve a probar la resolución (Tarea 14). Si sobrevive múltiples reinicios, has terminado.

Broma #1: El DNS es como el café de la oficina: nadie lo financia correctamente hasta el día en que deja de funcionar, y entonces de repente es la máxima prioridad de todos.

Estrategia B: Usar systemd-resolved dentro de WSL2 para DNS dividido (cuando importan las reglas VPN corporativas)

Si tienes DNS de horizonte dividido (los dominios internos deben ir a resolvedores internos y el resto a públicos),
un resolv.conf estático puede ser demasiado brusco. systemd-resolved puede manejar el enrutamiento por dominio de forma ordenada.
Pero debes conectarlo correctamente, o tendrás lo peor de ambos mundos: cacheo más servidores equivocados.

Enfoque de alto nivel:

• Desactiva la generación de resolv.conf por parte de WSL.
• Haz que /etc/resolv.conf apunte al resolvedor stub de systemd (127.0.0.53) o al archivo gestionado por resolved.
• Configura systemd-resolved con los servidores DNS y dominios de enrutamiento correctos.

Paso 1: Confirma que systemd está disponible/activo

cr0x@server:~$ ps -p 1 -o comm=
systemd

Significado: PID 1 es systemd. Si no lo es, habilitar resolved es otra conversación.
Decisión: Si systemd no está en ejecución, prefiere la Estrategia A a menos que estés listo para replantear la distro.

Paso 2: Configura resolved

cr0x@server:~$ sudo tee /etc/systemd/resolved.conf >/dev/null <<'EOF'
[Resolve]
DNS=10.10.0.53 10.10.0.54
FallbackDNS=1.1.1.1 8.8.8.8
Domains=~corp.example corp.example
DNSSEC=no
EOF
cr0x@server:~$ sudo systemctl restart systemd-resolved

Significado: Domains=~corp.example lo convierte en un dominio de enrutamiento: consultas para esa zona van a tu DNS corporativo.
El simple corp.example establece un dominio de búsqueda para conveniencia.
Decisión: Usa esto cuando tu VPN requiere que los nombres internos se resuelvan internamente pero el DNS público debe mantenerse rápido.

Paso 3: Apunta /etc/resolv.conf a resolved

cr0x@server:~$ sudo rm -f /etc/resolv.conf
cr0x@server:~$ sudo ln -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Feb  5 10:02 /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf

Significado: Las apps leen /etc/resolv.conf, alcanzan 127.0.0.53 y resolved toma decisiones inteligentes.
Decisión: Si ves cache extraño, ahora sabes dónde vive (resolved), y puedes vaciarlo.

Estrategia C: Hacer resolv.conf inmutable (efectivo, pero no me encanta)

Sí, puedes aplicar chattr +i a /etc/resolv.conf. Puede detener las sobrescrituras incluso si olvidas wsl.conf.
También es una trampa: el tú del futuro (o tu automatización) fallará al actualizar DNS y perderá tiempo depurando permisos.

cr0x@server:~$ sudo chattr +i /etc/resolv.conf
cr0x@server:~$ lsattr /etc/resolv.conf
----i--------e----- /etc/resolv.conf

Significado: El bit inmutable está establecido.
Decisión: Úsalo solo si tienes un entorno controlado y entiendes la compensación. De lo contrario: desactiva correctamente la generación.

Broma #2: Poner chattr +i en resolv.conf es como pegar con superglue el termostato—satisfactorio en silencio hasta que facilities lo descubre.

VPN, DNS corporativo y DNS dividido: no adivines

El DNS corporativo rara vez es solo “un par de servidores de nombres”. Es política. Es reenvío condicional. Son zonas internas que nunca deberían filtrarse al internet público.
Los clientes VPN suelen imponer esto canalizando el DNS a través de:

• un resolvedor alcanzable solo por el túnel VPN,
• un proxy DNS local de Windows enlazado a loopback o a un adaptador virtual,
• reglas por dominio que Windows cumple pero Linux dentro de WSL2 nunca ve.

El modo de fallo se ve así:

• Windows resuelve git.corp.example bien.
• WSL2 hace timeout o devuelve NXDOMAIN.
• Editas resolv.conf, funciona por un momento, luego se restablece.
• Tras suspensión/resumen, vuelve a fallar.

La decisión clave es: ¿necesitas DNS dividido dentro de WSL2?

• Si solo necesitas resolución de internet pública: resolv.conf estático apuntando a DNS públicos está bien.
• Si necesitas zonas corp internas: apunta a resolvedores corporativos que sean realmente alcanzables desde WSL2, o ejecuta un resolvedor local con dominios de enrutamiento adecuados.
• Si tu VPN solo expone DNS vía un proxy local de Windows: puede que necesites apuntar WSL2 a una dirección alcanzable (a veces la gateway de WSL), o usar systemd-resolved y proporcionarle los servidores correctos.

Si tu entorno cambia de red con frecuencia (vida de laptop), un resolv.conf estático puede ser “demasiado estable”.
Pero aquí está la realidad práctica: la generación automática de WSL2 no es lo mismo que “DNS dinámico que siempre permanece correcto”.
Es un “mejor esfuerzo al arrancar”. Si tu día incluye alternar VPNs y suspender, quieres control explícito.

Tres mini-historias corporativas desde las trincheras del DNS

Mini-historia 1: El incidente causado por una suposición equivocada

Un equipo de producto tenía una imagen de desarrollo basada en WSL2: Ubuntu, herramientas Docker, algunas utilidades CLI internas.
Funcionaba en la oficina. Funcionaba en la Wi‑Fi de casa. Incluso funcionaba con la VPN—la mayoría del tiempo.
Luego una rotación on-call la usó para un incidente de staging, y de repente la mitad del equipo no pudo resolver nombres internos.

La suposición equivocada fue sutil: “Si Windows puede resolverlo, WSL2 puede resolverlo.”
En Windows, el cliente VPN instaló políticas de DNS por dominio y enruta corp.example a resolvedores internos,
mientras que deja los dominios públicos en el DNS del ISP local. La resolución de nombres de Windows era consciente de políticas.
WSL2 no lo era; heredó un resolv.conf generado al inicio que apuntaba a una IP de gateway que no estaba reenviando DNS de forma fiable bajo la VPN.

El equipo intentó el ritual habitual: reiniciar la VPN, reiniciar WSL, vaciar caches, intentarlo de nuevo.
Obtuvieron éxito intermitente, lo cual es peor que un fallo consistente porque desperdicia horas y crea confianza falsa.
Un ingeniero “lo arregló” hardcodeando un DNS público, que resolvió nombres públicos y rompió silenciosamente la resolución interna.

La solución real fue dejar de generar automáticamente y configurar explícitamente DNS dividido usando systemd-resolved:
zonas internas enrutadas a resolvedores corporativos, DNS de fallback para el resto, y un plan de pruebas claro.
Después de eso, los informes de bugs desaparecieron. No porque el DNS se volviera mágico, sino porque se eliminaron las suposiciones del sistema.

Mini-historia 2: La optimización que salió mal

Otra organización ejecutaba grandes instalaciones de dependencias dentro de WSL2 durante flujos locales tipo CI. Alguien notó que las búsquedas DNS eran “lentas”
y decidió optimizar aumentando los intentos del resolvedor y añadiendo múltiples nameservers públicos “por redundancia”.
Añadieron cuatro nameservers y pusieron attempts:5 y timeout:5.

En laboratorio parecía resiliente. En el mundo real creó la tormenta perfecta:
cuando el primer nameserver se volvió inalcanzable con la VPN, cada consulta se pausó 25 segundos antes de fallar por conmutación.
Multiplica eso por repositorios de paquetes, registros de contenedores y descubrimiento de servicios internos.
Los ventiladores del portátil se aceleraron, los desarrolladores culparon a Docker y el equipo de VPN fue arrastrado a reuniones.

El contragolpe fue clásico: “redundancia” con timeouts largos no es redundancia; es amplificación de latencia.
Un resolvedor solo puede ser tan rápido como su fallo más lento.
Añadir más nameservers sin ajustar timeouts solo incrementa el número de fallos lentos que tendrás que aguantar.

La solución fue aburrida: máximo dos nameservers, timeouts cortos y DNS dividido explícito para que las consultas internas no vaguen hacia resolvedores públicos.
Una vez que midieron de nuevo, la “lentitud del DNS” desapareció—porque había sido autoinfligida.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Un equipo de plataforma mantenía un bootstrap estándar de WSL2 para ingenieros.
Hicieron algo profundamente poco sexy: escribieron un runbook de una página con tres comandos para verificar DNS, más una estrategia canónica de resolv.conf.
Sin heroísmos. Sin “simplemente reiniciar”. Todo era verificable.

Un lunes, una actualización de Windows y una actualización del cliente VPN llegaron cerca una de la otra. De repente, un grupo de ingenieros no podía resolver dominios internos desde WSL2.
En lugar de que todos intentaran arreglos aleatorios, siguieron el runbook:
comprobar nameserver actual, probar alcance del puerto 53, comparar búsquedas internas vs públicas.

El diagnóstico fue consistente entre máquinas: WSL2 recibía una IP de nameserver que solo era válida cuando un adaptador VPN específico estaba arriba.
Tras suspensión/resumen, el adaptador levantó tarde, WSL2 arrancó temprano y resolv.conf se generó con un servidor inalcanzable.
La “solución” no fue luchar contra tiempos; fue desactivar la generación y usar IPs DNS corporativas estables alcanzables por el túnel.

Pusieron una actualización en su bootstrap: establecer generateResolvConf = false, desplegar una plantilla de resolv.conf,
e incluir un paso de verificación rápido. El incidente se convirtió en una molestia menor, sobre todo porque la práctica era repetible y aburrida.
Aburrido vence a emocionante cuando tratas de entregar.

Errores comunes: síntoma → causa raíz → solución

1) “Funciona hasta que reinicio WSL”

Síntoma: Editas /etc/resolv.conf, el DNS funciona y luego se rompe tras el reinicio.

Causa raíz: WSL genera resolv.conf automáticamente al iniciar y sobrescribe tus cambios.

Solución: Añade generateResolvConf = false en /etc/wsl.conf, luego escribe tu propio resolv.conf.

2) “Los dominios públicos resuelven, los internos fallan”

Síntoma: example.com funciona; git.corp.example devuelve NXDOMAIN o hace timeout.

Causa raíz: Estás usando servidores DNS públicos que no conocen zonas internas, o tu política de DNS dividido no está replicada en WSL.

Solución: Apunta WSL a resolvedores corporativos (alcanzables con la VPN) o usa systemd-resolved con dominios de enrutamiento (~corp.example).

3) “FQDN interno funciona, hostname corto no”

Síntoma: getent hosts git.corp.example funciona; getent hosts git falla.

Causa raíz: Falta o está mal el dominio search en resolv.conf (o en la configuración de resolved).

Solución: Añade search corp.example (o configura Domains=corp.example en resolved).

4) “El DNS es lento, los builds se cuelgan, pero acaban teniendo éxito”

Síntoma: Comandos se pausan varios segundos por búsqueda; a veces minutos durante instalaciones de paquetes.

Causa raíz: Timeouts largos del resolvedor, demasiados nameservers, primer servidor inalcanzable o retrasos en la conmutación a TCP.

Solución: Usa 1–2 nameservers alcanzables, establece options timeout:2 attempts:2. Asegura alcance del puerto 53 a los servidores elegidos.

5) “Se rompió al conectar la VPN”

Síntoma: El DNS falla inmediatamente tras conectar/desconectar la VPN.

Causa raíz: Windows cambió el DNS a servidores/proxies provistos por la VPN; resolv.conf de WSL no se actualizó correctamente o se actualizó a un proxy inalcanzable.

Solución: Desactiva la generación automática y establece explícitamente servidores DNS apropiados para el modo VPN; considera systemd-resolved para DNS dividido.

6) “Solo falla tras suspensión/resumen”

Síntoma: Al despertar el portátil por la mañana = fiesta de timeouts de DNS dentro de WSL.

Causa raíz: La VM WSL reanuda con estado de red obsoleto; resolv.conf apunta a un gateway/proxy que no está listo.

Solución: wsl.exe --shutdown y reinicia; la solución a largo plazo es una configuración DNS estable que no dependa de un gateway/proxy transitorio.

7) “Puse chattr +i y ahora nada puede cambiar resolv.conf”

Síntoma: Actualizaciones o scripts fallan al editar resolv.conf; obtienes errores de permiso incluso como root.

Causa raíz: Atributo inmutable establecido.

Solución: sudo chattr -i /etc/resolv.conf, luego gestiona resolv.conf correctamente vía /etc/wsl.conf y tu estrategia elegida.

8) “nslookup funciona pero apt aún falla”

Síntoma: Una herramienta resuelve; otra hace timeout.

Causa raíz: Diferentes rutas de resolvedor (NSS vs consultas directas), capas de cacheo, o diferencias de preferencia IPv6/IPv4.

Solución: Usa getent para la ruta del sistema; verifica /etc/nsswitch.conf incluye dns para hosts; valida registros A y AAAA con dig.

Listas de verificación / plan paso a paso

Lista 1: El plan “hacer que deje de romperse tras reinicio” (DNS estático)

1. Inspecciona /etc/resolv.conf actual y captura la IP del nameserver actual.
2. Prueba alcance a ese nameserver en TCP 53. Si hace timeout, deja de culpar a apt.
3. Crea /etc/wsl.conf con generateResolvConf = false.
4. Reemplaza /etc/resolv.conf con dos nameservers estables y tu dominio de búsqueda.
5. Reinicia WSL con wsl.exe --shutdown.
6. Valida: resuelve un dominio público y uno interno. Repite después de otro reinicio.

Lista 2: El plan “estoy en VPN corporativa y el DNS dividido importa” (systemd-resolved)

1. Confirma que systemd es PID 1 (o acepta que usarás DNS estático).
2. Desactiva la generación de resolv.conf de WSL.
3. Configura /etc/systemd/resolved.conf con DNS corporativo en DNS=, público en FallbackDNS= y dominio de enrutamiento ~corp.example.
4. Enlaza /etc/resolv.conf a /run/systemd/resolve/stub-resolv.conf.
5. Reinicia systemd-resolved y vuelve a probar con dig nombres internos y públicos.
6. Al depurar: vacía caches (reinicia resolved) y vuelve a ejecutar consultas para confirmar comportamiento.

Lista 3: El plan “son las 2am y necesito que funcione ya”

1. Ejecuta getent ahosts example.com. Si falla, esto es DNS amplio.
2. Comprueba la IP del nameserver en /etc/resolv.conf y prueba conectividad TCP 53.
3. Si es inalcanzable: temporalmente configura resolv.conf a un DNS conocido y alcanzable (público o corporativo) y termina el incidente.
4. Después del incidente: implementa la Estrategia A o B correctamente para no repetir esto la próxima semana.

Preguntas frecuentes

1) ¿Por qué WSL2 seguirá reescribiendo /etc/resolv.conf?

Porque por defecto WSL2 trata a Windows como la autoridad de red y genera resolv.conf al iniciar la instancia.
Lo desactivas con generateResolvConf = false en /etc/wsl.conf.

2) ¿Cuál es la solución más segura “configurar y olvidar”?

Estrategia A: desactivar la generación automática y apuntar a nameservers estables que controles y puedas alcanzar.
Añade timeouts razonables. Valida después de varios reinicios.

3) ¿Debería apuntar el DNS de WSL2 a 8.8.8.8 o 1.1.1.1?

Solo si no necesitas zonas internas corporativas y tu organización lo permite.
Si necesitas nombres internos, usa resolvedores corporativos (o DNS dividido con systemd-resolved).

4) Mi /etc/resolv.conf tiene una dirección 172.x. ¿Es eso incorrecto?

No automáticamente. A menudo es el gateway de WSL2 o un reenviador DNS.
Se vuelve “incorrecta” cuando es inalcanzable, está obsoleta o no reenvía correctamente bajo condiciones de VPN.
Prueba el alcance del puerto 53 y la resolución real, no las corazonadas.

5) ¿Por qué veo timeouts en vez de NXDOMAIN?

Timeout significa que tu resolvedor no pudo contactar a ningún servidor DNS. Eso es problema de ruta de red o política de firewall.
NXDOMAIN significa que alcanzaste un servidor DNS y te dijo que el nombre no existe (o no está en esa visión DNS).

6) ¿Puedo arreglar esto reiniciando WSL cada vez?

Puedes, y la gente lo hace. También así acabas con conocimiento tribal en lugar de un sistema.
Reiniciar es un paso diagnóstico; la configuración estable es la solución.

7) ¿Systemd-resolved ayuda, o solo añade complejidad?

Ambas cosas. Ayuda cuando necesitas DNS dividido o comportamiento consistente de cache. Añade complejidad cuando lo único que necesitabas eran dos nameservers estáticos.
Úsalo con intención, no porque viste un post en un blog.

8) ¿Qué pasa con Docker dentro de WSL2—cambia el DNS?

Puede. Los contenedores tienen su propio comportamiento DNS y pueden heredar del resolvedor del host o usar DNS embebido en la red de contenedores.
Arregla primero el DNS del host WSL2. Luego valida la resolución en contenedores si persisten problemas.

9) ¿Por qué se rompe solo en una red Wi‑Fi?

Diferentes redes proporcionan diferentes servidores DNS, distintas configuraciones IPv6 y distintos comportamientos de portales cautivos.
resolv.conf autogenerado puede elegir una configuración “que funciona para Windows, rara para WSL”. Un DNS explícito y estable evita esto.

10) Si desactivo la generación, ¿WSL2 ignorará los cambios de DNS de Windows para siempre?

Sí. Ese es el punto. Si te desplazas entre redes y dependes de que el DNS se adapte automáticamente, necesitarás una estrategia para actualizar tu configuración deliberadamente
(o usar un resolvedor que pueda ingerir políticas), no hacerlo de forma accidental.

Conclusión: siguientes pasos que puedes hacer hoy

Si el DNS de WSL2 falla tras reinicios, no tienes un “problema de Linux”. Tienes un problema de propiedad.
WSL está generando /etc/resolv.conf desde una visión de red de Windows que cambia bajo tus pies.
Tus ediciones desaparecen porque nunca estuvieron en control.

Haz esto a continuación, en orden:

1. Ejecuta el guion de diagnóstico rápido una vez. Confirma si el nameserver está obsoleto/inalcanzable o si el dominio es de DNS dividido.
2. Implementa la Estrategia A (resolv.conf estático) si puedes usar servidores DNS estables y alcanzables. Tiene menos piezas móviles.
3. Implementa la Estrategia B (systemd-resolved) si necesitas DNS de horizonte dividido. Enruta dominios internos explícitamente.
4. Prueba tras wsl.exe --shutdown dos veces. Si solo funciona “a veces”, no has terminado.

El objetivo no es tener el DNS “funcionando ahora mismo”. El objetivo es tener el DNS funcionando mañana por la mañana después de suspender, después de la VPN, tras la próxima actualización,
sin que realices rituales. Los sistemas de producción no aceptan rituales. Tu entorno de desarrollo tampoco debería aceptarlos.