El orden de la resolución de nombres en Windows — hosts, la caché DNS, LLMNR/mDNS y DoH

«La configuración es la misma, pero solo este PC no alcanza el servidor interno.» «Se abre en el navegador, pero la aplicación empresarial falla en la resolución de nombres.» «Lo puse en hosts y no surte efecto.»

Al investigar problemas como estos, lo primero que hay que establecer es qué mecanismo está respondiendo por ese nombre. Windows tiene varias rutas: la caché, hosts, el servidor DNS, LLMNR, NetBIOS y mDNS, y algunas aplicaciones usan una ruta propia, aparte de Windows.

Este artículo da primero el panorama general, ordena la forma de un nombre y las diferencias entre las rutas, y después pasa al procedimiento real de aislamiento. Si necesita investigar ahora mismo, salte a la sección pertinente desde la tabla siguiente.

Premisas de este artículo

El artículo de captura de paquetes cubre los paquetes que circulan por el cable, y el artículo de proxy cubre «de quién se leen los valores de proxy». Este artículo cubre el paso anterior: «de dónde salió la dirección IP de destino», organizado a partir de las fuentes primarias de Microsoft.

1. La conclusión primero

Hay tres cosas que conviene recordar.

• La resolución de nombres de Windows no siempre recorre una sola cola en orden. La caché y hosts van primero, pero en un nombre de una sola etiqueta, DNS y LLMNR/NetBT se ejecutan en paralelo de forma predeterminada.³⁴
• El mismo nombre da resultados distintos cuando cambian la configuración del PC y la ruta de la aplicación. Piense por separado en los sufijos, la VPN, la NRPT y el resolvedor integrado del navegador.⁵⁶⁷
• En una investigación, restrinja la ruta en uso y compare los resultados. Separe caché, DNS y vínculo local con los modificadores de Resolve-DnsName, y confirme después con una comparación de configuración frente a un PC que funciona y con una captura.⁸

Use el diagrama siguiente como mapa de conjunto.

flowchart TB
    accTitle: La resolución de nombres es un apilamiento de capas
    accDescr: La solicitud de resolución de nombres pasa de la API de la aplicación al servicio Cliente DNS; primero se consultan la caché y hosts, después el servidor DNS y, solo en nombres de una sola etiqueta, LLMNR y NetBIOS (en paralelo con DNS de forma predeterminada). En nombres .local, mDNS es una ruta adicional junto al DNS configurado. El navegador tiene su propio resolvedor fuera de esta cola
    app["Aplicación (getaddrinfo)"] --> svc["Servicio Cliente DNS"]
    svc --> cache["Caché (incluye hosts)"]
    cache -->|si no hay respuesta| dns["Consultar el servidor DNS"]
    cache -->|"si no hay respuesta, nombre de una sola etiqueta (en paralelo con DNS de forma predeterminada)"| ll["LLMNR / NetBIOS"]
    svc -->|"nombre .local (ruta adicional)"| mdns["mDNS"]
    browser["Navegador"] -.->|resolvedor propio, DoH| ext["Ruta aparte"]

La caché se consulta primero; más allá, DNS y, en nombres de una sola etiqueta, LLMNR y NetBIOS se ejecutan en paralelo. El navegador tiene una ruta aparte.

A continuación, «qué capa responde» se cubre en los capítulos 3 a 5, «cómo se envía la consulta» en el capítulo 6 y «cómo verificarlo» en los capítulos 7 y 8. DoH es una característica que cambia el transporte hacia el servidor DNS a HTTPS; no sustituye el orden de hosts, caché y NRPT.⁹

En el diagrama, una línea continua marca una relación que siempre se cumple y una línea discontinua una relación condicional (las condiciones están en la explicación de cada relación en la página de detalle). La lista completa de relaciones (48 en total, con evidencia y grado de certeza) y las definiciones de los conceptos principales están reunidas en la página de detalle del mapa de conocimiento (en japonés). Datos: JSON-LD / Turtle

2. La «resolución de nombres» no es una sola operación

Lo único que recibe la aplicación es una dirección o un error

Cuando una aplicación se conecta usando un nombre como www.example.com, se llama a getaddrinfo de Winsock (la versión Unicode es GetAddrInfoW). Para el espacio de nombres NS_DNS, esta función convierte el nombre en una dirección a través de DNS, el archivo hosts local y otros mecanismos. Si responden varios proveedores de espacio de nombres, agrega sus respuestas y las devuelve.¹⁰

Es decir, a partir del resultado que recibe la aplicación no se puede saber qué capa respondió.

Dns.GetHostAddresses de .NET también usa getaddrinfo en Windows. Para un host listado en hosts, devuelve esa dirección sin consultar un servidor DNS. HttpClient también se ejecuta sobre esta clase Dns, de modo que una aplicación .NET que se conecta directamente a su destino hereda el orden de resolución de nombres de Windows.¹¹

Si se pasa por un proxy HTTP, el nombre que se resuelve cambia. Lo que se resuelve en local es el nombre del proxy; el nombre de destino se resuelve en el lado del proxy. En ese caso, hosts, la caché, los sufijos y la NRPT locales no intervienen en la resolución del destino. Qué valores de proxy se usan se cubre en el artículo de proxy.

2.1 El servicio Cliente DNS decide el orden

Quien trabaja debajo de getaddrinfo es el servicio Cliente DNS (nombre de servicio Dnscache). La documentación de Microsoft describe el orden básico así.³

1. Comprobar la caché.
2. Comprobar el archivo hosts.
3. Consultar el servidor DNS.

Como el contenido de hosts se carga en la caché al iniciar el servicio, este artículo trata los dos primeros juntos como capa 1, «caché y hosts».⁵

Más allá, la ruta se ramifica según el nombre y las directivas.

La «resolución de nombres inteligente con varios hosts» predeterminada envía consultas DNS, LLMNR y NetBT a todas las redes en paralelo. Qué respuesta se adopta lo deciden las reglas de las secciones 4.3 y 5.2.⁴

Por tanto, «cuándo se envía la consulta» y «la prioridad que se da a las respuestas que vuelven» son dos asuntos distintos. Ver LLMNR o NetBT en una captura no significa por sí solo «DNS falló». Las «tres capas» de este artículo son una división para explicar; no significan que las capas se ejecuten siempre en secuencia en el tiempo.

2.2 Lo que queda fuera de la cola

Los dos que más se confunden son estos.

Usar el cliente integrado de Edge no significa por sí solo que cambie el servidor DNS. La sección 6.2 lo trata por separado de la configuración de DNS seguro que selecciona otro proveedor.

3. Capa 1 — La caché y hosts

Lo que se quiere saber en esta capa es qué respuestas quedan dentro del PC. La caché no solo guarda respuestas correctas, también respuestas obsoletas y respuestas de «el nombre no existe».

3.1 hosts se carga en la caché

