L’erreur curl: (6) Could not resolve host signifie que cURL n’a pas pu résoudre le nom d’hôte demandé. Elle peut interrompre une mise à jour, un téléchargement ou une connexion à une API. Elle ne prouve pas, à elle seule, que votre serveur DNS est défectueux.
Sur un hébergement Nuagerie, commencez par relever l’erreur et son contexte. Ne modifiez pas la configuration réseau du serveur pour corriger une erreur isolée. Les vérifications ci-dessous permettent de transmettre une demande utile à notre équipe ou à l’administrateur concerné.
1. Identifier précisément l’erreur
La référence officielle de libcurl distingue plusieurs situations :
- 5 : résolution du nom du proxy impossible.
- 6 : résolution du nom d’hôte distant impossible.
- 7 : connexion impossible à l’hôte ou au proxy.
- 28 : délai dépassé, y compris éventuellement pendant la résolution DNS.
- 35 ou 60 : problème de négociation TLS ou de vérification du certificat.
Conservez le code et le message complets. Ajouter -k à cURL désactive une vérification de certificat et ne corrige pas une erreur DNS.
2. Vérifier le nom réellement utilisé
Comparez le nom indiqué dans l’erreur à la documentation actuelle du service : faute de frappe, adresse de téléchargement abandonnée, espace ajouté ou variable d’environnement mal remplacée peuvent expliquer l’échec. Une URL globalement mal formée peut aussi produire une autre erreur, notamment le code 3.
Dans une commande, placez l’URL entre guillemets adaptés au shell, par exemple 'https://example.com/' pour une adresse littérale. Cela évite que des caractères de l’URL soient interprétés comme des instructions. Vérifiez également les redirections et la présence d’un proxy configuré par l’application ou son environnement, sans afficher ses identifiants.
Pour un téléchargement cPanel, vérifiez la commande proposée dans la documentation actuelle de cPanel. Ne remplacez pas le domaine par une adresse IP trouvée au hasard et ne réutilisez pas automatiquement une ancienne commande d’installation.
3. Distinguer les deux rôles du DNS
Les serveurs DNS faisant autorité publient les enregistrements d’un domaine. Le résolveur récursif utilisé par votre ordinateur ou serveur recherche les réponses pour ses applications et peut les conserver en cache. Ce sont des rôles distincts, décrits dans la terminologie DNS de l’IETF.
Si une application ne résout pas le domaine d’un fournisseur, changer les nameservers de votre propre domaine chez le registraire ne répare généralement pas cette connexion sortante. Si l’enregistrement manquant concerne votre domaine, son gestionnaire DNS doit plutôt vérifier la zone et la délégation.
4. Effectuer des vérifications ciblées
Ces exemples sont facultatifs, pour un environnement Linux où vous disposez d’un terminal autorisé et des outils nécessaires, dont GNU timeout. Sur un hébergement partagé, demandez notre aide si cet accès n’est pas disponible. Remplacez example.com par le nom public concerné, sans protocole ni chemin.
curl --version
timeout --kill-after=2s 10s getent ahosts example.com
timeout --kill-after=2s 10s dig -r +time=3 +tries=1 example.com A
timeout --kill-after=2s 10s dig -r +time=3 +tries=1 example.com AAAA
Ces commandes ne modifient pas la configuration et n’effectuent aucun téléchargement HTTP. timeout limite l’attente de chaque diagnostic; une interruption par cet outil ne constitue pas un code de réponse DNS.
- getent interroge les mécanismes de résolution configurés dans le système, qui peuvent inclure des sources autres que le DNS.
- dig effectue une requête DNS. Ici,
-rignore les préférences personnelles de son fichier de configuration. - A demande les adresses IPv4 et AAAA les adresses IPv6. L’absence d’AAAA n’empêche pas nécessairement une connexion IPv4.
Gardez le statut et le serveur interrogé dans le résultat. Testez depuis l’environnement touché : une réussite sur votre ordinateur ne prouve pas que le serveur de votre site obtient la même réponse.
5. Comprendre les résultats
- NXDOMAIN : le nom demandé est annoncé inexistant. Vérifiez son orthographe, sa validité et les enregistrements auprès du gestionnaire du domaine.
- SERVFAIL : la requête n’a pas pu être traitée correctement. Une panne des serveurs faisant autorité, une délégation incorrecte ou une validation DNSSEC en échec peuvent être en cause.
- NOERROR sans adresse utile : examinez le type demandé, les alias et la réponse complète. Un nom peut exister sans enregistrement A ou AAAA utilisable dans le contexte de l’application.
- Aucune réponse ou délai dépassé : faites vérifier l’accès au résolveur et le transport DNS par l’administrateur réseau. Cela ne démontre pas que le site distant est hors service.
Une différence entre résolveurs peut venir du cache, d’un filtrage ou de la configuration du domaine. La documentation de diagnostic de Google détaille notamment les problèmes de délégation et de DNSSEC. Ne désactivez pas DNSSEC ou le pare-feu pour contourner le symptôme.
6. Si le terminal fonctionne, mais pas l’application
Le cURL du terminal et l’extension cURL de PHP peuvent utiliser des versions ou réglages différents. Une tâche planifiée, un conteneur ou un processus web peut aussi avoir un environnement réseau, un proxy ou une configuration DNS distincts. Libcurl peut utiliser différents mécanismes de résolution, dont c-ares ou DNS sur HTTPS selon sa compilation et ses options.
Faites comparer le nom effectivement demandé, la version de libcurl utilisée par l’application, les paramètres IPv4/IPv6 et les caches concernés. Le développeur peut recueillir ces renseignements dans un diagnostic privé; il n’est pas nécessaire de publier une page phpinfo() ou des journaux détaillés.
7. Choisir un résolveur adapté au service
- Ordinateur ou réseau de bureau : vérifiez d’abord les paramètres du routeur, du fournisseur Internet et, s’il y en a un, du VPN.
- Serveur hébergé ou VPS : demandez au fournisseur les résolveurs recommandés et les contraintes de son réseau.
- Réseau privé ou environnement infonuagique : préservez la résolution des noms internes et les règles de transmission conditionnelle. Un résolveur public ajouté comme « secondaire » ne remplace pas ces règles.
Pour un usage compatible et autorisé, les adresses IPv4 standard sont 8.8.8.8 et 8.8.4.4 pour Google Public DNS, et 1.1.1.1 et 1.0.0.1 pour Cloudflare 1.1.1.1. Leurs pages officielles indiquent aussi les adresses IPv6. Ce sont des options possibles, pas une correction universelle. N’envoyez pas de noms internes à un résolveur public.
Pour un nom public uniquement, si votre réseau l’autorise, comparez les réponses A sans changer les paramètres du système :
timeout --kill-after=2s 10s dig -r @1.1.1.1 +time=3 +tries=1 example.com A
timeout --kill-after=2s 10s dig -r @8.8.8.8 +time=3 +tries=1 example.com A
Remplacez le nom d’exemple. Une réussite ici ne prouve pas que remplacer votre résolveur est la bonne correction.
Sur un serveur cPanel utilisant des listes de blocage DNS pour le courriel, le choix peut affecter les vérifications antispam. cPanel recommande les résolveurs du fournisseur dans ce contexte. Certaines listes peuvent refuser les requêtes provenant de résolveurs publics; une réponse de refus n’est pas un résultat fiable sur la réputation d’un expéditeur.
8. Corriger la configuration au bon endroit
Dans /etc/resolv.conf, le mot-clé valide est nameserver, suivi de l’adresse IP du résolveur. Les mots-clés de configuration ne doivent pas être traduits. La référence de resolv.conf décrit sa syntaxe.
Ce fichier peut être généré par le gestionnaire réseau ou pointer vers un service de résolution local. Une adresse de boucle locale n’est donc pas automatiquement une erreur. L’administrateur doit identifier le mécanisme responsable, conserver les paramètres précédents et appliquer une modification réversible par la méthode adaptée. Écraser ce fichier peut casser la résolution interne ou être annulé au prochain renouvellement réseau.
9. Obtenir de l’aide efficacement
Dans votre espace client Nuagerie, précisez le service touché, l’heure avec le fuseau, le nom demandé, le code d’erreur, l’application et les changements récents. Joignez les résultats utiles après avoir retiré mots de passe, jetons, adresses privées et paramètres sensibles des URL.
Ces éléments nous aident à orienter l’analyse vers l’application, le domaine ou le réseau concerné. Pour une infrastructure externe ou un besoin d’accompagnement technique, utilisez notre formulaire de contact afin de définir le périmètre de l’intervention.
