Test de vitesse DNS

Pourquoi la vitesse des résolveurs DNS est essentielle pour le WiFi d'entreprise et le WiFi invité

Chaque requête réseau, qu'il s'agisse du chargement d'une page web ou du lancement d'une connexion au portail captif, commence par une requête DNS (Domain Name System). Avant qu'un appareil mobile ou un ordinateur portable ne puisse négocier une connexion TCP ou une poignée de main TLS, il doit résoudre le nom d'hôte cible en une adresse IP. Lorsque les résolveurs DNS publics répondent lentement, les utilisateurs subissent une latence perceptible à chaque nouvelle connexion à un domaine.

Sur les réseaux WiFi invité à forte densité, la performance du DNS est encore plus critique. Dès la connexion à un SSID ouvert, les systèmes d'exploitation modernes (iOS CNA, Android Captive Portal Handler, Windows NCSI) émettent des requêtes de test HTTP pour détecter la connectivité Internet. Si le serveur DNS local ou le résolveur en amont ralentit pendant cette recherche, la page d'accueil du portail captif ne s'ouvre pas automatiquement, entraînant l'abandon de la connexion par l'invité.

Comparatif benchmark des résolveurs DNS publics

Le tableau ci-dessous résume les attributs techniques principaux et les profils de latence globale typiques des principaux fournisseurs DNS publics :

Comment fonctionne la mesure de la vitesse DNS sur navigateur

Les outils en ligne de commande traditionnels comme dig ou nslookup envoient des paquets UDP ou TCP bruts directement au port 53. Comme les navigateurs web fonctionnent dans un environnement sécurisé sans accès direct aux sockets, les tests de vitesse DNS sur navigateur utilisent DNS-over-HTTPS (RFC 8484).

L'outil d'évaluation lance une requête HTTPS de préchauffage pour alimenter le cache DNS local et établir la session TLS. Il effectue ensuite quatre cycles de récupération consécutifs en utilisant l'horodatage haute résolution performance.now() pour calculer le temps de réponse médian. Les résolveurs qui ne configurent pas les en-têtes CORS (Cross-Origin Resource Sharing) pour les requêtes de navigateur sont identifiés comme restreints par CORS.

Dépannage des échecs de connexion DNS et de portail captif

Lors de la configuration d'infrastructures sans fil d'entreprise (Cisco Meraki, HPE Aruba, Ruckus ou Ubiquiti UniFi), des paramètres DNS mal configurés entraînent fréquemment des pertes de connexion. Assurez-vous que votre configuration réseau prend en compte ces facteurs clés :

• Accès DNS de pré-authentification : Les équipements invités doivent bénéficier d'une résolution DNS non authentifiée sur le port 53 (ou les points de terminaison DoH) avant de terminer l'enregistrement sur le portail captif.
• Résolution de domaine en walled garden : Les connexions via les réseaux sociaux OAuth (Google, Apple, Facebook) nécessitent des listes d'autorisations FQDN explicites dans le contrôleur sans fil. Si le serveur DNS ne parvient pas à résoudre ces domaines, l'authentification s'arrête.
• Interférence du DNS chiffré : Apple Private Relay et le DNS privé d'Android (DoT/DoH) peuvent intercepter les requêtes DNS sur les SSID invités, en contournant les politiques de filtrage locales.

Foire aux questions sur la vitesse du DNS