El archivo hosts está en C:\Windows\System32\drivers\etc\hosts. Cuando se inicia el servicio Cliente DNS, sus asignaciones de nombre a dirección IP se cargan en la caché del resolvedor. Los registros obtenidos de consultas DNS se conservan en la misma caché durante su TTL (time to live).⁵

ipconfig /displaydns muestra tanto las entradas cargadas desde hosts como las obtenidas por consultas DNS recientes.¹³ En el propio ejemplo de Microsoft, si pone contoso.com en hosts, Resolve-DnsName contoso.com devuelve esa dirección y no circula tráfico DNS.³

Cómo leer la ausencia de paquetes DNS

Si resuelve un FQDN sin DoH ni DoT, la resolución de nombres tiene éxito y no hay consulta en el puerto 53, cabe suponer que responde la caché o hosts. Antes, no obstante, descarte las otras rutas siguientes.

No concluya «caché» solo porque «no hay nada en el puerto 53»; mire también las rutas que podrían estar en uso. Una sola línea de hosts de prueba dejada en una máquina de desarrollo puede desviar una investigación.

Editar hosts requiere derechos de administrador, y los productos de seguridad pueden detectar el cambio. Conviene evitar un diseño que haga depender las operaciones de la aplicación empresarial de hosts.

3.2 Las respuestas negativas también se almacenan en caché

«No encontrado» también es una de las respuestas que se almacenan en caché. El cliente DNS guarda las respuestas negativas igual que las positivas.⁵

Si ipconfig /displaydns muestra «Name does not exist» para el nombre de destino, en el cliente queda una respuesta negativa del servidor DNS. El procedimiento de Microsoft indica descartarla con ipconfig /flushdns.¹⁴¹³

El tiempo de retención de la caché negativa es MaxNegativeCacheTtl en HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters, y el valor predeterminado es 5 segundos.¹⁵ Por eso un PC puede seguir devolviendo fallos durante unos segundos incluso justo después de que se haya añadido un registro a DNS.

3.3 TTL y «solo algunos PC están obsoletos»

Las respuestas positivas también permanecen durante su TTL. Un PC que resolvió el nombre antes de que se cambiara la dirección IP del servidor sigue usando la respuesta antigua, mientras que un PC que lo resuelve por primera vez después del cambio obtiene la nueva. Aunque el servidor DNS sea el mismo, el resultado difiere cuando difiere el momento de la consulta.⁵

Clear-DnsClientCache se comporta igual que ipconfig /flushdns y elimina todo el contenido de la caché, incluidas las respuestas negativas.¹⁶ Con Get-DnsClientCache puede recuperar la caché como objetos y comprobar el tipo de registro y el TTL restante.¹⁷

# ¿Está un nombre concreto en la caché y cuántos segundos de TTL quedan?
Get-DnsClientCache -Entry 'app01.corp.example.com' |
    Select-Object Entry, Type, Status, TimeToLive, Data

# Comprobar juntos el contenido de hosts y de la caché
ipconfig /displaydns | Select-String -Pattern 'app01' -Context 0,6

# Descartar la caché (incluidas las respuestas negativas)
Clear-DnsClientCache

Si se encuentra una respuesta en la capa 1, esta consulta queda decidida antes de llegar al servidor DNS. Sin embargo, sigue abierta la posibilidad de que una respuesta incorrecta se aprendiera originalmente del servidor DNS. No se detenga al borrarla; compruebe también la respuesta obtenida de nuevo en el paso 3 del capítulo 8.

4. Capa 2 — Consultar el servidor DNS

Si la capa 1 no tiene respuesta, la resolución pasa a DNS. Aquí, piense por separado qué nombre se envía, a qué servidor y en qué momento.

4.1 Nombres de una sola etiqueta y sufijos

Primero, compruebe la forma del nombre que pasó la aplicación.⁵

Un sufijo es la parte de dominio que se añade después de un nombre corto. Añadir corp.example.com a app01 hace que el nombre consultado sea app01.corp.example.com.

Cuando existe una lista de búsqueda

Los sufijos de la lista de búsqueda de sufijos DNS se añaden en orden desde arriba, y el nombre se envía con un punto final. Una vez configurada una lista de búsqueda, solo se usa esa lista. No se usan el sufijo primario, los sufijos específicos de la conexión ni la devolución de nombres.¹⁸

Cuando no hay lista de búsqueda

Se añade el sufijo DNS primario. Si la devolución de nombres está habilitada, tras cada fallo se quita la etiqueta más a la izquierda y se vuelve a probar el nombre; por ejemplo, de www.test.contoso.com a www.contoso.com. Si un adaptador tiene un sufijo DNS específico de la conexión, ese también se añade y se envía.⁵

Por eso, el mismo server01 se expande de forma distinta en un entorno donde la Directiva de grupo distribuye una lista de búsqueda y en un entorno donde la pertenencia al dominio aporta un sufijo primario.

Una lista larga también aumenta la espera

Si el sufijo correcto está cerca del final de la lista, el tiempo de consulta se acumula hasta llegar a él. Microsoft también explica este retraso con un ejemplo que prueba seis sufijos. Para probar solo una expansión concreta, añada un punto final, como en internal.contoso.com..³

# Configuración global: lista de búsqueda y devolución de nombres
Get-DnsClientGlobalSetting

# Por interfaz: sufijo específico de la conexión y configuración de registro
Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix, UseSuffixWhenRegistering

# Servidores DNS por interfaz (IPv4 e IPv6)
Get-DnsClientServerAddress | Where-Object ServerAddresses | Select-Object InterfaceAlias, AddressFamily, ServerAddresses

Get-DnsClientGlobalSetting devuelve la configuración global, como la lista de búsqueda y si la devolución de nombres está habilitada y hasta qué nivel; Get-DnsClient devuelve la configuración por interfaz.¹⁹²⁰

4.2 El orden de varios servidores DNS y los tiempos de espera

Cuando «no falla, pero hay una espera de varios segundos», sospeche retransmisiones a un servidor DNS que no responde. Para los servidores DNS configurados en una sola NIC, el momento de retransmisión predeterminado se alinea así.²¹

Esta es la tabla para el caso en que no hay respuesta. En particular, no confunda estos dos.

Cuando «paramos uno y no conmuta», si un servidor que conserva una zona antigua sigue en marcha y devuelve respuestas negativas, la resolución no pasa al siguiente servidor.²¹

Los servidores a partir del cuarto no se alcanzan hasta los 4 segundos

Si el servidor que puede responder es el cuarto o posterior de la lista, transcurren al menos 4 segundos desde la primera consulta. Si el plazo de la aplicación es más corto, falla en la etapa de resolución de nombres. Para sacar la consulta antes, habría que mover ese servidor a los tres primeros, pero la corrección de raíz es reparar los servidores inalcanzables que van delante, o quitarlos de la configuración. Revise también el tiempo de espera del lado de la aplicación.²¹

En el ejemplo de Microsoft, también, una configuración en la que solo uno de cuatro servidores es alcanzable tarda unos 4 segundos en completar. Puede medir el tiempo transcurrido con Measure-Command, y el mismo documento trata menos de 1 segundo como aceptable.³

