DNS interne qui galère à résoudre les nouveaux services

Question

yo la team, j'ai un souci bizarre avec notre DNS interne (bind) sur l'infra on-prem. on déploie de nouveaux services dans le cloud (AWS ECS) via un service discovery et on voudrait que nos services on-prem puissent les résoudre via un enregistrement CNAME ou A.
j'ai bien configuré des forwarders conditionnels pour le domaine cloud vers la resolver privé aws mais les requêtes pour les nouveaux services plantent souvent. les anciens ça va mais les fresh deploys c la galère. ça finit par marcher mais avec un délai de ouf. des pistes ?

# exemple de config named.conf.options
options {
    directory "/var/cache/bind";
    forwarders {
        8.8.8.8;
        8.8.4.4;
    };
    allow-query { any; };
    recursion yes;
    forward only;
};

# exemple de zone pour le forward conditionnel
zone "moncloud.local" {
    type forward;
    forwarders { 10.0.0.2; }; // ip du resolver aws
};

vmoreau · Answer

Salut ! T'as checké les logs de ton bind sur le serveur on-prem ? Des fois c'est juste le cache qui est pas invalide ou une entrée qui est stale. Regarde si t'as des SERVFAIL ou des timeouts sur les requêtes vers 10.0.0.2.

guillaume-marty · Answer

Ouais j'ai fouillé les logs bind ça donne des SERVFAIL parfois mais pas tout le temps et pas d'erreur claire. le resolver aws répond bien quand je le query direct depuis le bind via dig

gvaillant · Answer

hmm ça sent le problème de propagation ou de TTL trop élevés côté cloud qui sont pas respectés par ton bind ou par un cache intermédiaire entre ton bind et tes services on-prem. t'as regardé la config dns des vpc links ou des endpoint services si y'a pas un dns resolver interne qui met le bazar ?

guillaume-marty · Answer

pas de dns resolver intermédiaire en plus. le ttl c'est du 60s pour les nouveaux services. mais ça parait long pour se mettre à jour.

vmoreau · Answer

ok un truc con mais la synchro horaire de ton serveur bind elle est bonne ? si le ntp est à la ramasse ça peut foirer les validités de cache et ttl. Et sinon t'as essayé de vider le cache de bind après un déploiement pour voir si ça force la maj ?

sudo rndc reload
sudo rndc flush

guillaume-marty · Answer

ah ntp j'y ai pas pensé direct mais oui il est synchro. j'ai fait le reload/flush et là... miracle. les nouveaux services popent direct. c'était bien un souci de cache qui collait trop longtemps les entrées même avec un ttl court. merci pour les commandes les gars !

DNS interne qui galère à résoudre les nouveaux services

Commentaires

Laisser une réponse

Création d'une fenêtre et d'un rendu sur la SDL 2

L'histoire du DevOps

Gérer des environnements éphémères sur Kubernetes

Rejoindre la communauté