Comprobador de propagación DNS
Compruebe la propagación de registros DNS en tiempo real en 8 resolvedores Anycast globales para garantizar cutovers de dominio sin tiempo de inactividad.
Verifique la sincronización global de registros DNS
Estimador de convergencia de propagación de DNS
Estime cuánto tiempo los resolutores recursivos secundarios y los dispositivos de los visitantes mantendrán en caché los registros obsoletos en función del TTL de su zona anterior.
Consulta los resolutores Anycast públicos de Google, Cloudflare, NextDNS, AdGuard, Alibaba y DNS.SB a través de DNS-over-HTTPS (DoH) seguro.
Cómo funciona la propagación DNS global
Cuando añade o actualiza un registro DNS en su registrador de dominios o servidor de nombres autoritativo, la actualización se escribe inmediatamente en su archivo de zona maestro. Sin embargo, los resolvedores DNS recursivos de los proveedores de servicios de Internet (ISP), las redes de operadores móviles y las redes Anycast públicas no realizan consultas continuas a los servidores de nombres. En su lugar, almacenan en caché los registros existentes durante el tiempo dictado por el valor TTL (Time To Live) del registro.
Este comprobador realiza consultas paralelas de DNS sobre HTTPS (DoH) directamente contra 8 de las principales redes recursivas Anycast globales ubicadas en América del Norte, Europa y Asia-Pacífico. Las discrepancias entre resolvedores indican que la actualización de una zona se está propagando de forma activa, lo que permite a los ingenieros de redes verificar la convergencia antes de anunciar cutovers importantes en la red.
Matriz comparativa de resolvedores DNS Anycast globales
| Red del resolvedor | IP Anycast primaria | Arquitectura de enrutamiento | Subred cliente EDNS (ECS) | Latencia global habitual |
|---|---|---|---|---|
| Google Public DNS | 8.8.8.8 | BGP Anycast global (100+ POP) | Compatible (ECS habilitado) | 10 - 45 ms |
| Cloudflare Standard | 1.1.1.1 | BGP Anycast global (300+ ciudades) | Deshabilitado (prioridad a la privacidad) | 5 - 25 ms |
| Cloudflare Security | 1.1.1.2 | Anycast de seguridad global (bloqueo de malware) | Deshabilitado | 10 - 30 ms |
| NextDNS Anycast | 45.90.28.0 | Anycast global de latencia ultrabaja | Compatible | 12 - 40 ms |
| AdGuard DNS | 94.140.14.14 | Anycast distribuido global | Deshabilitado | 15 - 50 ms |
| Alibaba Cloud DNS | 223.5.5.5 | Anycast global y para Asia-Pacífico | Compatible | 20 - 80 ms |
Propagación DNS en portales cautivos y mecánica del walled garden
Para despliegues de WiFi para invitados en recintos, hoteles, centros comerciales y campus empresariales, la fiabilidad del DNS es crítica. Cuando un visitante se conecta a un punto de acceso WiFi, el controlador de LAN inalámbrica (WLC) intercepta el tráfico DNS y HTTP inicial para activar el flujo de inicio de sesión del portal cautivo:
- Sondas del asistente de red cautiva (CNA): Los sistemas operativos móviles emiten automáticamente solicitudes DNS para dominios de prueba (como
captive.apple.comen iOS yconnectivitycheck.gstatic.comen Android). - Walled Garden preautenticación: El controlador de red debe permitir la resolución DNS sin restricciones para el nombre de host de su portal cautivo, pasarelas de pago y proveedores OAuth de inicio de sesión social antes de que el visitante se autentique.
- Preconfiguración del TTL de DNS: Al migrar URL de portal cautivo o certificados SSL, los ingenieros de redes deben reducir el TTL de la zona a 300 segundos (5 minutos) con al menos 24 a 48 horas de antelación para evitar interrupciones de conexión en el lado del cliente durante el cutover.
Cómo comprobar la propagación DNS global para dominios de portal cautivo
Instrucciones paso a paso para que los ingenieros de redes verifiquen la sincronización de registros DNS en resolvedores Anycast globales antes y después de los cutovers de dominio.
Introduzca el nombre de host o el FQDN del portal cautivo
Introduzca el nombre de dominio totalmente cualificado (FQDN), como portal.venue.com o purple.ai, en el campo del nombre de host.
Seleccione el tipo de registro DNS de destino
Elija el tipo de registro que se está auditando: A (IPv4), AAAA (IPv6), CNAME (alias canónico), TXT (verificación o SPF) o MX (enrutamiento de correo).
Consulte los resolutores Anycast globales
Haga clic en «Check propagation» para activar solicitudes DNS-over-HTTPS paralelas a través de Google, Cloudflare, NextDNS, AdGuard, Alibaba y DNS.SB.
Inspeccione la tasa de sincronización y la convergencia de TTL
Revise el indicador del porcentaje de sincronización global, verifique la latencia del resolutor (ms) y exporte el informe de diagnóstico en Markdown para los tickets de verificación de cambios.
Preguntas frecuentes sobre la propagación DNS
¿Qué es la propagación DNS y por qué tarda tiempo?
La propagación DNS es el periodo de tiempo necesario para que las actualizaciones realizadas en los servidores de nombres autoritativos se distribuyan y actualicen en los resolutores DNS recursivos a nivel global. Cuando se modifica un registro DNS, los resolutores de caché intermedios (como los resolutores de ISP, los resolutores públicos como Google y Cloudflare, y los reenviadores corporativos) conservan el registro antiguo hasta que expira su tiempo de vida (TTL, Time To Live). Por lo general, la propagación tarda entre unos minutos y 24 horas, según el TTL preconfigurado.
¿Por qué fallan los portales cautivos de WiFi para invitados durante la propagación DNS?
Cuando un dispositivo de invitado se conecta a un SSID para invitados abierto o seguro, los sistemas operativos como iOS, macOS, Android y Windows inician comprobaciones automáticas de detección del portal cautivo (como consultar captive.apple.com o connectivitycheck.gstatic.com). El punto de acceso o controlador intercepta el tráfico HTTP y redirige el navegador del cliente al dominio del portal cautivo (p. ej., portal.purple.ai). Si el dispositivo cliente utiliza un resolutor DNS que aún no ha almacenado en caché el nuevo registro del portal, la resolución DNS falla, lo que provoca tiempos de espera agotados en el navegador del asistente de red cautiva (CNA) y errores en la incorporación.
¿Cómo afecta el TTL de DNS a la velocidad de propagación en los resolutores de los ISP?
El TTL (Time To Live) es un entero de 32 bits en segundos definido en cada registro de recurso DNS que especifica cuánto tiempo se permite a los resolutores recursivos almacenar en caché la respuesta. Un TTL más bajo (como 300 segundos) garantiza que los resolutores consulten al servidor de nombres autoritativo cada 5 minutos, lo que permite migraciones rápidas. Un TTL alto (como 86 400 segundos / 24 horas) hace que los resolutores sirvan registros obsoletos en caché durante hasta un día entero.
¿Cuál es la diferencia entre el DNS autoritativo y los resolutores DNS recursivos?
Los servidores de nombres autoritativos contienen el archivo de zona maestro y la fuente definitiva de verdad para un dominio (p. ej., AWS Route 53, Cloudflare DNS, NS1). Los resolutores DNS recursivos (como Google 8.8.8.8, Cloudflare 1.1.1.1 y los servidores de nombres de ISP) actúan como intermediarios que consultan a los servidores autoritativos en nombre de los dispositivos cliente y almacenan en caché los resultados según el TTL del registro.
¿Cómo pueden los ingenieros de red borrar la caché DNS local para verificar la propagación?
En macOS, ejecute `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder` en Terminal. En Windows, ejecute `ipconfig /flushdns` en el Símbolo del sistema. En Linux, reinicie systemd-resolved mediante `sudo systemd-resolve --flush-caches` o `sudo resolvectl flush-caches`. Como alternativa, utilice este verificador de propagación DNS en línea para consultar directamente resolutores Anycast externos, omitiendo toda la caché local del sistema operativo.
¿Por qué Purple recomienda Anycast DNS y dominios de jardín vallado preconfigurados?
Purple opera una infraestructura en la nube Anycast distribuida globalmente que ofrece una resolución DNS inferior a 20 ms y una carga instantánea de la página de bienvenida HTTPS en todo el mundo. Preconfigurar las listas blancas de dominios de jardín vallado (walled garden) y reducir los TTL de DNS antes de las migraciones de incorporación garantiza una autenticación de invitados fluida en el hardware de Cisco Meraki, Aruba, Ubiquiti UniFi, Ruckus y Cisco Catalyst.
Herramientas de WiFi y diagnóstico de red relacionadas
Related WiFi tools
¿Va a migrar un dominio de portal cautivo?
Los cutovers de dominio y la propagación DNS pueden causar tiempos de inactividad en el WiFi para invitados si no se gestionan cuidadosamente. Purple ofrece alojamiento de portal Anycast de alta disponibilidad, gestión automatizada de certificados SSL e integraciones de hardware preconfiguradas para la incorporación de visitantes sin tiempo de inactividad.
Book a 20-min demoNetforge Network Multi-Tool
Run offline network health checks, path analysis, and latency diagnostic scans directly from your desktop.
Download Multi-Tool