# Preguntar a un servidor concreto de forma directa, solo DNS, y obtener el tiempo transcurrido en milisegundos
(Measure-Command {
    Resolve-DnsName -Name 'app01.corp.example.com' -Server 10.0.1.2 -DnsOnly
}).TotalMilliseconds

Como este comando fija el servidor, mide el tiempo de respuesta de ese servidor solo. El retraso hasta alcanzar la cuarta entrada de la lista se comprueba con una consulta sin -Server, o con una captura de esa consulta.

Tenga en cuenta que el cliente DNS adelanta los servidores que responden más rápido, recuerda los que no responden y los reintenta periódicamente. El tiempo de espera inicial también se ajusta en un intervalo de 25 a 1.000 milisegundos según el rendimiento pasado. La tabla anterior es el esqueleto predeterminado, por eso las mediciones reales se apartan de ella.⁵

4.3 Varias NIC y la «resolución de nombres inteligente con varios hosts»

En un PC con cable y Wi-Fi, o en un PC al que se añade un adaptador VPN, compruebe no solo la lista de servidores DNS, sino también la consulta a través de las redes y la selección de la respuesta.

Retransmisión a varios adaptadores

En el procedimiento de consulta de Microsoft, la consulta va al primer servidor DNS del adaptador preferido, con una espera de 1 segundo. Si no hay respuesta, va al primer servidor de cada adaptador que sigue en el conjunto de candidatos, con una espera de 2 segundos, y después a todos los servidores de todos los adaptadores, con esperas de 2, 4 y 8 segundos. Cuando un servidor de un adaptador devuelve una respuesta negativa, los demás servidores de ese adaptador se quitan de los candidatos.⁵

La directiva que controla la consulta en paralelo

La Directiva de grupo «Desactivar la resolución de nombres inteligente con varios hosts» controla el comportamiento siguiente.⁴

Como la directiva se llama «Desactivar», tenga en cuenta que habilitar la directiva desactiva la optimización.

Un ejemplo en el que la VPN cambia el resultado

Cuando se consulta un nombre interno, el DNS del lado de la VPN devuelve la dirección interna, y el DNS del lado del router doméstico también puede devolver otra respuesta positiva: una dirección pública bajo el mismo nombre de dominio que el interno, o la dirección de una página publicitaria sustituida por un nombre inexistente, por ejemplo.

Con dos respuestas positivas, la adopción la decide el orden de enlace. En el Windows actual, esta prioridad la determina la métrica de interfaz; cuanto menor es el InterfaceMetric que muestra Get-NetIPInterface, mayor es la prioridad. Las diferencias de este orden de un PC a otro se convierten en diferencias de resultado.²²

Si, en cambio, el lado doméstico devuelve una respuesta negativa, ese adaptador se quita de los candidatos y se usa la respuesta del lado de la VPN.⁵ Los productos VPN distribuyen la NRPT o «Desactivar la resolución de nombres inteligente con varios hosts» precisamente para controlar estas diferencias.

4.4 NRPT — Cambiar a dónde van las consultas por espacio de nombres

La NRPT (Name Resolution Policy Table, tabla de directivas de resolución de nombres) es una tabla que especifica, por espacio de nombres como .corp.contoso.com, qué servidores DNS usar y la configuración de DirectAccess y DNSSEC. Los perfiles de DirectAccess y Always On VPN escriben reglas en ella para producir un comportamiento como «enviar solo los nombres internos al DNS interno».²³⁶

Get-DnsClientNrptPolicy -Effective muestra las reglas realmente en vigor.

# Las reglas de la NRPT realmente en vigor
Get-DnsClientNrptPolicy -Effective

# Mostrar solo las reglas de un espacio de nombres concreto. -Namespace solo filtra por el atributo Namespace; no compara con un nombre.
# Pasar 'app01.corp.example.com' no devuelve la regla de sufijo de '.corp.example.com'.
# Para saber qué regla se aplica a un nombre, enumere las reglas y compárelas usted mismo, como en el paso 4 del capítulo 8
Get-DnsClientNrptPolicy -Effective -Namespace '.corp.example.com'

La NRPT se aplica solo a las aplicaciones que usan la API DNS de Windows. Las aplicaciones con su propia implementación DNS omiten esa ruta. La documentación del CSP VPNv2 cita nslookup como ejemplo y exige Resolve-DnsName para comprobar la NRPT. El resolvedor integrado del navegador y DoH también quedan fuera de la API DNS de Windows.⁶

5. Capa 3 — Las rutas de escape de los nombres de una sola etiqueta: LLMNR, NetBIOS y después mDNS

5.1 En qué se diferencian los tres protocolos

LLMNR y NetBIOS over TCP/IP (NetBT) son medios alternativos de resolver un nombre de una sola etiqueta como app01. De forma predeterminada se ejecutan en paralelo con DNS, y se puede adoptar una respuesta de vínculo local incluso cuando DNS devuelve una respuesta positiva. Solo pasan a ser secuenciales tras un fallo de DNS cuando se ha desactivado la resolución de nombres inteligente con varios hosts.⁴

mDNS es aparte de estos; es una ruta adicional para nombres .local. No es un cajón de sastre que entra en juego después de que haya fallado la resolución DNS de un nombre de una sola etiqueta.²⁴

Incluso con .local, no se salte la comprobación de DNS

.local no se convierte en solo mDNS. Si el dominio de Active Directory es algo como corp.local, ese nombre sigue resolviéndose también por los servidores DNS configurados y por la NRPT. RFC 6762 también permite la coexistencia con DNS de unidifusión. Al investigar nombres .local, compruebe también las directivas de DNS y de VPN.²⁴

NetBT depende de si existe WINS y del tipo de nodo

Sin WINS configurado el valor predeterminado es B-node; con un solo servidor WINS configurado, el valor predeterminado es H-node.²⁹ Las difusiones de LLMNR y NetBT no cruzan subredes, pero las consultas a WINS son de unidifusión y por tanto sí pueden.

nbtstat -c muestra la caché de nombres NetBIOS, y nbtstat -R vacía la caché y recarga LMHOSTS.³¹

5.2 Cuál tiene prioridad

Qué respuesta tiene prioridad después de las consultas en paralelo también lo rige una directiva.⁴

En redes domésticas o públicas, la respuesta de un dispositivo cercano con el mismo nombre puede tener prioridad sobre DNS. Aquí también importa leer la prioridad de las respuestas por separado de si las consultas son secuenciales o en paralelo.

5.3 La dirección de Microsoft: alinear en mDNS

En abril de 2022, Microsoft anunció la dirección de alinear en mDNS y reducir de forma gradual la resolución de nombres NetBIOS y LLMNR.²⁷ Protocolos antiguos e inseguros de descubrimiento de dispositivos como Computer Browser también han quedado en desuso.³² Los diseños que complementan los nombres de una sola etiqueta con multidifusión o difusión van de salida.

