9 commentaires
ouais clock skew c'est classique. sinon t'as essayé de vérifier la zone avec un outil genre dnssec-debugger.verisignlabs.com ou zonemaster.net ? ça te dira direct où ça coince.
horloge synchro avec ntp niquel. les outils externes disent que les zones sont ok. le problème est vraiment sur nos résolveurs internes. par contre on a des forwarding rules vers les dns de notre opérateur. ptete qu'eux ils sont pas dnssec aware ?
si ton forwarder ne fait pas dnssec ou le strip ça va te poser pb c'est sûr. soit tu le bypasses et tu fais la validation directement depuis ton bind soit tu t'assures que ton forwarder est full dnssec. t'as une option
dnssec-validation auto;dnssec-enable yes;attention si tu fais la validation toi-même il faut que t'aies les racines à jour les trust anchors.
bind keys { initial-key id_root; };managed-keys { "..." };oui les
dnssec-validation auto;dnssec-enable yes;managed-keysun truc bête mais la taille des paquets udp. si t'as des gros enregistrements dnssec ça peut dépasser la taille max d'un paquet udp non fragmenté (genre 512 bytes sans edns0, 1280 ou 1500 avec). ça force au tcp. t'as pas un fw qui bloque le tcp 53 ?
bingo les gars ! c'était bien le tcp 53 que le fw bloquait en sortie vers nos forwarders externes. certains enregistrements dnssec sont trop gros pour l'udp only. une fois ouvert ça valide niquel. merci bcp.
Laisser une réponse
Vous devez être connecté pour poster un message !
yo la team ! galère avec dnssec nos clients internes voient des servs down mais c pas le cas. après analyse nos dns resolvers internes (bind) foirent la validation dnssec pour certains domaines externes. on a des messages "SERVFAIL" avec "RRSIG not found" ou "NSEC3 missing". on utilise bind 9.16.