Ridurre la latenza sulle reti WiFi ad alta densità

TESTO DEL PODCAST — "Ridurre la latenza sulle reti WiFi ad alta densità" Durata: circa 10 minuti Voce: italiano, tono da consulente senior — sicuro, colloquiale, autorevole. --- [INTRO — circa 1 minuto] Bentornati. Oggi andrò dritto al punto, perché questo è uno di quei temi in cui il divario tra ciò che la maggior parte dei team fa e ciò che dovrebbe fare ha un costo reale. Parliamo di latenza sulle reti WiFi ad alta densità — e in particolare, del perché il DNS sia il colpevole nascosto che quasi nessuno prende in considerazione. Se gestite il WiFi in un hotel, uno stadio, un centro congressi o una grande catena di negozi, avrete quasi certamente affrontato la conversazione: "La rete è lenta". E l'istinto è sempre quello di guardare alla densità degli access point, all'utilizzo dei canali o alla capacità del backhaul. Elementi importanti, certo. Ma c'è un livello inferiore a tutto questo — il livello DNS — in cui si rischia di perdere latenza su ogni singolo dispositivo, per ogni singolo caricamento di pagina, prima ancora che venga spostato un solo byte di contenuto effettivo. Questo è ciò che analizzeremo oggi. Vi guiderò attraverso i meccanismi tecnici, vi presenterò due scenari concreti di implementazione e vi lascerò con una serie chiara di azioni da proporre al vostro team già questa settimana. --- [APPROFONDIMENTO TECNICO — circa 5 minuti] Partiamo dalle basi. Quando un dispositivo si connette al vostro WiFi e un utente apre un browser o un'app, cosa succede effettivamente per primo? Prima di recuperare qualsiasi contenuto, il dispositivo deve risolvere i nomi di dominio in indirizzi IP. Questo è il DNS. E su un moderno smartphone, il caricamento di una singola pagina — ad esempio, un articolo di giornale o la pagina di prenotazione di un hotel — può attivare tra le 20 e le 70 query DNS. Non perché la pagina stessa contenga 70 domini, ma perché è piena di pixel di tracciamento di terze parti, script pubblicitari, beacon di analisi e widget di social media. Ognuno di questi avvia una query DNS. Ora, in un normale ambiente domestico o d'ufficio con pochi dispositivi, tutto questo è ampiamente invisibile. Il resolver DNS gestisce la richiesta, la cache TTL fa il suo lavoro e l'overhead è trascurabile. Ma provate a mettere 500 dispositivi sullo stesso cluster di access point durante una conferenza, o 3.000 ospiti in un hotel nell'ora di punta dei check-in, e avrete una tempesta di query DNS (DNS query storm). Il vostro resolver locale — ammesso che ne abbiate uno — si troverà a gestire decine di migliaia di query al minuto, una percentuale significativa delle quali è diretta verso l'internet pubblico per risolvere domini di reti pubblicitarie e servizi di tracciamento che non caricheranno mai contenuti di reale interesse per l'utente. Ecco l'aspetto cruciale: ognuna di queste query DNS non necessarie aggiunge latenza all'esperienza percepita dall'utente. Non parliamo del tempo di caricamento del contenuto, ma del tempo di risoluzione precedente al caricamento. Su una rete congestionata, una singola query DNS a un resolver esterno può richiedere da 80 a 150 millisecondi. Se una pagina avvia 15 query a domini di tracciamento prima di iniziare a caricare il contenuto effettivo, avete appena aggiunto più di un secondo di ritardo invisibile prima che l'utente veda qualcosa. Questo non è un problema di backhaul. È un problema di DNS. La soluzione prevede due componenti. Primo, distribuire un resolver DNS locale — idealmente on-premises o all'edge della rete — con un caching aggressivo. Unbound, Pi-hole in modalità enterprise o equivalenti commerciali di vendor come Cisco Umbrella o Infoblox funzionano benissimo in questo contesto. L'obiettivo è risolvere la maggior parte delle query dalla cache, in meno di 5 millisecondi, senza interpellare l'internet pubblico. Per una struttura ad alta densità, dovreste puntare a un cache hit rate superiore al 70% in condizioni di funzionamento a regime. Secondo, ed è qui che si ottengono i veri vantaggi: implementare il filtraggio DNS per scartare le query verso domini noti di tracciamento, pubblicità e telemetria direttamente a livello di resolver. Quando arriva una query per un dominio pubblicitario noto, il resolver restituisce istantaneamente NXDOMAIN — dominio non trovato — in meno di un millisecondo. Il dispositivo riceve la risposta, smette di attendere e passa alla query successiva. Avete eliminato completamente il viaggio di andata e ritorno verso l'internet pubblico. Moltiplicate questo risultato per 15 domini di tracciamento a caricamento di pagina, su 500 dispositivi simultanei, e la riduzione complessiva del volume di query DNS — e quindi della latenza — sarà sostanziale. C'è un'importante sfumatura da considerare riguardo al DNS over HTTPS, o DoH. I browser e i sistemi operativi moderni aggirano sempre più spesso il resolver locale inviando le query DNS direttamente ai provider DoH come Cloudflare o Google tramite HTTPS crittografato. Se questo è eccellente per la privacy degli utenti consumer, mina completamente la vostra strategia di caching e filtraggio locale in un ambiente di rete gestito. È necessario intercettare o reindirizzare il traffico DoH a livello di firewall, oppure distribuire un proprio resolver DoH verso cui indirizzare i dispositivi tramite la DHCP option 6 e le policy di rete. Questa è un'area di crescente complessità — se desiderate un approfondimento specifico sulle implicazioni del DoH, Purple offre una guida dedicata al DNS over HTTPS per il filtraggio del WiFi pubblico che vale la pena leggere. Ora, colleghiamo questo aspetto alla parte RF, perché l'ottimizzazione del DNS non esiste nel vuoto. In una distribuzione ad alta densità, in genere si utilizza lo standard 802.11ax — WiFi 6 o WiFi 6E — con OFDMA e BSS Colouring per gestire l'interferenza co-canale. Il motivo per cui il DNS è ancora più importante in questi ambienti è che i guadagni di efficienza di OFDMA si basano sul presupposto che il mezzo radio sia utilizzato per il trasferimento effettivo dei dati, non per l'overhead della risoluzione di centinaia di nomi di dominio non necessari. Ogni query DNS inviata a internet è un piccolo pacchetto che occupa un'opportunità di trasmissione (TXOP). Su larga scala, questo overhead è misurabile in termini di throughput. La combinazione di caching DNS locale, filtraggio dei domini di tracciamento e un ambiente radio 802.11ax ben ottimizzato è il punto di partenza per ottenere miglioramenti radicali. Parliamo di una riduzione della latenza percepita nel caricamento delle pagine dal 60 all'87% in distribuzioni reali, non in condizioni di laboratorio. --- [RACCOMANDAZIONI DI IMPLEMENTAZIONE E TRAPPOLE DA EVITARE — circa 2 minuti] Bene, passiamo alla pratica. Se state pianificando una distribuzione di questo tipo, ecco come procederei. Iniziate con un audit del DNS. Prima di toccare qualsiasi cosa, monitorate il resolver esistente — o implementate un Passive DNS Tap — e acquisite i log delle query per 24-48 ore. Scoprirete quasi certamente che dal 30 al 50 percento del volume delle query è diretto verso un gruppo relativamente ristretto di domini di tracciamento e pubblicità. Questo è il vostro primo obiettivo. Successivamente, distribuite un resolver locale con una blocklist curata. Raccomando di iniziare con una lista conservativa — come la lista consolidata di host di Steven Black o un equivalente commerciale — piuttosto che con una troppo aggressiva. L'obiettivo è evitare di bloccare domini da cui dipendono applicazioni legittime. Eseguite i test in una VLAN di staging prima di passare alla produzione. Per l'intercettazione del DoH, dovrete agire a livello di firewall. Bloccate le porte TCP e UDP 443 in uscita verso gli intervalli IP dei noti provider DoH — come 1.1.1.1 di Cloudflare o 8.8.8.8 di Google — e reindirizzate tali query al vostro resolver DoH locale. Questo richiede coordinamento con il team di sicurezza, in particolare se operate in un ambiente sensibile a PCI DSS o GDPR, poiché state di fatto eseguendo una forma di ispezione DNS. Documentate la procedura, ottenete l'approvazione e assicuratevi che i termini di servizio del vostro Captive Portal riflettano la policy di filtraggio. La trappola più grande che vedo è l'implementazione di un filtraggio troppo aggressivo, che genera chiamate al supporto perché una specifica applicazione ha smesso di funzionare. Prevedete un processo di risposta rapida per le richieste di whitelist dei domini e monitorate i tassi di risposta NXDOMAIN. Se aumentano improvvisamente, significa che qualcosa è cambiato nelle dipendenze DNS di un'applicazione legittima. Il secondo errore è considerare questa configurazione come un'attività una tantum anziché come un compito operativo continuo. I domini di tracciamento cambiano. Emergono nuove reti pubblicitarie. La blocklist deve essere aggiornata regolarmente — come minimo mensilmente, idealmente ogni settimana tramite un feed automatizzato. --- [DOMANDE E RISPOSTE RAPIDE — circa 1 minuto] Alcune domande che mi vengono poste regolarmente su questo argomento. "Il filtraggio DNS influisce sulla conformità al GDPR?" — In realtà può essere d'aiuto. Impedendo la risoluzione dei domini di tracciamento, riducete i dati che le reti pubblicitarie di terze parti possono raccogliere sui vostri ospiti. Detto questo, documentate la vostra policy di filtraggio e includetela nell'informativa sulla privacy. "Che dire dello Split DNS per le risorse interne?" — Assolutamente necessario. Il resolver locale deve avere zone autorevoli per tutti i nomi host interni, che non devono mai essere inoltrati all'esterno. È una pratica standard, ma vale la pena ribadirla. "Posso farlo su una piattaforma WiFi gestita in cloud?" — Sì, la maggior parte delle piattaforme enterprise — Cisco Meraki, Juniper Mist, Aruba Central — supporta l'assegnazione di server DNS personalizzati tramite DHCP. Indirizzate i dispositivi verso il vostro resolver locale e il filtraggio avverrà lì, indipendentemente dalla piattaforma cloud che gestisce gli AP. "Qual è il ROI di questo intervento?" — Punteggi di soddisfazione degli ospiti più elevati, riduzione del volume di ticket di supporto per lamentele sul WiFi lento e miglioramenti misurabili nei tempi di caricamento del Captive Portal. Per un hotel, questo si traduce direttamente in recensioni migliori. Per un centro congressi, fa la differenza tra una riconferma della prenotazione e la perdita di un cliente. --- [RIASSUNTO E PROSSIMI PASSI — circa 1 minuto] Per concludere: l'intervento a più alto impatto e minor costo che possiate fare per ridurre la latenza del WiFi in una struttura ad alta densità è distribuire un resolver DNS locale con filtraggio dei domini di tracciamento. Questo risolve la causa principale di una percentuale significativa della latenza percepita — non l'ambiente RF, non il backhaul, ma la tempesta di query DNS generata da ogni dispositivo sulla rete che risolve domini per contenuti che non verranno mai caricati. La vostra lista d'azione: eseguite un audit del DNS questa settimana, pianificate la distribuzione di un resolver locale e concordate una strategia di blocklist con il vostro team di sicurezza. Se dovete gestire l'aggiramento tramite DoH, quello sarà il livello successivo da affrontare. La piattaforma [Guest WiFi] di Purple e gli strumenti di [WiFi Analytics] sono progettati esattamente con questo tipo di intelligenza di rete — se volete scoprire come l'ottimizzazione del DNS si inserisce in una strategia WiFi più ampia per le strutture, vale la pena fare una chiacchierata con il team di Purple. Grazie per l'ascolto. Alla prossima. --- FINE DEL TESTO