La información de Microsoft sobre la vulnerabilidad de LLMNR enumera, como soluciones alternativas, bloquear TCP/UDP 5355 y habilitar la Directiva de grupo «Desactivar la resolución de nombres de multidifusión». También indica que, como consecuencia, el equipo puede volverse invisible para otros equipos.²⁵ Habilitar esta directiva desactiva LLMNR en todos los adaptadores del cliente DNS.⁴

La decisión de desactivarlos es en sí correcta, pero hay que proporcionar en DNS un reemplazo de la ruta que desaparece. Para los dispositivos no registrados en DNS, registre sus registros A o habilite el registro dinámico a través de DHCP, y cambie los destinos a FQDN. Los dispositivos que admiten mDNS pueden usar nombres .local, pero el alcance queda limitado a donde pasa la multidifusión.

5.4 El caso típico de «solo algunos PC no conectan»: nombres de una sola etiqueta

Cuando un archivo de configuración o un acceso directo contiene \\fileserver01 o http://app01/, el mismo nombre produce las diferencias siguientes.

Lo que Resolve-DnsName app01 -LlmnrOnly le dice es «si se puede resolver a través de LLMNR». No le dice de dónde salió la respuesta adoptada en las consultas cotidianas. La comparación con el resultado sin modificadores, y las capturas, se hacen en el paso 5 del capítulo 8.⁸

La corrección de raíz son los FQDN y el registro en DNS

Cambie a FQDN los destinos que dependen de nombres de una sola etiqueta, y consolide la resolución de nombres en DNS.

SMB2 y posteriores se conectan directamente en TCP 445 y no usan sesiones NetBIOS.³³ Eso, no obstante, es un asunto de transporte. En la etapa de resolver el nombre de un destino como \\fileserver01\share, se puede usar LLMNR o NetBT. Especifique el FQDN, como en \\fileserver01.corp.example.com\share, para quitar la dependencia de la ruta del nombre de una sola etiqueta.

Algunas precauciones quedan incluso con FQDN. Un FQDN sin punto final también se prueba con sufijos si está habilitada la directiva que añade sufijos a nombres de varias etiquetas. Un nombre que termina en .local puede usar mDNS junto a DNS. La forma que fija el nombre de manera incondicional es el nombre absoluto con un punto final. La premisa para tratar en la práctica «un FQDN queda fijado a DNS» como cierto es que la directiva anterior esté deshabilitada y que el nombre de dominio interno no use .local.

6. El transporte hacia el servidor DNS — DoH no cambia el orden

6.1 DoH en Windows 11 / Windows Server 2022

El DoH de Windows es una característica que envía las consultas al servidor DNS por HTTPS. Se integra con hosts, la caché y la NRPT existentes, y con la configuración de resolvedor por adaptador y por perfil; no sustituye el orden descrito en los capítulos 3 y 4.⁹

El cliente DNS de Windows 11 admite DoH, y las versiones más nuevas también admiten DoT (DNS over TLS). La descripción de Microsoft, no obstante, no indica qué versiones admiten DoT, de modo que no está garantizado que esté disponible en todos los entornos que este artículo da por supuestos. Lo siguiente cubre DoH.⁹

Primero, compruebe la lista de servidores DoH conocidos

Salvo que DDR esté habilitado, solo se pueden usar servidores de la lista de servidores DoH conocidos. La lista predeterminada contiene Cloudflare, Google y Quad9, y se puede comprobar con Get-DnsClientDohServerAddress. Para un servidor DNS interno y similares, registre una plantilla DoH junto con la configuración de reserva y de actualización automática.¹³⁴

# La lista de servidores DoH conocidos
Get-DnsClientDohServerAddress

# Registrar el servidor DNS interno como servidor DoH (sin reserva a texto no cifrado, con actualización automática)
Add-DnsClientDohServerAddress -ServerAddress '10.0.1.2' `
    -DohTemplate 'https://dns.corp.example.com/dns-query' `
    -AllowFallbackToUdp $false -AutoUpgrade $true

El registro también es posible con netsh dnsclient add encryption. El netsh dnsclient set global doh=yes|no|auto global es una configuración aparte del autoupgrade por servidor.³⁵

auto por sí solo no prohíbe volver a texto no cifrado. Si se vuelve a UDP al fallar lo decide por separado el udpfallback por servidor, o -AllowFallbackToUdp en PowerShell. Para restringir la resolución solo al transporte cifrado, deshabilite también la reserva.³⁵

Con DDR habilitado, también hay una ruta de descubrimiento dinámico

En las versiones que admiten DDR (Discovery of Designated Resolvers), un resolvedor configurado en texto no cifrado puede anunciar sus puntos de conexión DNS cifrados. Como la conexión se puede actualizar a cifrado sin un registro en la lista estática, no se puede decir «no está en la lista, así que no es DoH».³⁵

Para que DDR funcione, hacen falta ambos: el netsh dnsclient set global ddr=yes global y el set interface <name> ddr=yes por adaptador. Si se vuelve a texto no cifrado cuando falla la resolución cifrada obtenida por DDR lo decide ddrfallback, que está deshabilitado de forma predeterminada.

En una investigación, además de la lista conocida, compruebe netsh dnsclient show global y netsh dnsclient show state, y los valores establecidos con set interface en los adaptadores que tienen servidores DNS. Los subcomandos show definidos en la documentación son encryption, global y state; no hay un subcomando show específico de adaptador.³⁵

Separe «Permitir», «Requerir» y volver a texto no cifrado

En la aplicación Configuración, ponga la configuración DNS en manual; «Cifrado DNS preferido» solo se puede elegir cuando el servidor DNS preferido está en la lista conocida. Hay tres opciones.¹

La Directiva de grupo «Configurar la resolución de nombres DNS sobre HTTPS (DoH)» tiene Permitir, Prohibir y Requerir. Con Permitir, se usa DoH cuando, además de un registro en la lista conocida, se cumplen condiciones como la actualización automática, la configuración de cifrado del adaptador o el doh=auto global. Con «Requerir», la resolución de nombres en sí falla frente a servidores que no admiten DoH.¹³⁵

No aplique «Requerir DoH» a PC unidos a un dominio. Microsoft avisa de esto de forma explícita. Active Directory Domain Services depende en gran medida de DNS, y el servicio Servidor DNS que se incluye con Windows Server no admite consultas DoH.¹

En una captura, lea la configuración y el tráfico real por separado

Las consultas enviadas realmente por DoH van dentro de TLS en el puerto 443, no en UDP 53. Incluso con «Permitir DoH», no obstante, las consultas a servidores que no están en la lista conocida, y las reservas tras un fallo de cifrado, circulan en texto no cifrado. Tener DoH configurado no hace desaparecer el tráfico del puerto 53.

Si no se ven consultas DNS, compruebe DoH y DoT (puerto 853) además de hosts y la caché. Para cómo capturar, vea el artículo de captura de paquetes.

6.2 El DoH del navegador es aparte del sistema operativo

