Verifica della propagazione DNS
Verifica la propagazione dei record DNS in tempo reale su 8 resolver Anycast globali per garantire passaggi di consegne del dominio senza tempi di inattività.
Verifica la sincronizzazione dei record DNS globali
Stimatore di convergenza della propagazione DNS
Stima per quanto tempo i resolver ricorsivi downstream e i dispositivi dei visitatori manterranno in cache i vecchi record in base al TTL precedente della zona.
Interroga i resolver Anycast pubblici di Google, Cloudflare, NextDNS, AdGuard, Alibaba e DNS.SB tramite DNS-over-HTTPS (DoH) sicuro.
Come funziona la propagazione DNS globale
Quando aggiungi o aggiorni un record DNS sul tuo registrar di domini o nameserver autorevole, l'aggiornamento viene immediatamente scritto nel tuo file di zona master. Tuttavia, i resolver DNS ricorsivi degli Internet Service Provider (ISP), delle reti di operatori mobili e delle reti Anycast pubbliche non interrogano i nameserver in modo continuo. Al contrario, memorizzano in cache i record esistenti per la durata stabilita dal valore TTL (Time To Live) del record.
Questo strumento esegue query DNS-over-HTTPS (DoH) parallele direttamente su 8 principali reti ricorsive Anycast globali situate in Nord America, Europa e Asia-Pacifico. Eventuali discrepanze tra i resolver indicano che un aggiornamento di zona si sta propagando attivamente, consentendo agli ingegneri di rete di verificare la convergenza prima di annunciare importanti passaggi di consegne della rete.
Matrice di benchmark dei resolver DNS Anycast globali
| Rete resolver | IP Anycast primario | Architettura di routing | Subnet client EDNS (ECS) | Latenza globale tipica |
|---|---|---|---|---|
| Google Public DNS | 8.8.8.8 | BGP Anycast globale (100+ POP) | Supportato (ECS abilitato) | 10 - 45 ms |
| Cloudflare Standard | 1.1.1.1 | BGP Anycast globale (300+ città) | Disabilitato (orientato alla privacy) | 5 - 25 ms |
| Cloudflare Security | 1.1.1.2 | Anycast di sicurezza globale (blocco malware) | Disabilitato | 10 - 30 ms |
| NextDNS Anycast | 45.90.28.0 | Anycast globale a bassissima latenza | Supportato | 12 - 40 ms |
| AdGuard DNS | 94.140.14.14 | Anycast distribuito globale | Disabilitato | 15 - 50 ms |
| Alibaba Cloud DNS | 223.5.5.5 | Anycast Asia-Pacifico e globale | Supportato | 20 - 80 ms |
Propagazione DNS del portale captive e meccaniche di walled garden
Per le distribuzioni del WiFi per ospiti in location, hotel, centri commerciali e campus aziendali, l'affidabilità del DNS è fondamentale. Quando un visitatore si connette a un access point WiFi, il controller LAN wireless (WLC) intercetta il traffico DNS e HTTP iniziale per attivare il flusso di login al portale captive:
- Probe del Captive Network Assistant (CNA): I sistemi operativi mobili inviano automaticamente richieste DNS per i domini di probe (come
captive.apple.comsu iOS econnectivitycheck.gstatic.comsu Android). - Walled Garden di pre-autenticazione: Il controller di rete deve consentire la risoluzione DNS senza restrizioni per l'hostname del portale captive, i gateway di pagamento e i provider OAuth per il social login prima che il visitatore si autentichi.
- Pre-staging del TTL DNS: Quando si migrano gli URL del portale captive o i certificati SSL, gli ingegneri di rete devono ridurre il TTL della zona a 300 secondi (5 minuti) con almeno 24-48 ore di anticipo per prevenire timeout di connessione lato client durante il passaggio di consegne.
Come verificare la propagazione DNS globale per i domini dei portali captive
Istruzioni passo-passo per gli ingegneri di rete per verificare la sincronizzazione dei record DNS tra i resolver Anycast globali prima e dopo i passaggi di consegne del dominio.
Inserisci l'hostname o l'FQDN del portale captive
Inserisci il nome di dominio completamente qualificato (FQDN), come portal.venue.com o purple.ai, nel campo hostname.
Seleziona il tipo di record DNS di destinazione
Scegli il tipo di record oggetto di audit: A (IPv4), AAAA (IPv6), CNAME (alias canonico), TXT (verifica o SPF) o MX (routing della posta).
Interroga i resolver Anycast globali
Fai clic su Check propagation per attivare richieste DNS-over-HTTPS parallele su Google, Cloudflare, NextDNS, AdGuard, Alibaba e DNS.SB.
Ispeziona il tasso di sincronizzazione e la convergenza TTL
Esamina l'indicatore della percentuale di sincronizzazione globale, verifica la latenza dei resolver (ms) ed esporta il report diagnostico Markdown per i ticket di verifica delle modifiche.
Domande frequenti sulla propagazione DNS
Che cos'è la propagazione DNS e perché richiede tempo?
La propagazione DNS è l'intervallo di tempo necessario affinché gli aggiornamenti effettuati sui nameserver autorevoli vengano distribuiti e aggiornati attraverso i resolver DNS ricorsivi a livello globale. Quando un record DNS viene modificato, i resolver di caching intermedi (come quelli degli ISP, i resolver pubblici come Google e Cloudflare e i forwarder aziendali) conservano il vecchio record fino alla scadenza del suo Time To Live (TTL). La propagazione richiede in genere da pochi minuti a 24 ore, a seconda del TTL preconfigurato.
Perché i portali captive del WiFi per ospiti smettono di funzionare durante la propagazione DNS?
Quando un dispositivo ospite si connette a un SSID per ospiti aperto o sicuro, i sistemi operativi come iOS, macOS, Android e Windows avviano controlli automatizzati di rilevamento del portale captive (come l'invio di query a captive.apple.com o connectivitycheck.gstatic.com). L'access point o il controller intercetta il traffico HTTP e reindirizza il browser del client al dominio del portale captive (ad es. portal.purple.ai). Se il dispositivo client utilizza un resolver DNS che non ha ancora salvato in cache il nuovo record del portale, la risoluzione DNS fallisce, causando il timeout del browser del captive network assistant (CNA) e l'interruzione dell'onboarding.
In che modo il TTL DNS influisce sulla velocità di propagazione attraverso i resolver degli ISP?
Il TTL (Time To Live) è un intero a 32 bit espresso in secondi, definito su ciascun record di risorsa DNS, che specifica per quanto tempo ai resolver ricorsivi sia consentito memorizzare in cache la risposta. Un TTL più basso (come 300 secondi) assicura che i resolver interroghino il nameserver autorevole ogni 5 minuti, consentendo migrazioni rapide. Un TTL elevato (come 86.400 secondi / 24 ore) fa sì che i resolver forniscano record obsoleti memorizzati in cache fino a un'intera giornata.
Qual è la differenza tra DNS autorevole e resolver DNS ricorsivi?
I nameserver autorevoli contengono il zone file master e la fonte di verità definitiva per un dominio (ad es. AWS Route 53, Cloudflare DNS, NS1). I resolver DNS ricorsivi (come Google 8.8.8.8, Cloudflare 1.1.1.1 e i nameserver degli ISP) agiscono come intermediari che interrogano i server autorevoli per conto dei dispositivi client e memorizzano in cache i risultati in base al TTL del record.
In che modo gli ingegneri di rete possono svuotare la cache DNS locale per verificare la propagazione?
Su macOS, esegui `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder` nel Terminale. Su Windows, esegui `ipconfig /flushdns` nel Prompt dei comandi. Su Linux, riavvia systemd-resolved tramite `sudo systemd-resolve --flush-caches` o `sudo resolvectl flush-caches`. In alternativa, utilizza questo strumento online di verifica della propagazione DNS per interrogare direttamente i resolver Anycast esterni, ignorando la cache di qualsiasi sistema operativo locale.
Perché Purple consiglia il DNS Anycast e domini walled garden preconfigurati?
Purple gestisce un'infrastruttura cloud Anycast distribuita a livello globale che offre una risoluzione DNS inferiore a 20 ms e il caricamento istantaneo delle splash page HTTPS in tutto il mondo. La preconfigurazione delle whitelist dei domini walled garden e la riduzione dei TTL DNS prima delle migrazioni di onboarding garantiscono un'autenticazione trasparente degli ospiti con l'hardware Cisco Meraki, Aruba, Ubiquiti UniFi, Ruckus e Cisco Catalyst.
Strumenti correlati per la diagnostica di rete e il WiFi
Related WiFi tools
Stai migrando il dominio di un portale captive?
I passaggi di consegne del dominio e la propagazione DNS possono causare tempi di inattività per il WiFi per ospiti se non gestiti con attenzione. Purple offre hosting di portali Anycast ad alta disponibilità, gestione automatizzata dei certificati SSL e integrazioni hardware preconfigurate per l'onboarding dei visitatori senza tempi di inattività.
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