Squid Split DNS : acheminer les domaines privés par le bon résolveur

Placer un résolveur interne en premier et un résolveur public en second n'indique pas à Squid quels noms appartiennent à quel espace de noms.

Dans Squid 6 et 7, dns_nameservers remplace la liste habituelle de résolveurs par des adresses de serveurs. Sa syntaxe n'offre aucune correspondance par domaine. Une réponse négative valide diffère aussi d'un résolveur injoignable, si bien que les solutions de repli ne constituent pas un moyen fiable d'explorer des espaces de noms incompatibles.

Acheminer les requêtes par domaine

Un redirecteur DNS local peut exprimer la politique manquante. Dans une configuration dnsmasq existante, un suffixe privé peut être acheminé ainsi :

server=/internal.example/192.0.2.53

Remplacez le domaine et l'adresse. Configurez un upstream par défaut approuvé pour les autres noms, un écouteur adapté et des restrictions d'accès. Pointez ensuite Squid vers ce résolveur avec la configuration prise en charge par la version installée.

Sinon, utilisez un service DNS d'entreprise qui résout correctement les deux espaces de noms. Évitez un repli public qui exposerait des noms privés sans pouvoir y répondre.

Si un proxy parent effectue la résolution de destination, ce saut a besoin de l'espace de noms privé. Un résolveur sur l'hôte Squid local ne corrigera pas la résolution du parent.

Vérifiez aussi le cas négatif

Choisissez un nom privé valide, un nom public valide et un nom privé inexistant. Pour chacun, identifiez l'upstream prévu et si la réponse attendue est une adresse ou une réponse négative. Le dernier cas révèle un repli public accidentel après une réponse négative interne.

Incluez les familles d'adresses exigées par le client. Une résolution A fonctionnelle ne prouve pas que AAAA suit la politique ni qu'elle renvoie une destination joignable. Notez aussi l'état du cache : une réponse mise en cache peut masquer quel upstream une requête fraîche choisirait.