El cliente DNS integrado de Edge y el cambio de destino de consulta a través de DNS seguro se entienden mejor al partirlos en dos etapas.

El cliente integrado lo controla BuiltInDnsClientEnabled, y las consultas DoH las hace siempre el resolvedor integrado.⁷ DNS seguro está deshabilitado de forma predeterminada en los PC administrados por la organización y se configura con DnsOverHttpsMode (off / automatic / secure) y DnsOverHttpsTemplates.³⁶³⁷

Un Edge que tiene elegido otro proveedor puede resolver sitios externos pero fallar al resolver nombres que solo conoce el DNS interno. A la inversa, Edge solo puede seguir abriendo páginas cuando el DNS del sistema operativo no funciona bien. Si se queda con el proveedor actual, el destino de la consulta no cambia.

La conclusión es: no trate el éxito del navegador y el éxito de la aplicación empresarial como prueba sobre la misma ruta. Compruebe la ruta del sistema operativo con Resolve-DnsName o ping.

7. ¿Qué ruta toma la aplicación?

Antes de elegir las herramientas de una investigación, alinee la ruta que está mirando.

Los modificadores principales de Resolve-DnsName, organizados por propósito de investigación, son los siguientes.⁸

7.1 A y AAAA: IPv6 vuelve primero

Aunque la resolución de nombres tenga éxito, la selección de dirección que sigue puede hacer lenta la conexión.

El cliente DNS consulta tanto A (IPv4) como AAAA (IPv6). En una captura, también, ambas consultas aparecen como un par.³ Después de que vuelven las respuestas, getaddrinfo y la pila de conexión eligen la dirección que se usará. Windows Vista y posteriores usan la tabla de prefijos de RFC 3484 y, de forma predeterminada, prefieren IPv6 de unidifusión global frente a IPv4.³⁸

Sin embargo, una respuesta AAAA sola no significa que siempre se intente una conexión IPv6. La selección de destino descarta primero los destinos inutilizables, como los que no tienen dirección de origen IPv6 ni ruta, y después ordena los candidatos.³⁹

El problema surge en entornos donde parece existir una dirección de origen IPv6 y una ruta, pero en realidad no funcionan. La resolución de nombres tiene éxito, y aun así se pierde tiempo en la conexión. Si realmente se intentó IPv6 se confirma no solo a partir de la respuesta DNS, sino a partir de los registros de conexión o de una captura.

Microsoft no recomienda desactivar IPv6 como remedio, porque algunos componentes de Windows dejan de funcionar. En su lugar, describe establecer DisabledComponents en 0x20 para preferir IPv4 en la directiva de prefijos.³⁸ El caso en que localhost se resuelve a ::1 y entra en conflicto con una investigación que daba por supuesto 127.0.0.1 también se cubre en el artículo de captura de paquetes.

8. El procedimiento de aislamiento — quite las capas de arriba abajo

En el PC que falla, ejecute lo siguiente en orden. Cada comando existe para restringir la ruta, y su éxito solo no prueba la ruta tomada en la resolución cotidiana. Combine la comparación de resultados con la captura del final.

Paso 1: Compruebe la forma del nombre

Compruebe, en un registro o en un archivo de configuración, el nombre que la aplicación pasa realmente. La ruta cambia según sea un nombre de una sola etiqueta, termine en .local o tenga un punto final. Para un nombre corto como http://app01/, empiece por cómo se completa en la sección 4.1 y por las diferencias por PC de la sección 5.4.

Paso 2: ¿Se puede resolver solo desde la caché y hosts?

Resolve-DnsName -Name 'app01.corp.example.com' -CacheOnly
Get-DnsClientCache -Entry 'app01.corp.example.com'
Get-Content "$env:SystemRoot\System32\drivers\etc\hosts" | Select-String -Pattern 'app01'

-CacheOnly solo restringe esta consulta a la caché local. Si se aprendió una respuesta incorrecta del servidor DNS, el mismo valor vuelve después de borrar. El hecho de que estuviera en la caché no prueba que el servidor DNS no tenga que ver.⁸

Paso 3: ¿Se puede resolver solo a través de DNS?

# Excluir hosts, no enviar LLMNR/NetBIOS y consultar solo los servidores DNS configurados
Resolve-DnsName -Name 'app01.corp.example.com' -NoHostsFile -DnsOnly

Si el paso 2 no tenía respuesta y este paso simplemente tiene éxito, suele ser un fallo de caché ordinario. Solo puede llamarlo un problema de caché o de hosts cuando el paso 2 mostró una respuesta obsoleta, una respuesta incorrecta o una entrada de caché negativa.

Si este paso también falla, investigue la ruta hacia el servidor DNS, el lado del servidor y las directivas del lado del cliente. Antes de pasar al paso 4, compruebe lo siguiente.

• Get-DnsClientNrptPolicy -Effective: ¿hay una regla que dirige el nombre a otro servidor DNS?
• Get-DnsClientDohServerAddress y la Directiva de grupo de DoH: ¿está «Requerir DoH» establecido frente a un servidor que no lo admite?

Si hay una NRPT, los servidores de destino del paso 4 cambian. Si «Requerir DoH» es la causa, solo falla la resolución de nombres mientras la ruta y el servidor están ambos sanos. Termine primero las comprobaciones de las secciones 4.4 y 6.1.

Paso 4: Pregunte a cada servidor de forma directa

Recoja los servidores DNS de los adaptadores conectados y, si una regla NRPT se aplica al nombre de destino, sustitúyalos por los servidores de esa regla. Incluya también los servidores DNS configurados solo para IPv6.

$name = 'app01.corp.example.com'
# Recoger los servidores DNS de las interfaces conectadas, tanto IPv4 como IPv6.
# Los servidores que quedan en la configuración de una VPN o un conmutador virtual desconectados no forman parte de la ruta de resolución actual, así que exclúyalos (no pase por alto los servidores configurados solo para IPv6)
$connected = @((Get-NetIPInterface -ConnectionState Connected).ifIndex | Select-Object -Unique)
$servers = @((Get-DnsClientServerAddress |
    Where-Object { $_.ServerAddresses -and ($connected -contains $_.InterfaceIndex) }).ServerAddresses)
