Vérifier d’abord l’adresse et l’étendue du problème
Le DNS associe notamment un nom de domaine à des adresses réseau. Une erreur de résolution peut empêcher de trouver le service, mais un chargement interrompu peut aussi venir du site, du navigateur ou de la connexion. Recopiez le message exact et contrôlez l’adresse, en particulier un lien ancien ou une faute de frappe.
Ouvrez deux autres sites que vous utilisez habituellement. Si un seul domaine échoue, notez-le séparément. Cette comparaison ne prouve pas que le service est en panne ; elle évite de traiter un problème limité comme une coupure générale. Ne modifiez pas tous les appareils du foyer pour ce premier essai.
Construire une comparaison utile
Sur le même appareil et le même Wi-Fi, essayez un autre navigateur avec l’adresse identique. Puis utilisez un second appareil sur ce réseau. Gardez l’heure et les résultats dans la fiche de tests ; un changement de site, de réseau et de navigateur à la fois rend l’interprétation plus difficile.
Si vous disposez d’une connexion mobile, comparez le même domaine sur le téléphone en vérifiant le réseau réellement utilisé. Un résultat différent oriente vers le trajet ou la configuration, sans identifier à lui seul le responsable. Un service peut répondre différemment selon les accès et les régions.
Distinguer les réglages du système et du navigateur
Certains navigateurs proposent le DNS via HTTPS et peuvent employer une configuration distincte de celle du système. La documentation Mozilla décrit aussi ses interactions avec les réseaux administrés et les dispositifs de filtrage. Relevez si cette fonction ou un fournisseur personnalisé est activé dans votre navigateur.
Si vous gérez l’appareil, utilisez la procédure documentée pour un essai réversible et notez la valeur de départ. Sur un poste professionnel, demandez au service informatique quels réglages sont attendus : un domaine interne et un site public ne répondent pas nécessairement au même parcours DNS. Un nouveau fournisseur DNS n’est pas une réparation universelle.
Garder une conclusion limitée à ce qui a été testé
Exemple fictif : un domaine fonctionne dans un navigateur et échoue dans l’autre sur le même ordinateur. Ce résultat donne une piste côté navigateur ou réglage associé, mais ne suffit pas à déclarer le DNS de la box défectueux. Consignez aussi les extensions ou le VPN présents pour le support.
Une page ouverte directement par adresse IP n’est pas un test universel : un service peut dépendre du nom demandé et de sa configuration HTTPS. Ne contournez pas une alerte de certificat pour conclure le diagnostic. Transmettez l’adresse, le message, les comparaisons et les réglages observés au support adapté.
Une réponse DNS reçue peut encore être un échec
Relevez le code de réponse au lieu de noter seulement « DNS ne marche pas ». Un SERVFAIL mérite un contrôle du résolveur et, pour un domaine signé, de la validation DNSSEC. Comparez le nom exact sur le système et dans un navigateur qui peut utiliser son propre DNS chiffré.
Un changement de résolveur peut modifier le résultat sans corriger la cause publiée par le domaine. Si vous gérez celui-ci, faites vérifier la chaîne de confiance. Sur un accès IPv6 seul, vérifiez aussi si le DNS recommandé assure une fonction DNS64 avant de le remplacer.
Questions fréquentes
Changer le DNS accélère-t-il tous les téléchargements ?
La résolution du nom et le transfert du fichier sont deux opérations différentes. Un réglage DNS ne supprime pas une limitation de débit du Wi-Fi, du câble ou du serveur de téléchargement.
Pourquoi un seul navigateur affiche-t-il une erreur ?
Il peut avoir ses propres paramètres DNS, proxy ou extensions. Comparez la même adresse sur le même réseau et consultez sa documentation avant de modifier la box.
Faut-il mettre un DNS public sur un ordinateur professionnel ?
Utilisez la configuration prévue par votre organisation. Les services internes et les règles de filtrage peuvent dépendre du DNS administré ; transmettez vos observations au support informatique.