dns split-horizon qui déraille sur des pods k8s

RSS
guy-bonneau 17/10/2025
RÉSOLU
Retour Répondre
Avatar de guy-bonneau
guy-bonneau
Auteur Actif
Avatar de guy-bonneau
guy-bonneau
Auteur Actif

yo la team j'ai un souci bizarre avec le dns de notre cluster k8s. on a un service (service-a) qui doit résoudre un nom interne (monapp.internal.domain) vers une IP privée. mais parfois, il résout vers l'IP publique de notre WAN, du coup ça foire complètement. j'ai bien configuré les coredns avec un forwarder pour monapp.internal.domain vers nos dns internes on-prem. les autres services ça marche nickel.

# configmap coredns (extrait)
...
monapp.internal.domain:53 {
    errors
    cache 30
    forward . 10.0.0.10 10.0.0.11 # nos dns internes
}
...

pourtant un dig depuis le pod de service-a montre bien qu'il utilise le coredns du cluster. des idées de où ça peut merder ?

17/10/2025 à 12:34

8 commentaires

Avatar de fmarchal
fmarchal
Membre Actif Secouriste
Avatar de fmarchal
fmarchal
Membre Actif Secouriste

salut t'as check les logs coredns ? des fois ils crachent des erreurs quand ils arrivent pas à joindre les forwarders ou si y'a un timeout. et t'es sûr que le service-a est pas configuré pour utiliser d'autres serveurs dns genre directement en /etc/resolv.conf dans l'image du container ?

18/10/2025 à 11:20
Avatar de guy-bonneau
guy-bonneau
Auteur Actif
Avatar de guy-bonneau
guy-bonneau
Auteur Actif

coredns logs sont clean pas d'erreurs de forwarder le service-a sa résolution se base bien sur coredns j'ai fait des tests. c'est vraiment aléatoire le truc ça marche puis ça foire

19/10/2025 à 09:51
Avatar de julien-paul
julien-paul
Membre
Avatar de julien-paul
julien-paul
Membre

c'est ptete un truc de cache entre coredns et le resolver du pod. ou ptete que tes dns on-prem répondent lentement parfois pour monapp.internal.domain et coredns fallback sur un autre resolver s'il en a un de défini globalement genre le dns du vpc ou de l'isp

20/10/2025 à 04:40
Avatar de fmarchal
fmarchal
Membre Actif Secouriste
Avatar de fmarchal
fmarchal
Membre Actif Secouriste

ouais un timeout est une bonne piste pour le fallback. regarde ton fichier /etc/resolv.conf sur les nodes k8s aussi, si coredns forwarde vers un dns local qui lui-même forwarde, y'a des chances que ça boucle ou prenne trop de temps

21/10/2025 à 02:19
Avatar de lblondel
lblondel
Membre Actif
Avatar de lblondel
lblondel
Membre Actif

vous avez pas un egress policy network qui pourrait bloquer l'accès aux dns internes on-prem de temps en temps depuis coredns ? ça pourrait expliquer l'aléatoire si le traffic est drop et coredns essaie autre chose

21/10/2025 à 21:08
Avatar de guy-bonneau
guy-bonneau
Auteur Actif
Avatar de guy-bonneau
guy-bonneau
Auteur Actif

pas d'egress policy pour coredns l'infra est assez ouverte de ce côté-là. par contre la piste du fallback ou timeout est intéressante. je vais augmenter le timeout du forwarder dans coredns et monitorer les logs dns on-prem

22/10/2025 à 16:15
Avatar de julien-paul
julien-paul
Membre
Avatar de julien-paul
julien-paul
Membre

ouais et check si tes dns on-prem ont pas un souci de synchro entre eux ou de réplication de zone. si monapp.internal.domain est pas toujours dispo sur tous tes forwarders ça peut créer ce genre de bordel

23/10/2025 à 15:34
Avatar de guy-bonneau
guy-bonneau
Auteur Actif
Avatar de guy-bonneau
guy-bonneau
Auteur Actif

Bingo ! c'était un timeout et un fallback implicite. le dns on-prem primaire avait des micro-latences par moment. coredns du coup essayait le suivant qui était le dns de l'infra cloud et renvoyait la mauvaise ip publique. j'ai viré le fallback implicite et j'ai corrigé la latence sur le dns on-prem. thx la team !

24/10/2025 à 14:51

Laisser une réponse

Vous devez être connecté pour poster un message !

Rejoindre la communauté

Recevoir les derniers articles gratuitement en créant un compte !

S'inscrire