Examinar el comportamiento de las consultas DNS y la resolución de nombres de dominio
Contenido
Introducción
Este documento describe cómo los sistemas operativos cliente manejan las consultas DNS y los efectos en la resolución de nombres de dominio usando Cisco IOS® Secure Client.
Prerequisites
Requirements
No hay requisitos específicos para este documento.
Componentes Utilizados
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware. Los ejemplos de laboratorio utilizan las políticas de grupo de ASA/FTD de Secure Firewall y Cisco Secure Client en Windows, macOS, Linux y Apple iOS.
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
DNS dividido frente a DNS estándar
Este documento explica cómo los sistemas operativos cliente manejan las consultas DNS y los efectos en la resolución de nombres de dominio cuando se utiliza Cisco Secure Client (anteriormente Cisco AnyConnect) con tunelización dividida o completa. Entre las cabeceras de VPN analizadas se incluyen Cisco Secure Firewall ASA y FTD (anteriormente ASA); la configuración de la política de grupo como split-dns, dns-server y split-tunnel-all-dns se aplica a ambos, a menos que se indique lo contrario.
Si una sección hace referencia explícitamente a versiones de cliente anteriores, se aplica el comportamiento descrito para Secure Client 4.2 y versiones posteriores (incluidas las versiones actuales de Secure Client 5.x). Cisco AnyConnect 4.x ha alcanzado el fin de su vida útil; migre a Cisco Secure Client para obtener las funciones de tunelación y DNS compatibles.
El comportamiento de la resolución DNS depende de tres factores:
- Política de DNS de VPN: Configurado en la cabecera (DNS dividido, DNS completo de túnel o DNS estándar)
- Modo de tunelización dividida: Tunnel-all, split-include o split-exclude
- Sistema operativo del cliente: Arquitectura de resolución de DNS (por interfaz frente a global)
Cuando ejecuta el comando de tunelización split-include, estas son las tres opciones de DNS disponibles en la política de grupo:
| Modo |
Descripción |
|---|---|
| DNS dividido | Las consultas DNS que coinciden con los nombres de dominio configurados en la cabecera (split-dns) se envían a través del túnel a los servidores DNS VPN (dns-server). Todas las demás consultas utilizan los servidores DNS de resolución del sistema operativo del cliente y del adaptador físico. |
| Tunnel-all-DNS | Solo se permite el tráfico DNS a los servidores DNS definidos por la cabecera. Configurado con split-tunnel-all-dns enable en la política de grupo. |
| DNS estándar | Todas las consultas DNS se envían primero a los servidores DNS VPN definidos por la cabecera. En una respuesta negativa (NXDOMAIN o sin respuesta), la resolución también puede probar los servidores DNS en el adaptador físico. |
Nota: El comando split-tunnel-all-dns se implementó por primera vez en ASA versión 8.2(5). Antes de esa versión, solo estaba disponible el DNS dividido o el DNS estándar. En todos los casos, las consultas DNS definidas para moverse a través del túnel pasan a cualquier servidor DNS definido por la cabecera. Si no se ha definido ningún servidor DNS en la cabecera, los parámetros DNS del túnel estarán en blanco.
Si no se definen los DNS divididos, todas las consultas DNS se envían a los servidores DNS definidos por la cabecera (sujeto al comportamiento específico del sistema operativo que se describe más adelante en este documento). Sin embargo, los comportamientos descritos en este documento pueden diferir en función del sistema operativo (SO).
Prueba de DNS: importante
Nota: Evite utilizar NSLookup o dig cuando pruebe la resolución de nombres en el cliente. En su lugar, utilice un navegador web o ejecute el comando ping. NSLookup y dig no utilizan el código auxiliar de resolución DNS del sistema operativo de la misma manera que la mayoría de las aplicaciones. Secure Client no fuerza cada solicitud DNS a través de una interfaz específica; permite o rechaza solicitudes basadas en la política split DNS y tunnel-all-DNS.
Para observar un comportamiento de conmutación por error correcto, realice pruebas sólo con aplicaciones que dependan de la resolución de DNS del sistema operativo nativo (navegadores, ping y la mayoría de las aplicaciones empresariales). Las herramientas que realizan su propia resolución DNS (NSLookup, dig y algunas aplicaciones personalizadas) pueden mostrar errores engañosos incluso cuando el cliente funciona correctamente.
DNS dividido Verdadero frente a Mejor Esfuerzo
La versión 2.4 de AnyConnect introdujo la reserva de DNS dividido (DNS dividido de mejor esfuerzo), que no es un DNS dividido verdadero y también se encontró en el cliente IPsec heredado.
Comportamiento de mejor esfuerzo (repliegue):
- Si la solicitud coincide con un dominio DNS dividido, Secure Client permite que la solicitud sea tunelizada a la cabecera.
- Si el servidor DNS VPN no puede resolver el nombre de host, la resolución DNS del sistema operativo continúa y puede enviar la misma consulta a un servidor DNS en la interfaz física.
- Si la solicitud no coincide con ningún dominio DNS dividido, Secure Client no lo tuneliza. Puede sintetizar una respuesta para que la resolución recurra a los servidores DNS de la interfaz física.
Esta es la razón por la que la función heredada se denomina reserva de DNS para la tunelización dividida, que no es un verdadero DNS dividido. Secure Client garantiza que sólo las consultas de dominio DNS dividido coincidentes entren en el túnel, pero sigue dependiendo del comportamiento de resolución del sistema operativo para la resolución final.
Problema de seguridad: Un nombre de dominio privado puede filtrarse a un servidor DNS público cuando el servidor DNS VPN devuelve NXDOMAIN o no se puede resolver; y la resolución vuelve a intentarlo en el adaptador físico.
DNS dividido verdadero: ID de bug de Cisco CSCtn14578
Resuelto en Microsoft Windows en AnyConnect 3.0(4235) y conservado en Secure Client 4.2+):
- Las consultas para dominios split-DNS configurados solo se permiten a través de la ruta VPN (servidores DNS de túnel/adaptador VPN, dependiendo de la plataforma y la versión).
- El resto de las consultas se permiten sólo a través de servidores DNS que no sean VPN (adaptador físico).
Nota: Solo los usuarios registrados de Cisco tienen acceso a las herramientas de errores internas de Cisco y a la información detallada de errores.
Tunnel-all y Tunnel-all DNS
Cuando se inhabilita la tunelización dividida (configuración tunnel-all), el tráfico DNS se permite estrictamente a través del túnel.
La configuración tunnel-all-DNS (split-tunnel-all-dns enable en la política de grupo) envía todas las búsquedas de DNS a través del túnel, mientras que también se configura algún tipo de tunelización dividida, y el tráfico DNS se permite estrictamente a través de la interfaz de túnel.
Esto es coherente en todas las plataformas con una advertencia en Microsoft Windows: cuando se configura tunnel-all o tunnel-all-DNS, Secure Client permite el tráfico DNS estrictamente a los servidores DNS configurados en el gateway seguro (aplicado al adaptador VPN). Esta mejora de la seguridad se implementó con un verdadero DNS dividido. Si esto es problemático (por ejemplo, la actualización/registro de DNS debe alcanzar servidores DNS no VPN), complete estos pasos:
- Si la configuración actual es tunnel-all, habilite la tunelización split-exclude. Cualquier red de exclusión dividida de un solo host es aceptable, como una dirección local de link.
- Asegúrese de que tunnel-all-DNS no esté habilitado en la política de grupo (split-tunnel-all-dns disable).
Módulo Tunnel-all-DNS y Cisco Secure Client Umbrella
Cuando se habilitan split tunneling y tunnel-all-DNS, el DNS se intercepta en el núcleo y se bloquea si no sale de la interfaz VPN correcta. El módulo Secure Client Umbrella (anteriormente conocido como AnyConnect Roaming Security) puede verse afectado en redes en las que el DNS cifrado no está disponible. Esto se debe a que el módulo puede intentar utilizar DNS estándar a través de la interfaz LAN mientras tunnel-all-DNS requiere DNS a través de VPN.
De forma predeterminada, el módulo Umbrella utiliza DNS cifrado (puerto UDP 443), que generalmente no está bloqueado por tunnel-all-DNS. El problema aparece principalmente cuando el cifrado no está disponible y se utiliza DNS sin formato.
Recomendación: Agregue las direcciones de resolución de Cisco Umbrella a la lista de split-include si utiliza tunnel-all-DNS con el módulo Umbrella. O consulte el documento Habilitación de DNS de Todo el Túnel para Secure Client con Umbrella Module (ID del documento: 224809.)
Problema de rendimiento de DNS resuelto en AnyConnect versión 3.0 (4235)
Este problema de Microsoft Windows es más frecuente en estas condiciones:
- Configuración del router doméstico donde los servidores DNS y DHCP comparten la misma dirección IP (Secure Client crea una ruta necesaria al servidor DHCP).
- Un gran número de sufijos/dominios DNS en la directiva de grupo.
- Una configuración tunnel-all.
- La resolución de nombres utiliza un nombre de host no calificado, por lo que el solucionador intenta utilizar varios sufijos DNS en todos los servidores DNS disponibles.
- El cliente DNS nativo intenta enviar consultas DNS a través del adaptador físico, que Secure Client bloquea en tunnel-all.
Esto puede causar retrasos significativos en la resolución de nombres, especialmente cuando la cabecera envía muchos sufijos DNS. La resolución debe recorrer los sufijos y los servidores hasta que reciba una respuesta positiva.
Este problema se resuelve en AnyConnect 3.0(4235) y versiones posteriores de Secure Client. Consulte Cisco bug ID CSCtq02141 y Cisco bug ID CSCtn14578 para obtener detalles.
Nota: Solo los usuarios registrados de Cisco tienen acceso a las herramientas de errores internas de Cisco.
Soluciones alternativas (si no es posible realizar una actualización)
Habilite la tunelización split-exclude para una dirección IP de modo que el DNS local pueda utilizar el adaptador físico. Una dirección de la subred local del link 169.254.0.0/16 se utiliza comúnmente ya que es poco probable que el tráfico a esas direcciones atraviese la VPN.
Después de habilitar la tunelización split-exclude, habilite el acceso LAN local en el perfil o cliente del cliente y deshabilite tunnel-all-DNS. Este es un ejemplo de configuración de ASA/FTD:
access-list acl_linklocal_169.254.1.1 standard permit host 169.254.1.1
group-policy gp_access-14 attributes
split-tunnel-policy excludespecified
split-tunnel-network-list value acl_linklocal_169.254.1.1
split-tunnel-all-dns disable
exit
XML de perfil de cliente:
<LocalLanAccess UserControllable="true">true</LocalLanAccess>
También puede habilitar esto en la GUI de Secure Client: Preferencias → Activar Permitir acceso local (LAN) al utilizar VPN
- Utilice nombres de dominio completos (FQDN) en lugar de nombres de host no calificados.
- Utilice una dirección IP diferente para el servidor DNS en la interfaz física (independiente de DHCP en la misma subred).
DNS con tunelación dividida en diferentes sistemas operativos cliente
Diferentes sistemas operativos cliente manejan DNS de manera diferente con tunelización dividida (sin DNS dividido) para Secure Client; en esta sección se describen dichas diferencias.
Microsoft Windows (Windows 10 y Windows 11)
En Windows, la configuración de DNS se realiza por interfaz de red. Con la tunelización dividida, las consultas DNS pueden recurrir a los servidores DNS de adaptador físico después de que fallan en el adaptador de túnel VPN. Si se utiliza la tunelización dividida sin DNS dividido, la resolución interna y externa puede funcionar, ya que la resolución puede recurrir a servidores DNS externos. Se produjo un cambio significativo en Secure Client para Windows en la versión 4.2 después de la corrección para el Id. de error de Cisco CSCuf07885. Este comportamiento no se modifica en Secure Client 5.x.
Nota: Solo los usuarios registrados de Cisco tienen acceso a las herramientas de errores internas de Cisco.
Configuración de Tunnel-all (y Tunelización Dividida con Tunnel-all-DNS Habilitado)
Pre-Secure Client 4.2 (AnyConnect 4.1 y versiones anteriores):
- Sólo se permiten las solicitudes DNS a servidores DNS configurados en la directiva de grupo (servidores DNS de túnel).
- El controlador de Secure Client responde a todas las demás solicitudes sin ese nombre.
- La resolución DNS sólo puede utilizar servidores DNS de túnel.
Secure Client 4.2 y versiones posteriores:
- Las solicitudes DNS a cualquier servidor DNS se permiten si se originan desde el adaptador VPN y se envían a través del túnel.
- Todas las demás solicitudes no reciben ese nombre; solo a través del túnel VPN.
- Antes de la identificación de error de Cisco CSCuf07885, Secure Client restringía los servidores DNS de destino. Después de esta corrección, restringe qué adaptadores de red pueden iniciar solicitudes DNS.
Configuración Split-include (Tunnel-all-DNS deshabilitado, sin Split-DNS)
El controlador de Secure Client no interfiere con la resolución DNS nativa. La resolución respeta el orden del adaptador de red; Secure Client es el adaptador preferido cuando la VPN está conectada.
Una consulta DNS se envía primero a través del túnel; si no se resuelve, la resolución puede probar la interfaz pública. La lista de acceso split-include debe incluir la subred que cubre los servidores DNS de túnel en las versiones anteriores a la 4.2. A partir de Secure Client 4.2, las rutas de host para los servidores DNS de túnel se agregan automáticamente como redes split-include (rutas seguras), por lo que la ACL split-include ya no requiere subredes de servidores DNS de túnel explícitas.
Configuración de exclusión dividida (Tunnel-all-DNS deshabilitado, no Split-DNS)
El mismo comportamiento de resolución que split-includes, túnel primero y, a continuación, repliegue de la interfaz pública. La lista de acceso de exclusión dividida no debe incluir la subred que cubre los servidores DNS del túnel. A partir de Secure Client 4.2, las rutas de host automáticas para los servidores DNS de túnel evitan errores de configuración comunes de split-exclude.
Split-DNS (túnel-todo-DNS deshabilitado, Split-incluir configurado)
Split-DNS en Windows requiere tunelización split-include (túnel split-tunnel-policy tunnelspecified). No admite políticas de túnel split-exclude-only para la configuración split-DNS.
Cliente Pre-Secure 4.2:
- Consultas de dominio de DNS dividido: Solo se permite tunelizar servidores DNS; no existe tal nombre si se envía a otros servidores.
- Consultas de dominio DNS no dividido: Permitido sólo para otros servidores DNS; no existe tal nombre si se intenta a través del túnel.
Secure Client 4.2 y posterior (DNS dividido verdadero en Windows):
- Consultas de dominio de DNS dividido: Permitido a cualquier servidor DNS sólo si se originan desde el adaptador VPN. Las consultas de la interfaz pública no reciben tal nombre para forzar el uso del túnel.
- Consultas de dominio DNS no dividido: Permitido a cualquier servidor DNS sólo si se originan en el adaptador físico. Las consultas del adaptador VPN no reciben tal nombre para forzar la resolución de la interfaz pública.
DNS dividido con tunelización de exclusión dividida (Secure Client 5.x)
La documentación de administración de Secure Client 5.x agrega DNS dividido para configuraciones de exclusión dividida. Consulte la Guía del Administrador de Secure Client 5.x — Configure Split DNS for Split Exclude Tunneling para los requisitos de cabecera y política. Las reglas de aplicación en el nivel del sistema operativo se siguen aplicando una vez que el DNS dividido está activo.
DNS cifrado (DoH/DoT) en Windows
Las aplicaciones o las funciones del sistema operativo que utilizan DNS sobre HTTPS (DoH) o DNS sobre TLS (DoT) pueden omitir la ruta de resolución de rutas internas de Windows que Secure Client filtra. Si el DNS dividido parece fallar para aplicaciones específicas pero funciona en un navegador, verifique si esas aplicaciones utilizan DNS cifrado o personalizado. Las pruebas estándar de split-DNS deberían utilizar la resolución del sistema operativo (navegador, ping), no NSLookup/dig.
macOS
En macOS, la configuración de DNS es global (no por interfaz). Si se utiliza la tunelización dividida sin DNS dividido, las consultas DNS a menudo no pueden alcanzar a los servidores DNS fuera del túnel como se esperaba, puede resolver sólo los nombres internos, no los nombres externos a través de la ruta pública. Esto se documenta en el ID de bug de Cisco CSCtf20226 y el ID de bug de Cisco CSCtz86314.
Soluciones alternativas:
- Especifique una dirección IP de servidor DNS externo en la directiva de grupo y utilice FQDN para consultas internas.
- Si los nombres externos se pueden resolver a través del túnel, desactive split DNS en Advanced > Split Tunneling quitando los nombres DNS de la política de grupo y utilice FQDN para consultas internas.
El DNS dividido en macOS es compatible desde AnyConnect 3.1 en adelante, sujeto a estas condiciones:
- DNS dividido habilitado para ambos protocolos IP (requiere ASA 9.0+/FTD equivalente) o;
- DNS dividido habilitado para un protocolo IP y Protocolo de omisión del cliente habilitado para el otro sin conjunto de direcciones para el protocolo omitido (o sin conjunto IPv6 en las versiones de ASA anteriores a la 9.0).
Nota: Secure Client no administra principalmente la resolución de nombres a través de /etc/resolv.conf en macOS; configura los parámetros de DNS en el nivel del SO. macOS puede mantener resolv.conf actualizado por compatibilidad. Ejecute scutil —dns para ver la configuración de DNS efectiva.
Configuración de Tunnel-all (y Tunelización Dividida con Tunnel-all-DNS Habilitado)
Cuando Secure Client está conectado, solo los servidores DNS de túnel permanecen en la configuración DNS del sistema; las solicitudes solo se dirigen a los servidores DNS de túnel.
Split-include / Split-exclude (Tunnel-all-DNS deshabilitado, no Split-DNS)
Secure Client no interfiere con la resolución nativa. Los servidores DNS de túnel son preferibles a los resolvers públicos, por lo que el primer intento de consulta pasa por el túnel. Debido a que DNS es global en macOS, las consultas no siempre usan de manera confiable DNS público fuera del túnel (Id. de error de Cisco: CSCtf2026).
A partir de Secure Client 4.2, las rutas de host para los servidores DNS de túnel se agregan automáticamente como rutas seguras.
Split-DNS (túnel-todo-DNS deshabilitado, Split-incluir configurado)
El DNS dividido verdadero (similar a Windows) se aplica cuando:
- Split-DNS está habilitado para IPv4 e IPv6, o bien;
- Split-DNS está habilitado para un protocolo y no existe ningún conjunto de direcciones de cliente para el otro protocolo.
El DNS dividido verdadero significa que los dominios de DNS dividido coincidentes se resuelven solamente a través del túnel y no se filtran a los resolvers externos.
Si split-DNS está habilitado sólo para un protocolo y se asigna una dirección de cliente para el otro protocolo, sólo se aplica la reserva de DNS para la tunelización dividida: Secure Client permite las consultas coincidentes a través del túnel (otras consultas pueden ser rechazadas para forzar la conmutación por fallas), pero no puede prevenir completamente la fuga de consultas de dominio DNS dividido enviadas en el clear a través del adaptador público.
Compatibilidad de plataforma (guía de administración de Secure Client): El DNS dividido completo es compatible con Windows y macOS. Linux tiene una compatibilidad limitada (consulte la sección Linux).
Linux
Configuración de Tunnel-all (y Tunelización Dividida con Tunnel-all-DNS Habilitado)
Cuando Secure Client está conectado, sólo los servidores DNS de túnel se mantienen en la configuración DNS del sistema.
Split-include / Split-exclude (Tunnel-all-DNS deshabilitado, sin Split-DNS)
Secure Client no interfiere con la resolución nativa. Se prefieren los servidores DNS de túnel; el intento de resolución inicial pasa por el túnel.
Split-DNS (túnel-todo-DNS deshabilitado, Split-incluir configurado)
Si split-DNS está habilitado, solamente se aplica el respaldo DNS para la tunelización dividida en Linux:
- Secure Client permite consultas de dominio DNS dividido a través del túnel.
- Otras consultas pueden recibir rechazo para alentar la conmutación por error a DNS público.
- Secure Client no puede aplicar completamente las consultas split-DNS-domain, ya que nunca se envían en el clear a través del adaptador público.
La guía de administración de Secure Client indica que el DNS dividido limitado en Linux: solo las solicitudes DNS tunelizadas están totalmente sujetas a la política de DNS dividido; algunas consultas fuera del túnel no pueden cumplir con la política de DNS dividido.
VM y contenedores de Linux
Secure Client admite un atributo personalizado tunnel-from-any-source, por lo que los paquetes con cualquier dirección de origen se pueden enrutar en modo split-include o split-exclude dentro de las instancias de VM o los contenedores Docker. Consulte la Guía del Administrador de Secure Client 5.x para obtener detalles de configuración.
Apple iOS (iPhone y iPad)
El comportamiento de iOS difiere de macOS y no es idéntico a Windows. Si la tunelización dividida se configura sin DNS dividido, las consultas DNS suelen utilizar el servidor DNS global definido para el dispositivo, no el mismo patrón de reserva que Windows.
Impacto práctico: Las entradas de dominio DNS dividido suelen ser necesarias para una resolución de nombres interna confiable cuando se utiliza la tunelización dividida sin DNS dividido.
Corrección histórica: Id. de error de Cisco CSCtq09624 - (AnyConnect para iOS 2.5.4038 y versiones posteriores.) El cliente seguro actual para iOS obedece al mismo requisito general; configure split DNS para dominios internos cuando utilice split-include/split y exclude sin depender de la reserva de estilo Windows.
Nota: Las consultas de DNS de iOS ignoran los dominios .locales (Id. de error de Cisco CSCts89292).
Apple trata esto como un comportamiento diseñado; no espere una resolución .local a través de un DNS dividido estándar en iOS. En iOS, el comportamiento de DNS dividido de Secure Client también difiere de otras plataformas cuando la tunelización dividida se combina con ciertas configuraciones de lista de DNS dividido. Consulte la sección Guía de Secure Client Administrator Comportamiento de la resolución de DNS dividido con túnel dividido para combinaciones de políticas específicas de iOS (split-dns none, default-domain, etc.).
Tunelización dividida dinámica y DNS (Secure Client 4.5+)
La tunelización dividida dinámica resuelve los FQDN en el momento de la conexión o a demanda, y ajusta el ruteo y los filtros para el tráfico a los dominios especificados. Esto se incluye o se excluye del túnel sin listas de IP estáticas.
| Función | Descripción |
|---|---|
| Exclusión de división dinámica | Los dominios (example.com) se excluyen del túnel en tiempo de ejecución cuando las aplicaciones resuelven esos nombres. |
| La división dinámica incluye | Los dominios se incluyen dinámicamente en el túnel. |
| División dinámica mejorada | Las listas de dominios de inclusión/exclusión combinadas con reglas de precedencia (como excluir example.com, pero incluir mail.example.com). |
La tunelización dividida dinámica utiliza la resolución DNS para impulsar los cambios de ruteo. Se configura a través de los atributos personalizados de Secure Client en la cabecera (por ejemplo, dynamic-split-exclude-dominios, dynamic-split-include-dominios).
La tunelización dividida dinámica se aplica a las políticas tunnel-all y split-exclude (exclusión dinámica) o split-include (inclusión dinámica). No reemplaza la política de DNS dividido, sin embargo, la complementa: split DNS controla qué consultas se tunelizan; la tunelización dividida dinámica controla qué tráfico IP se tuneliza en función de los nombres resueltos. Consulte los detalles de configuración: Configure Dynamic Split Tunneling y la Guía del Administrador de Secure Client 5.x.
Fallo de exclusión dividido (Secure Client 5.x): El atributo personalizado opcional SplitExcludeFailoverEnabled enruta el tráfico a través de la VPN cuando la ruta pública no tiene conectividad con los destinos de exclusión dividida. Consulte la guía del administrador para obtener información sobre la configuración de atributos personalizados.
Versiones históricas de clientes (Referencia)
La siguiente tabla se aplica sólo a las implementaciones heredadas que aún ejecutan clientes obsoletos:
| Versión | Relevancia |
|---|---|
| AnyConnect 2.4 | Introducción de la reserva de DNS dividido de mejor esfuerzo |
| AnyConnect 2.5 (iOS) | ID de falla de funcionamiento de Cisco: Alineación DNS de iOS CSCtq09624 |
| AnyConnect 3.0 (4235) | DNS dividido verdadero en Windows; Correcciones de rendimiento de DNS |
| AnyConnect 3.1 (macOS) | Compatibilidad con DNS dividido con condiciones IPv4/IPv6 |
| AnyConnect 4.2 | Id. de error de Cisco: aplicación basada en el adaptador CSCuf07885; Automatic Tunnel DNS Host Routers |
Implemente Secure Client 5.x en todas las plataformas compatibles para las correcciones y funciones actuales.
Información de error relacionada
Nota: Solo los usuarios registrados de Cisco tienen acceso a las herramientas de errores internas de Cisco.
- Id. de error de Cisco: CSCtn14578 - DNS dividido verdadero (sin reserva) - Windows, 3.0(4235)+
- Cisco bug ID: CSCtq02141 - Retraso de DNS cuando el ISP DNS está en la misma subred que la IP pública
- ID de falla de funcionamiento de Cisco: CSCuf0785 - DNS de Windows: restringir por adaptador, no por servidor de destino - 4.2+
- ID de falla de funcionamiento de Cisco: CSCtf2026 - MACOS split tunnel DNS a diferencia de Windows
- ID de falla de funcionamiento de Cisco: CSCtz86314 - consultas de DNS dividido de macOS no enviadas a través del túnel
- ID de falla de funcionamiento de Cisco: CSCtq09624 - Comportamiento DNS de túnel dividido de iOS
- ID de falla de funcionamiento de Cisco: CSCts89292 - iOS ignora los dominios DNS .local
- ID de falla de funcionamiento de Cisco: CSCsv34395: proxy FQDN para compatibilidad con servidor DHCP
Información Relacionada
- Examine el comportamiento de las consultas DNS y la resolución de nombres de dominio (Cisco.com) — Id. de documento 116016
- Guía del administrador de Cisco Secure Client 5.x: Configurar acceso VPN/DNS dividido
- Configuración de la tunelización dividida dinámica de ASA/AnyConnect: ID de documento 215383
- Habilitar el túnel de todos los DNS para el cliente seguro con el módulo Umbrella — ID de documento 224809
- Interoperabilidad entre AnyConnect y el cliente de roaming de OpenDNS — ID de documento 200395
- Soporte técnico y descargas de Cisco
Historial de revisión
| Revisión: | Fecha | Comentarios |
|---|---|---|
| 4.0 | 28 de julio de 2026 | Actualización sustantiva completa: Marca Secure Client, actualización de la plataforma, tunelación dividida dinámica, Umbrella/tunnel-all-DNS, correcciones de errores tipográficos y configuraciones, enlaces relacionados corregidos |
| 3.0 | 23 de mayo de 2024 | Recertificación (Cisco.com) |
| 1.0 | 12 de junio de 2014 | Versión inicial |
El documento se aplica a
- Cisco Secure Client (incluido AnyConnect): Windows, macOS, Linux, iOS
- Políticas de grupo de VPN de acceso remoto FTD y ASA de Cisco Secure Firewall
Historial de revisiones
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
4.0 |
10-Aug-2026
|
Introducción actualizada, ortografía, gramática, URL fijas, líneas horizontales insertadas en secciones separadas para facilitar la lectura y errores de CCW corregidos. |
3.0 |
23-May-2024
|
Recertificación |
1.0 |
12-Jun-2014
|
Versión inicial |
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)