# Los servidores de la regla NRPT que se aplica a este nombre (escritos por Always On VPN o DirectAccess) no aparecen en la configuración del adaptador, así que tómelos de la directiva efectiva.
# El parámetro -Namespace de Get-DnsClientNrptPolicy solo filtra por el atributo Namespace de la regla; no compara con el nombre.
# Así que compare usted mismo la regla Any (.), las reglas de sufijo (punto inicial; se aplican al propio espacio de nombres y a los dominios secundarios), las reglas FQDN y las reglas de prefijo (la parte del nombre de host; se permiten caracteres comodín como web*),
# y adopte la regla más específica (más larga). La regla Any es la más corta, así que solo se elige cuando no coincide ninguna otra regla
# Namespace es un conjunto de cadenas (se muestra como Namespace : {.corp.example.com}), así que expanda los elementos de cada regla para comparar y ordene por la longitud del espacio de nombres coincidente
# En un nombre absoluto con punto final (app01.corp.example.com.), quite el punto solo para comparar. Pase el $name original a Resolve-DnsName
$matchName = $name.TrimEnd('.')
$label = $matchName.Split('.')[0]
$matched = foreach ($policy in @(Get-DnsClientNrptPolicy -Effective)) {
    foreach ($ns in @($policy.Namespace)) {
        if (-not $ns) { continue }
        $hit = if ($ns -eq '.') { $true }
               elseif ($ns.StartsWith('.')) { $matchName.Equals($ns.TrimStart('.'), [System.StringComparison]::OrdinalIgnoreCase) -or $matchName.EndsWith($ns, [System.StringComparison]::OrdinalIgnoreCase) }
               elseif ($ns.Contains('.')) { $matchName.Equals($ns, [System.StringComparison]::OrdinalIgnoreCase) }
               else { $label -like $ns }
        if ($hit) { [pscustomobject]@{ Namespace = $ns; Policy = $policy } }
    }
}
$rule = $matched | Sort-Object { $_.Namespace.Length } -Descending | Select-Object -First 1
$policyServers = @()
if ($rule) { $policyServers = @(@($rule.Policy.NameServers) + @($rule.Policy.DirectAccessDnsServers) | Where-Object { $_ }) }
if ($policyServers.Count -gt 0) {
    # Si la NRPT especifica servidores para este espacio de nombres, la consulta del paso 3 va a esos servidores. Los servidores del adaptador quedan fuera de la ruta, así que sustitúyalos
    $servers = $policyServers
}
$servers = $servers | Where-Object { $_ } | Select-Object -Unique
foreach ($server in $servers) {
    $sw = [System.Diagnostics.Stopwatch]::StartNew()
    try {
        $r = Resolve-DnsName -Name $name -Server $server -DnsOnly -ErrorAction Stop
        $status = 'OK'
        # Pueden volver varios registros en un orden distinto por respuesta, así que ordénelos antes de comparar
        $answer = ($r.IPAddress | Sort-Object) -join ','
    } catch {
        # Las respuestas negativas (el nombre no existe), SERVFAIL y los tiempos de espera caen aquí. Conserve el motivo en lugar de descartarlo
        $status = $_.Exception.Message
        $answer = ''
    }
    [pscustomobject]@{ Server = $server; Status = $status; Answer = $answer; Milliseconds = [int]$sw.ElapsedMilliseconds }
}

Primero, alinee los servidores que va a comparar

NameServers y DirectAccessDnsServers de la NRPT pueden no aparecer en la configuración DNS del adaptador. Si el paso 3 preguntó a los servidores de la NRPT pero el paso 4 examina solo los servidores del adaptador, acaba comparando rutas distintas.

La NRPT tiene tipos de regla como sufijo, FQDN, prefijo y Any (.), y las reglas más específicas tienen prioridad.⁴⁰ -Namespace solo filtra por el atributo de la regla; no compara con el nombre de host. Por eso el código anterior expande los espacios de nombres de las reglas y los compara con el nombre de destino.²³

En una VPN de DNS dividido, es normal que el resolvedor del lado doméstico devuelva una respuesta negativa para un nombre interno mientras solo el lado de la NRPT devuelve una positiva. Si también compara servidores fuera de la ruta, anótelos por separado como «control» y no los mezcle en el juicio de discrepancias de zona. Los tiempos de espera frente a servidores que quedan en adaptadores desconectados son, del mismo modo, aparte de los retrasos en la ruta de resolución actual.

Después, lea los resultados por separado

Si también difieren como conjuntos, compruebe el contenido de la zona y los números de serie. Además, esta es una medición con el destino fijado por -Server. El retraso causado por la posición en la lista, «4 segundos hasta alcanzar los servidores a partir del cuarto» de la sección 4.2, se comprueba en el paso 3 o en su captura.

Paso 5: Compruebe la capa de vínculo local

Resolve-DnsName -Name 'app01' -LlmnrOnly          # solo LLMNR
Resolve-DnsName -Name 'app01' -LlmnrNetbiosOnly   # solo LLMNR o NetBIOS (sin DNS)
nbtstat -c                                        # caché de nombres NetBIOS

Esta comprobación apunta a nombres de una sola etiqueta. -NetbiosFallback recurre a NetBIOS solo cuando DNS falla, de modo que para un nombre que DNS puede resolver no es una comprobación de NetBIOS.⁸

Lea los resultados así.

Qué protocolo respondió se distingue en una captura por UDP 5355 (LLMNR) frente a UDP 137 (NetBT). Para confirmar la ruta de resolución cotidiana, compare también con la dirección que devuelve Resolve-DnsName sin modificadores y, si discrepan, compruebe la respuesta adoptada en la captura, porque de forma predeterminada DNS también se consulta en paralelo.

Paso 6: Compare los volcados de configuración

En una investigación de «solo algunos PC», ejecute el mismo script en un PC que funciona y en uno que falla, y compare.

