Si un serveur DNS recherche un enregistrement manquant, il «cache» de manière négative le fait que cet enregistrement est manquant et n'essaie pas de le rechercher à nouveau pendant un certain temps. Je ne vois rien dans la RFC à propos de la durée de vie sur la mise en cache négative, alors je suppose que c'est quelque peu arbitraire. Dans le monde réel, combien de temps ces disques négatifs restent-ils?
domain-name-system
Léopd
la source
la source
Réponses:
La durée de vie pour la mise en cache négative n'est pas arbitraire. Il provient de l'enregistrement SOA situé en haut de la zone à laquelle l'enregistrement demandé aurait appartenu, s'il avait existé. Par exemple:
La dernière valeur de l'enregistrement SOA ("86400") est la durée pendant laquelle on demande aux clients de mettre en cache les résultats négatifs
example.org..Si un client le demande
doesnotexist.example.org., il mettra le résultat en cache pendant 86400 secondes.la source
MIN(SOA TTL, SOA.MINIMUM), pas simplementSOA.MINIMUM. (Voir tools.ietf.org/html/rfc2308#section-5 )Cela dépend de votre définition exacte d'une "requête négative", mais dans les deux cas, cela est décrit dans la norme rfc2308 «Mise en cache négative des requêtes DNS (DNS NCACHE)» :
NXDOMAINNXDOMAIN, la réponse sera accompagnée d'unSOAenregistrement contenant leNXDOMAINTTL (traditionnellement appeléMINIMUMchamp).rfc2308#section-4SERVFAILSi la résolution n'aboutit pas et entraîne un délai d'expiration (
SERVFAIL) , elle peut également ne pas être mise en cache du tout et, dans tous les cas, NE DOIT PAS être mise en cache plus de 5 minutes.rfc2308#section-7.1Notez que, dans la pratique, la mise en cache de ces résultats pendant le maximum de 5 minutes est un excellent moyen de diminuer l'expérience d'un client si son serveur de cache devait parfois subir de brefs problèmes de connectivité (et le rendre facilement vulnérable à une amplification de déni de service, quelques secondes d’indisponibilité auraient pour effet de bloquer certaines parties du DNS pendant cinq minutes complètes).
Avant BIND 9.9.6-S1 (publié en 2014), apparemment,
SERVFAILn'était pas du tout caché .a878301(2014-09-04)Par exemple, au moment de votre question et dans toutes les versions de BIND publiées avant 2014, le résolveur récursif de BIND ne mettait pas en cache
SERVFAIL, si la validation ci-dessus et la documentation relative à la première introduction de 9.9.6-S1 devaient être mises en mémoire. .Dans la dernière version de BIND, la valeur par défaut
servfail-ttlest1set le paramètre est codé en dur jusqu'à un plafond de30s(à la place du plafond obligatoire de RFC300s).90174e6(2015-10-17)En outre, voici quelques citations remarquables à ce sujet:
En résumé, une
NXDOMAINréponse serait mise en cache comme spécifié dans laSOAzone applicable, alors qu'ilSERVFAILest peu probable qu'elle soit mise en cache ou, si elle est mise en cache, le nombre de secondes sera au plus égal à deux chiffres.la source
Une RFC est dédiée à ce sujet: RFC 2308 - Mise en cache négative de requêtes DNS (DNS NCACHE) .
La section pertinente à lire est 5 - Mise en cache des réponses négatives qui indique:
Tout d'abord, identifions le
SOA.MINIMUMet la SOA TTL décrits dans le RFC. Le TTL est le numéro précédant le type d'enregistrementIN(900secondes dans l'exemple ci-dessous). Tant que le minimum est le dernier champ de l’enregistrement (86400secondes dans l’exemple ci-dessous).Voyons maintenant quelques exemples. La
serverfault.comzone est illustrative car elle possède des serveurs faisant autorité de deux fournisseurs différents configurés différemment.Permet de trouver les serveurs de noms faisant autorité pour la
serverfault.comzone:Vérifiez ensuite l'enregistrement SOA à l'aide d'un serveur de noms aws:
Nous pouvons voir que la durée de vie de l'enregistrement SOA est en
900secondes, tandis que la valeur de durée de vie négative est en86400secondes. La valeur de la durée de vie SOA900étant inférieure, nous nous attendons à ce que cette valeur soit utilisée.Maintenant, si nous interrogons un serveur faisant autorité pour un domaine inexistant, nous devrions obtenir une réponse sans réponse et avec un enregistrement SOA dans la section autorité:
Lorsqu'un résolveur récursif (mise en cache) reçoit cette réponse, il analyse l'enregistrement SOA dans le fichier
AUTHORITY SECTIONet utilise la durée de vie de cet enregistrement pour déterminer la durée pendant laquelle le résultat négatif doit être mis en cache (900secondes dans ce cas ).Suivons maintenant la même procédure avec un serveur de noms Google:
Vous pouvez constater que les serveurs de noms Google ont des valeurs différentes pour les valeurs TTL SOA et TTL négative. Dans ce cas, la durée de vie négative de
300est inférieure à la durée de vie SOA de21600. Par conséquent, le serveur Google doit utiliser la valeur inférieure de l'AUTHORITY SECTIONenregistrement SOA lors du renvoi d'uneNXDOMAINréponse:Comme prévu, la durée de vie de l'enregistrement SOA dans la
NXDOMAINréponse est de300quelques secondes.L'exemple ci-dessus montre également à quel point il est facile d'obtenir différentes réponses à la même requête. La réponse utilisée par un résolveur de mise en cache individuel est déterminée par la requête de namserver faisant autorité.
Lors de mes tests, j'ai également constaté que certains résolveurs récursifs (mise en cache) ne renvoient pas
AUTHORITY SECTIONun enregistrement avec un enregistrement SOA avec une durée de vie décrémentée pour les requêtes suivantes, contrairement à d'autres.Par exemple, le résolveur cloudflare fait (notez la valeur de décrémentation TTL):
Alors que le résolveur par défaut dans un AWS VPC répondra avec une section d'autorité uniquement à la première requête:
Remarque: cette réponse concerne le comportement des
NXDOMAINréponses.Glossaire:
la source