Cela dépend de votre définition exacte d'une "requête négative", mais dans tous les cas, ceci est documenté dans le document rfc2308 "Mise en cache négative des requêtes DNS (DNS NCACHE)" :

NXDOMAIN

• Si la résolution est réussie, et qu'elle aboutit à NXDOMAIN la réponse sera accompagnée d'un SOA qui contiendrait le NXDOMAIN TTL (traditionnellement connu sous le nom de MINIMUM ). rfc2308#section-4

SERVFAIL

• Si la résolution n'aboutit pas, et entraîne un dépassement de délai ( SERVFAIL ) Dans ce cas, il peut aussi bien ne pas être mis en cache du tout et, en toutes circonstances, il ne DOIT PAS être mis en cache pendant plus de 5 minutes. rfc2308#section-7.1

  Notez qu'en pratique, la mise en cache de tels résultats pendant la totalité des 5 minutes autorisées est un excellent moyen de diminuer l'expérience d'un client si son serveur de cache souffre occasionnellement de brefs problèmes de connectivité (et le rend facilement vulnérable à une amplification du déni de service, où quelques secondes d'interruption entraîneraient l'interruption de certaines parties du DNS pendant les cinq minutes complètes).

  Avant BIND 9.9.6-S1 (publié en 2014), apparemment, SERVFAIL n'a pas été mis en cache du tout. 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 du tout, si les commit ci-dessus et la documentation sur la première introduction en 9.9.6-S1 est à croire.

  Dans la dernière version de BIND, la valeur par défaut servfail-ttl es 1s et le réglage est codé en dur à un plafond de 30s (à la place du plafond imposé par le RFC de 300s ). 90174e6 (2015-10-17)

  En outre, voici quelques citations dignes d'intérêt sur le 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 où il a été considéré comme nuisant à l'expérience du client, en particulier lorsque les causes du SERVFAIL présenté au client étaient transitoires et d'un scénario où une nouvelle tentative immédiate de la requête serait une action plus appropriée.

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

    La deuxième tactique consiste à prétendre que les clients DNS répandus feront quelque chose de particulièrement maléfique lorsqu'ils ne pourront 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 bogué et ne pourra pas survivre sur le marché : considérez ce qui se passe si les routeurs du client tombent brièvement en panne, ou si le réseau du client est temporairement inondé.

En résumé, un NXDOMAIN sera mise en cache comme spécifié dans la directive SOA de la zone applicable, alors que SERVFAIL n'est pas susceptible d'être mis en cache, ou, s'il l'est, cela prendra au maximum un nombre de secondes à deux chiffres.

Il existe un RFC consacré à ce sujet : RFC 2308 - Mise en cache négative des requêtes DNS (DNS NCACHE) .

La section pertinente à lire est la suivante 5 - Mise en cache des réponses négatives qui stipule :

Comme les réponses normales, les réponses négatives ont un temps de vie (TTL). Comme il n'y a pas d'enregistrement dans la section des réponses auquel ce TTL peut être appliquer, le TTL doit être reporté par une autre méthode. Cela se fait par en incluant l'enregistrement SOA de la zone dans la section autorité de la réponse. réponse. Lorsque le serveur faisant autorité crée cet enregistrement, son TTL est de extrait du minimum du champ SOA.MINIMUM et du TTL de la SOA. Ce TTL diminue de la même manière qu'une réponse normale mise en cache et lorsqu'elle et lorsqu'il atteint zéro (0), il indique que la réponse négative mise en cache NE DOIT PAS être utilisée à nouveau.

Tout d'abord, identifions les SOA.MINIMUM et SOA TTL décrits dans le RFC. Le TTL est le nombre qui précède le type d'enregistrement. IN ( 900 secondes dans l'exemple ci-dessous). Alors que le minimum est le dernier champ de l'enregistrement ( 86400 secondes 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, le serverfault.com est illustrative car elle possède des serveurs faisant autorité de deux fournisseurs différents qui sont configurés différemment.

Trouvons les serveurs de noms qui font autorité pour le nom de domaine serverfault.com zone :

$ 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 en utilisant 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

A partir de là, nous pouvons voir que le TTL de l'enregistrement SOA est 900 secondes tandis que la valeur TTL négative est 86400 secondes. La valeur TTL de la SOA de 900 est plus faible, nous nous attendons donc à ce que cette valeur soit utilisée.

Maintenant, si nous interrogeons 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 (en antémémoire) reçoit cette réponse, il analyse l'enregistrement SOA dans l'en-tête de l'enregistrement. AUTHORITY SECTION et utilise le TTL de cet enregistrement pour déterminer combien de temps il doit mettre en cache le résultat négatif (dans ce cas-ci 900 secondes).

Maintenant, suivons 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 voir que les serveurs de noms de google ont des valeurs différentes pour le TTL SOA et le TTL négatif. Dans ce cas, le TTL négatif de 300 est inférieur au TTL de la SOA 21600 . Par conséquent, le serveur google doit utiliser la valeur la plus faible dans le champ AUTHORITY SECTION lors du renvoi d'un enregistrement SOA NXDOMAIN ré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, le TTL de l'enregistrement SOA dans le fichier NXDOMAIN la réponse est 300 secondes.

L'exemple ci-dessus montre également combien il est facile d'obtenir des réponses différentes à une même requête. La réponse qu'un résolveur de cache individuel finit par utiliser dépend du serveur de noms faisant autorité qui a été interrogé.

Lors de mes tests, j'ai également observé que certains résolveurs récursifs (caches) ne renvoient pas de message de type AUTHORITY SECTION avec un enregistrement SOA avec un TTL décroissant pour les demandes ultérieures, alors que d'autres le font.

Par exemple, le résolveur Cloudflare le fait (notez la valeur TTL décroissante) :

$ 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 VPC AWS répondra avec une section d'autorité uniquement lors de 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 traite du comportement de NXDOMAIN réponses.

Glossaire :

• Zone
• SOA
• TTL
• Serveur de nom récursif
• Serveur de nom de domaine faisant autorité