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?

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:

example.org.    IN      SOA     master-ns1.example.org. Hostmaster.example.org. (
            2012091201 43200 1800 1209600 86400 )

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.

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)» :

NXDOMAIN

• Si la résolution aboutit et aboutit NXDOMAIN, la réponse sera accompagnée d'un SOAenregistrement contenant le NXDOMAINTTL (traditionnellement appelé MINIMUMchamp). rfc2308#section-4

SERVFAIL

• Si 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.1

  Notez 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-ttlest 1set le paramètre est codé en dur jusqu'à un plafond de 30s(à la place du plafond obligatoire de RFC 300s). 90174e6(2015-10-17)

  En outre, voici quelques citations remarquables à ce sujet:

  • https://kb.isc.org/article/AA-01178/ (2014 / 2016-01-07)

  Le résultat de la mise en cache des réponses SERVFAIL a inclus certaines situations dans lesquelles il était perçu comme préjudiciable à l'expérience client, en particulier lorsque les causes de la présentation de SERVFAIL au client étaient transitoires et d'un scénario dans lequel une nouvelle tentative immédiate de la requête constituerait un problème. action plus appropriée.

  • http://cr.yp.to/djbdns/third-party.html (2003-01-11)

  La deuxième tactique consiste à affirmer que les clients DNS répandus feront quelque chose de particulièrement diabolique lorsqu'ils ne pourront pas atteindre tous les serveurs DNS. Le problème avec cet argument est que l'affirmation est fausse. Un tel client est clairement bogué et sera incapable de survivre sur le marché: réfléchissez à ce qui se passe si les routeurs du client tombent brièvement en panne ou si son réseau est inondé temporairement.

En résumé, une NXDOMAINréponse serait mise en cache comme spécifié dans la SOAzone applicable, alors qu'il SERVFAILest 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.

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:

Comme les réponses normales, les réponses négatives ont un temps de vivre (TTL). Comme il n'y a pas d'enregistrement dans la section de réponse à laquelle cette TTL peut être appliquée, la TTL doit être acheminée par une autre méthode. Ceci est fait en incluant l'enregistrement SOA de la zone dans la section autorité de la réponse. Lorsque le serveur faisant autorité crée cet enregistrement, sa durée de vie est calculée à partir du minimum du champ SOA.MINIMUM et de la durée de vie de la SOA. Cette durée de vie décroît de la même manière qu'une réponse en cache normale et, une fois que zéro (0) est atteint, indique que la réponse négative en cache NE DOIT PAS être utilisée à nouveau.

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'enregistrement IN( 900secondes dans l'exemple ci-dessous). Tant que le minimum est le dernier champ de l’enregistrement ( 86400secondes dans l’exemple ci-dessous).

$ dig serverfault.com soa @ns-1135.awsdns-13.org +noall +answer +multiline

; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> serverfault.com soa @ns-1135.awsdns-13.org +noall +answer +multiline
;; global options: +cmd
serverfault.com.    900 IN SOA ns-1135.awsdns-13.org. awsdns-hostmaster.amazon.com. (
                1          ; serial
                7200       ; refresh (2 hours)
                900        ; retry (15 minutes)
                1209600    ; expire (2 weeks)
                86400      ; minimum (1 day)
                )

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:

$ host -t ns serverfault.com
serverfault.com name server ns-860.awsdns-43.net.
serverfault.com name server ns-1135.awsdns-13.org.
serverfault.com name server ns-cloud-c1.googledomains.com.
serverfault.com name server ns-cloud-c2.googledomains.com.

Vérifiez ensuite l'enregistrement SOA à l'aide d'un serveur de noms aws:

$ dig serverfault.com soa @ns-1135.awsdns-13.org | grep 'ANSWER SECTION' -A 1
;; ANSWER SECTION:
serverfault.com.    900 IN  SOA ns-1135.awsdns-13.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

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 en 86400secondes. La valeur de la durée de vie SOA 900é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é:

$ dig nxdomain.serverfault.com @ns-1135.awsdns-13.org

; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> nxdomain.serverfault.com @ns-1135.awsdns-13.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51948
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nxdomain.serverfault.com.  IN  A

;; AUTHORITY SECTION:
serverfault.com.    900 IN  SOA ns-1135.awsdns-13.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

;; Query time: 125 msec
;; SERVER: 205.251.196.111#53(205.251.196.111)
;; WHEN: Tue Aug 20 15:49:47 NZST 2019
;; MSG SIZE  rcvd: 135

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:

$ dig serverfault.com soa @ns-cloud-c2.googledomains.com | grep 'ANSWER SECTION' -A 1
;; ANSWER SECTION:
serverfault.com.    21600   IN  SOA ns-cloud-c1.googledomains.com. cloud-dns-hostmaster.google.com. 1 21600 3600 259200 300

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 de 21600. Par conséquent, le serveur Google doit utiliser la valeur inférieure de l' AUTHORITY SECTIONenregistrement SOA lors du renvoi d'une NXDOMAINréponse:

$ dig nxdomain.serverfault.com @ns-cloud-c2.googledomains.com

; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> nxdomain.serverfault.com @ns-cloud-c2.googledomains.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 25920
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;nxdomain.serverfault.com.  IN  A

;; AUTHORITY SECTION:
serverfault.com.    300 IN  SOA ns-cloud-c1.googledomains.com. cloud-dns-hostmaster.google.com. 1 21600 3600 259200 300

;; Query time: 130 msec
;; SERVER: 216.239.34.108#53(216.239.34.108)
;; WHEN: Tue Aug 20 16:05:24 NZST 2019
;; MSG SIZE  rcvd: 143

Comme prévu, la durée de vie de l'enregistrement SOA dans la NXDOMAINréponse est de 300quelques 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):

$ dig nxdomain.serverfault.com @1.1.1.1 | grep 'AUTHORITY SECTION' -A 1
;; AUTHORITY SECTION:
serverfault.com.    674 IN  SOA ns-1135.awsdns-13.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
$ dig nxdomain.serverfault.com @1.1.1.1 | grep 'AUTHORITY SECTION' -A 1
;; AUTHORITY SECTION:
serverfault.com.    668 IN  SOA ns-1135.awsdns-13.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

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:

$ dig nxdomain.serverfault.com @169.254.169.253 | grep 'AUTHORITY SECTION' -A 1
;; AUTHORITY SECTION:
serverfault.com.    300 IN  SOA ns-cloud-c1.googledomains.com. cloud-dns-hostmaster.google.com. 1 21600 3600 259200 300
$ dig nxdomain.serverfault.com @169.254.169.253 | grep 'AUTHORITY SECTION' -A 1 | wc -l
0

Remarque: cette réponse concerne le comportement des NXDOMAINréponses.

Glossaire:

• Zone
• SOA
• TTL
• NameServer récursif
• Serveur de noms faisant autorité