Si aucun des serveurs de toute la zone ne peut être contacté, combien de temps un tel fait sera-t-il mis en cache ?
Selon le rfc2308#section-7.1 de 1998-03, si la résolution n'est pas réussie et se traduit par un SERVFAIL (par exemple, à cause d'un délai d'attente), alors cela PEUT être mis en cache, mais dans ce cas, il NE DOIT PAS être mis en cache pendant plus de 5 minutes.
En pratique, il semble souvent ne pas être mis en cache du tout, ou, s'il est mis en cache, l'est pour une durée purement symbolique, comme une seconde seulement.
Avant BIND 9.9.6-S1 (publié en 2014), apparemment, le SERVFAIL n'était pas mis en cache du tout.
Cela a été introduit avec le commit a878301 (2014-09-04).
Par exemple, au moment de cette question et dans toutes les versions de BIND publiées avant 2014, le résolveur récursif BIND NE METTAIT PAS le SERVFAIL en cache, si l'on croit le commit ci-dessus et la documentation sur la première introduction dans 9.9.6-S1.
Dans la dernière version de BIND, le réglage par défaut de servfail-ttl a été défini à 1s depuis 2015 (en 2016), et a été codé en dur avec un plafond de 30s (au lieu du plafond de 300s imposé par la RFC).
Voir commit 90174e6 (2015-10-17).
En 2014/2015, la durée par défaut était de 10s, et le plafond était de 300s, mais, selon les citations ci-dessous, les chiffres plus élevés étaient jugés excessivement pessimistes.
Références notables (avec les citations respectives) incluent:
https://kb.isc.org/article/AA-01178/ (2014/2016-01-07)
Les conséquences de la mise en cache des réponses SERVFAIL ont inclu certaines situations où cela a été jugé préjudiciable à l'expérience du client, en particulier lorsque les causes du SERVFAIL présenté au client étaient transitoires et dans un scénario où une nouvelle tentative immédiate de la requête aurait été une action plus appropriée.
http://cr.yp.to/djbdns/third-party.html (2003-01-11)
La deuxième tactique est d'affirmer que les clients DNS largement utilisés feront quelque chose de particulièrement maléfique lorsqu'ils ne peuvent pas atteindre tous les serveurs DNS. Le problème avec cet argument est que l'affirmation est fausse. Tout client de ce type est clairement défectueux et ne pourra pas survivre sur le marché : imaginez ce qui se passe si les routeurs du client tombent brièvement en panne, ou si le réseau du client est temporairement saturé.
En résumé, il est improbable que le SERVFAIL soit mis en cache, mais même s'il l'est, ce sera pour un nombre de secondes à peine en double ou en chiffre unique.
Dans BIND 9.11, une réponse SERVFAIL est mise en cache pendant 1 seconde par défaut.
De la Référence du Manuel de l'Administrateur BIND :
servfail-ttl
Définit le nombre de secondes pour mettre en cache une réponse SERVFAIL en raison d'un échec de validation DNSSEC ou d'une défaillance générale du serveur. Si défini à 0, le cache de SERVFAIL est désactivé. Le cache de SERVFAIL n'est pas consulté si une requête a le bit CD (vérification désactivée) défini ; cela permet à une requête qui a échoué en raison d'une validation DNSSEC d'être réessayée sans attendre que le TTL de SERVFAIL expire.
La valeur maximale est de 30 secondes ; toute valeur plus élevée sera réduite silencieusement. La valeur par défaut est de 1 seconde.
Ceci est implémenté conformément à RFC 2308, bien que dans la pratique les délais d'attente maximaux spécifiés aient été jugés problématiques, d'où la valeur par défaut actuelle.
Merci pour la réponse, cela fait seulement 3 ans que cette question existe, et de nombreuses réponses erronées ont été fortement critiquées et supprimées il y a 3 ans !
Hé, apparemment, il y a 3 ans, toute cette chose n'existait même pas - serveurdefichier.com/a/824873/110020
Selon http://cr.yp.to/djbdns/third-party.html
RFC 2182 affirme que les échecs de DNS ne sont pas mis en cache; cette affirmation est fausse.
Qui a voté négativement pour cela ? Je l'accepte, car cela semble être la réponse la plus correcte jusqu'à présent.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
