Membre depuis le 02/05/2024
yo la team gros pépin de DNS. j'ai des services en k8s qui doivent résoudre des noms d'hôtes sur notre infra on-prem et inversement. des fois ça marche nickel des fois timeout ou host not found. c'est totalement aléatoire aucune logique. j'ai le coredns de k8s qui forward vers nos DNS on-prem. des idées pour ce genre de truc ?
# CoreDNS config example
.:53 {
errors
health
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
}
forward . 10.0.0.1 10.0.0.2 {
force_tcp
prefer_udp
}
cache 30
reload
hosts /etc/coredns/hosts {
fallthrough
}
}
Vous devez être connecté pour poster un message !
Recevoir les derniers articles gratuitement en créant un compte !
S'inscrire
Commentaires
maggie84
Membre depuis le 21/07/2024
vérifie si tes serveurs DNS on-prem sont pas surchargés quand ça merde. des fois le coredns balance trop de requêtes et ils galèrent. regarde leurs logs et la charge réseau. le prefer_udp est ok mais si les réponses sont grosses ça peut foirer en udp et force_tcp est là pour ça
menard-noemi
Membre depuis le 10/11/2024
et tes serveurs DNS on-prem ils voient bien les requêtes de coredns ? y'a pas de firewall au milieu qui droppe aléatoirement des paquets ? t'as essayé un tcpdump sur le serveur DNS on-prem pendant que tu as le souci ?
ubigot
Membre depuis le 02/05/2024
les serveurs on-prem ont l'air ok pas de surcharge. et les firewalls sont censés être ouverts partout. tcpdump bonne idée j'ai pas pensé. je vais faire ça pour voir si les requêtes arrivent bien et si les réponses partent
maggie84
Membre depuis le 21/07/2024
des fois aussi c'est un problème de TTL trop bas ou trop haut. si le cache de coredns est trop agressif ou si tes enregistrements on-prem ont des TTL super courts ça peut créer de la danse bizarre entre le cache et les requêtes directes
ubigot
Membre depuis le 02/05/2024
après le tcpdump il semble que les requêtes arrivent bien sur les serveurs on-prem mais certaines réponses sont pas renvoyées ou sont corrompues. le firewall est bon. en fait c'était un vieux load balancer dns qui merdait sur un de nos dns on-prem et balançait des requêtes dans le vide. on l'a désactivé et tout est stable. merci !