# name-resolution-dump.ps1 -- ejecutar con derechos de administrador y comparar los archivos de salida de las dos máquinas uno al lado del otro
$out = "$env:COMPUTERNAME-name-resolution.txt"
$sections = [ordered]@{
    'Get-DnsClientServerAddress' = { Get-DnsClientServerAddress | Format-Table -AutoSize | Out-String -Width 200 }
    'Get-DnsClientGlobalSetting' = { Get-DnsClientGlobalSetting | Format-List | Out-String }
    'Get-DnsClient'              = { Get-DnsClient | Format-Table InterfaceAlias, ConnectionSpecificSuffix, UseSuffixWhenRegistering -AutoSize | Out-String -Width 200 }
    'Get-DnsClientNrptPolicy'    = { Get-DnsClientNrptPolicy -Effective | Format-List | Out-String }
    'Get-DnsClientDohServerAddress' = { Get-DnsClientDohServerAddress | Format-Table -AutoSize | Out-String -Width 200 }
    'netsh dnsclient show state' = { netsh dnsclient show state 2>&1 | Out-String }
    'Get-NetIPInterface'         = { Get-NetIPInterface | Sort-Object AddressFamily, InterfaceMetric | Format-Table InterfaceAlias, AddressFamily, InterfaceMetric, ConnectionState, Dhcp -AutoSize | Out-String -Width 200 }
    'DNSClient policy registry'  = { Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient' -ErrorAction SilentlyContinue | Format-List | Out-String }
    'ipconfig /all'              = { ipconfig /all | Out-String }
}
$sections.GetEnumerator() | ForEach-Object {
    "===== $($_.Key) ====="
    try { & $_.Value } catch { "ERROR: $($_.Exception.Message)" }  # Dejar los elementos que faltan (como DoH en Windows 10) registrados como errores
} | Set-Content -Path $out -Encoding UTF8
Write-Host "wrote $out"

Lo que hay que comparar es el orden de los servidores DNS, la lista de búsqueda, los sufijos específicos de la conexión, la NRPT, DoH, las métricas de interfaz y los valores de directiva.

HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient guarda EnableMulticast de «Desactivar la resolución de nombres de multidifusión», DisableSmartNameResolution de «Desactivar la resolución de nombres inteligente con varios hosts», la lista de búsqueda, el sufijo primario, etc.⁴ Compruebe la diferencia frente al funcionamiento de cada capa organizado hasta aquí.

Paso 7: Apóyelo con una captura de paquetes

El procedimiento de recogida de datos de Microsoft inicia netsh trace start capture=yes tanto en el cliente como en el servidor, descarta la caché con ipconfig /flushdns, reproduce el problema y detiene con netsh trace stop.⁴¹

En Wireshark, filtre con dns.qry.name == "app01.corp.example.com" o dns.qry.name contains "app01" para ver a qué servidor se preguntó qué, y qué volvió.

Si el firewall del lado emisor bloquea UDP 53, Resolve-DnsName agota el tiempo de espera y en la captura tampoco aparece ninguna consulta DNS. Aísle no solo el caso en que la resolución de nombres tiene éxito y no sale tráfico, sino también el caso en que falla y no sale tráfico.³

Más allá de DNS, compruebe 5355 para LLMNR, UDP 5353 para mDNS y UDP 137 para el servicio de nombres NetBT. DoH es 443 y DoT es 853. Cómo capturar y leer capturas está reunido en el artículo de captura de paquetes.

9. Diseño en el lado de la aplicación empresarial — hacerla robusta frente a la resolución de nombres

Para aligerar las investigaciones, importa que el lado de la aplicación pueda registrar «qué nombre, resuelto a qué, y dónde falló». Contrastar el registro de la aplicación con los volcados de configuración y las capturas que recoge el personal de TI facilita decidir por dónde empezar en el capítulo 8.

Conserve los destinos como FQDN y no dependa de hosts

Haga que los valores predeterminados de los archivos de configuración, los accesos directos y las rutas UNC sean FQDN. Así se quita la dependencia de completar con sufijos los nombres de una sola etiqueta y de LLMNR y NetBT. Quedan, no obstante, las precauciones de la sección 5.4: mDNS junto a DNS en nombres .local, y la directiva que añade sufijos a nombres sin punto final.

hosts es cómodo para una sobrescritura temporal durante el desarrollo, pero requiere derechos de administrador y trabajo manual. La distribución y el historial de cambios son difíciles de gestionar, y algunos resolvedores no lo consultan en absoluto (nslookup no lo hace¹²). Cambie los destinos a través de archivos de configuración.

Registre el resultado, el tiempo y el motivo de fallo de la resolución de nombres

En el arranque y puntos similares, registre las direcciones IPv4 e IPv6 y el tiempo transcurrido de los destinos principales. Como Dns.GetHostAddresses devuelve el mismo resultado que getaddrinfo, puede rastrear «en qué PC, desde cuándo, a qué se resolvió».¹¹

// Registrar los resultados de la resolución de nombres de los destinos principales al arrancar (.NET 6 o posterior)
static async Task LogNameResolutionAsync(ILogger logger, string host)
{
    var sw = System.Diagnostics.Stopwatch.StartNew();
    try
    {
        var addresses = await System.Net.Dns.GetHostAddressesAsync(host);
        logger.LogInformation("Resolución de nombres {Host} -> {Addresses} ({Elapsed} ms)",
            host, string.Join(",", addresses.Select(a => a.ToString())), sw.ElapsedMilliseconds);
    }
    catch (System.Net.Sockets.SocketException ex)
    {
        logger.LogError(ex, "Error en la resolución de nombres {Host} código {Code} ({Elapsed} ms)",
            host, ex.SocketErrorCode, sw.ElapsedMilliseconds);
        throw;
    }
}

Registre los fallos y vuelva a iniciar la excepción. Cambiar en silencio a otro nombre o a una IP fija hace que la ruta real sea incognoscible durante una investigación. Con el código de error y el tiempo transcurrido, el personal de TI puede decidir por dónde empezar en los pasos 2 a 4.

Prevea tiempos de espera y respuestas IPv6

El cliente DNS gasta hasta 10 segundos por candidato consultado frente a servidores que no responden.²¹ Si la búsqueda de sufijos produce varios candidatos, el total puede superar los 10 segundos.

Si el tiempo de espera de la conexión se aprieta a 2 o 3 segundos, la resolución de nombres no termina antes del plazo en configuraciones como aquella en la que el servidor que puede responder es el cuarto o posterior. El segundo servidor, no obstante, se consulta al cabo de 1 segundo y el tercero al cabo de 2 segundos, de modo que un solo servidor fallido no implica necesariamente el fallo. Diseñe con el momento de retransmisión de la sección 4.2 en mente.

Además, cuando vuelve una respuesta AAAA y existen una dirección de origen IPv6 y una ruta, Windows prefiere IPv6 de forma predeterminada.³⁸ Un código de conexión que da por supuesto solo IPv4 puede no conectar aunque la resolución de nombres haya tenido éxito. Separe el éxito de la resolución de nombres del éxito de la conexión, y gestione ambos tipos de dirección.

10. Resumen

Lo primero que hay que separar en la resolución de nombres de Windows es la forma del nombre, la capa que devuelve la respuesta y la ruta que toma la aplicación.

La caché y hosts responden primero, y en nombres de una sola etiqueta DNS y LLMNR/NetBT se ejecutan en paralelo de forma predeterminada. En .local, se suma mDNS. Una vez que la resolución pasa a DNS, los sufijos, el momento de retransmisión, varias NIC y la NRPT cambian el resultado. DoH es una característica que cambia ese transporte, y se considera por separado del resolvedor integrado del navegador.

La investigación restringe la ruta en el orden -CacheOnly, después -NoHostsFile -DnsOnly, después -Server, después -LlmnrOnly, y confirma con una comparación de configuración y una captura. Lo que importa es no pasar por alto la caché negativa, la diferencia entre ninguna respuesta y una respuesta negativa, y las directivas del lado del cliente.

Cuando «solo este PC no conecta», compruebe primero estas dos cosas.

¿En qué forma se está pasando el nombre? En ese PC, ¿qué ruta está respondiendo?

Con estas dos establecidas, puede acotar dónde mirar.

Artículos relacionados

• Captura de paquetes en Windows en la práctica — pktmon, netsh trace y Wireshark: cuándo usar cada uno
• Proxy interno de la empresa y aplicaciones de Windows — cómo se resuelve el proxy en WinINET, WinHTTP y .NET
• No envuelvas HttpClient en un using ── Comunicación HTTP en aplicaciones de negocio C# (patrones de creación, tiempos de espera y reintentos)
• El firewall de Windows y las aplicaciones empresariales — Registre las reglas de entrada con el instalador
• Trampas de las unidades de red y las rutas UNC — la gestión práctica de servidores de archivos (carpetas compartidas) en aplicaciones empresariales
• NTLM y Kerberos explicados con diagramas — por qué la autenticación «cae» a NTLM
• Colección práctica de comandos de PowerShell ── Amplíe las pequeñas funciones que usa a diario

Ámbitos de consultoría relacionados

KomuraSoft LLC se ocupa de investigaciones de causa raíz de problemas de comunicación relacionados con la resolución de nombres como «la aplicación empresarial no alcanza el servidor interno solo en algunos PC» y «se abre en el navegador pero la aplicación falla en la resolución de nombres», de revisiones de diseño sobre si una aplicación empresarial resiste cambios de entorno como la desactivación de LLMNR, DoH y VPN, y de la implementación de una capa de comunicación que registra los resultados de la resolución de nombres y los tiempos de espera. Si adjunta volcados de configuración de un PC que funciona y de uno que falla al contactarnos, el punto de partida de la investigación queda fijado con rapidez.

• Investigación de errores y análisis de causa raíz
• Consultoría técnica y revisión de diseño
• Desarrollo de aplicaciones para Windows
• Contacto

Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

He editado el archivo hosts, pero el cambio no surte efecto. ¿Por qué?

En Windows, el contenido del archivo hosts se carga en la caché al iniciar el servicio Cliente DNS, y la resolución de nombres avanza en el orden caché, hosts, servidor DNS. Cuando un cambio no surte efecto, compruebe primero la entrada de ese nombre con ipconfig /displaydns y, si sigue ahí una respuesta antigua, descártela con ipconfig /flushdns. A continuación, ponga en duda si la herramienta con la que está comprobando pasa siquiera por el resolvedor de Windows. nslookup no usa el resolvedor del sistema operativo; omite la caché, hosts y la NRPT y consulta el servidor DNS directamente, de modo que nada de hosts se refleja en su salida. Para ver el resultado real de la resolución, incluido hosts, use Resolve-DnsName o ping. Si aun así no surte efecto, compruebe si la aplicación, como un navegador, tiene su propio resolvedor o DoH.

El sitio se abre en el navegador, pero solo la aplicación empresarial falla en la resolución de nombres.

Lo más probable es que el navegador y la aplicación resuelvan el nombre por rutas distintas. De forma predeterminada, Microsoft Edge habla con el servidor DNS con su cliente DNS integrado, no con el cliente DNS del sistema operativo, y si en DNS seguro (DoH) se elige otro proveedor, consulta un resolvedor externo. En cambio, Dns.GetHostAddresses de .NET, y un HttpClient que se conecta directamente al destino, pasan por getaddrinfo del sistema operativo, así que quedan sujetos a hosts, la caché DNS, la NRPT y la lista de búsqueda de sufijos DNS (en las solicitudes que pasan por un proxy HTTP, el nombre de destino se resuelve en el lado del proxy). Cuando ambos devuelven respuestas distintas, la vía más rápida es confrontar qué ruta preguntó qué a qué servidor DNS, con Resolve-DnsName y una captura de paquetes.

La configuración debería ser idéntica, y aun así solo algunos PC no alcanzan el servidor interno. ¿Qué hay que comparar?

Compare la forma del nombre y la capa en la que cada PC obtiene su respuesta. Un nombre de una sola etiqueta (un nombre sin punto, como server01) se completa con la lista de búsqueda de sufijos DNS del PC o el sufijo específico de la conexión y se envía a DNS, y de forma predeterminada también se envía, en paralelo, a mecanismos limitados a la misma subred como LLMNR y la difusión NetBIOS (solo se prueban en secuencia después de que DNS falle cuando se ha desactivado la optimización; si WINS está configurado, NetBIOS usa unidifusión y puede cruzar subredes). Un PC unido a un dominio puede resolver el nombre porque el sufijo lo completa hasta un FQDN, mientras que un PC en VPN o en otra subred, o un PC con LLMNR y NetBIOS desactivados, no puede resolver el mismo nombre. El método fiable es recoger la salida de Get-DnsClientServerAddress, Get-DnsClientGlobalSetting, Get-DnsClient y Get-DnsClientNrptPolicy -Effective en un PC que funciona y en uno que falla, y compararlas. La corrección de raíz es que los destinos de los archivos de configuración y de los accesos directos sean FQDN.

La resolución de nombres no falla; solo tarda varios segundos hasta que la conexión acaba por pasar. ¿Qué lo causa?

Es el mecanismo de tiempo de espera y reintento del cliente DNS asomando. Frente a un servidor DNS que no responde, Windows retransmite a los 1, 2, 4 y 8 segundos desde el inicio y abandona a los 10 segundos. Aunque haya varios servidores DNS configurados, si el que responde es el cuarto o posterior de la lista, Windows espera al menos 4 segundos antes de consultar ese servidor. Una lista de búsqueda de sufijos DNS larga también acumula retraso, porque un nombre de una sola etiqueta se prueba con cada sufijo por turno. Mida cuánto tarda Resolve-DnsName con Measure-Command y aplique un filtro dns.qry.name en Wireshark para ver las consultas de qué servidor quedan sin respuesta.

Desactivamos LLMNR y NetBIOS como medida de seguridad, y ahora algunos dispositivos ya no se alcanzan por nombre.

Es un efecto secundario esperado. LLMNR y NetBIOS over TCP/IP son medios secundarios para resolver los nombres de una sola etiqueta de dispositivos no registrados en DNS dentro de la misma subred, y desactivarlos elimina esa ruta. El propio Microsoft anunció en 2022 la dirección de alinear en mDNS y reducir de forma gradual la resolución de nombres NetBIOS y LLMNR, de modo que la decisión de desactivarlos es en sí la correcta. El remedio es consolidar la resolución de nombres en DNS: registrar los registros A de los dispositivos en el DNS interno, o habilitar el registro dinámico a través de DHCP, y reescribir los destinos de las aplicaciones y de los recursos compartidos a FQDN. Los dispositivos que admiten mDNS se pueden resolver por sus nombres .local, pero esa ruta también queda limitada al alcance de la multidifusión.

¿Qué ocurre con la resolución de nombres interna al habilitar DoH (DNS over HTTPS) en Windows 11?

DoH es una característica que cambia el transporte a HTTPS cuando el cliente DNS consulta los servidores DNS configurados; el orden existente de hosts, caché y NRPT se mantiene. Salvo que DDR (Discovery of Designated Resolvers) esté habilitado, DoH solo se puede usar cuando el servidor está en la lista de servidores DoH conocidos, así que si quiere usar un servidor DNS interno, un administrador debe registrarlo con Add-DnsClientDohServerAddress. Si la Directiva de grupo «Configurar la resolución de nombres DNS sobre HTTPS (DoH)» se establece en «Requerir DoH», la resolución de nombres en sí falla frente a servidores que no admiten DoH. Microsoft indica de forma explícita que no se habilite esta configuración en PC unidos a un dominio, porque el servicio Servidor DNS que se incluye con Windows Server, del que depende Active Directory, no admite consultas DoH.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.