Quand Squid ne parvient pas à résoudre un nom d’hôte

Examinez le DNS là où la résolution échoue. Que votre portable résolve un nom ne prouve pas que Squid, ou un proxy parent établissant la connexion suivante, puisse le résoudre.

Consultez le journal de cache de l’instance en échec et les paramètres du résolveur du serveur. Voici une vérification complémentaire au niveau de l’hôte :

getent ahosts target.example

Utilisez la cible réelle. getent sollicite le mécanisme de résolution de l’hôte ; le résolveur interne ou le cache de Squid peut différer. Examinez les entrées explicites dns_nameservers et hosts_file avant de supposer leur concordance.

Dans Squid 6.13, une liste explicite de serveurs de noms contient des adresses IP :

dns_nameservers 192.0.2.53

Remplacez cette adresse de documentation par un résolveur approuvé et accessible depuis le serveur Squid. Les noms privés peuvent nécessiter le résolveur de l’organisation ; un résolveur public sans lien avec elle peut ne pas les voir dans sa vue DNS.

Un alias du fichier hosts du portable n’accompagne pas une requête par nom d’hôte passant par le proxy. Sur la machine qui effectue la résolution, examinez le paramètre hosts_file de la version de Squid installée et tenez compte du résolveur d’un parent le cas échéant. Le nom d’hôte utilisé pour l’identité TLS doit rester cohérent avec le service.

Après une seule modification contrôlée de la configuration, vérifiez sa syntaxe et rechargez l’instance voulue, répétez la même requête et examinez les éléments correspondants. Les réponses positives et négatives en cache peuvent influer sur les essais répétés. Une résolution réussie suivie d’un délai de connexion dépassé relève d’un échec ultérieur de routage ou d’autorisation ; ne continuez pas à modifier le DNS pour le corriger. Gardez le DNS client, le routage parent et le protocole proxy constants pendant l’évaluation de la modification du serveur.