web-dev-qa-db-fra.com

Combien de temps dure généralement la mise en cache DNS négative?

Si un serveur DNS recherche un enregistrement et qu'il est manquant, il "cache" négativement le fait que cet enregistrement est manquant et n'essaye pas de le rechercher à nouveau pendant un certain temps. Je ne vois rien dans le RFC sur le TTL sur la mise en cache négative devrait être, donc je suppose que c'est Dans le monde réel, combien de temps ces enregistrements négatifs restent-ils?

domain-name-system
49
Leopd

Le TTL pour la mise en cache négative n'est pas arbitraire. Il est extrait de l'enregistrement SOA en haut de la zone à laquelle l'enregistrement demandé aurait appartenu, avait 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 les clients sont invités à mettre en cache les résultats négatifs sous example.org..

Si un client demande doesnotexist.example.org., il mettra en cache le résultat pendant 86400 secondes.

65
Celada

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

NXDOMAIN

  • Si la résolution réussit et aboutit à NXDOMAIN, la réponse sera accompagnée d'un enregistrement SOA, qui contiendrait le NXDOMAIN TTL (traditionnellement appelé champ MINIMUM). rfc2308#section-4

SERVFAIL

  • Si la résolution échoue et entraîne un délai d'attente (SERVFAIL) , alors elle peut tout aussi bien ne pas être mise en cache du tout, et dans tous les cas NE DOIT PAS être mise en cache plus longtemps que 5 minutes. rfc2308#section-7.1

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

    Avant BIND 9.9.6-S1 (sorti en 2014), apparemment, SERVFAIL n'était pas du tout mis en cache. 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 BIND DID PAS en cache du tout SERVFAIL, si la validation ci-dessus et - la documentation sur la première introduction dans 9.9.6-S1 est à croire.

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

    En outre, voici quelques citations importantes à ce sujet:

    Le résultat de la mise en cache des réponses SERVFAIL a inclus certaines situations où cela a été perçu comme étant préjudiciable à l'expérience client, en particulier lorsque les causes de la SERVFAIL présentée au client étaient transitoires et à partir d'un scénario où une nouvelle tentative immédiate de la requête serait un action plus appropriée.

    La deuxième tactique consiste à affirmer que les clients DNS répandus feront quelque chose de particulièrement mauvais lorsqu'ils ne pourront pas atteindre tous les serveurs DNS. Le problème avec cet argument est que la déclaration est fausse. Un tel client est clairement bogué et ne pourra pas survivre sur le marché: réfléchissez à 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é, une réponse NXDOMAIN serait mise en cache comme spécifié dans le SOA de la zone applicable, tandis que SERVFAIL est peu susceptible d'être mis en cache, ou, s'il est mis en cache, ce sera au plus un nombre à deux chiffres de secondes.

12
cnst

Il existe une RFC dédiée à ce sujet: RFC 2308 - Mise en cache négative des 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 à vivre (TTL). Comme il n'y a aucun enregistrement dans la section réponse auquel ce TTL peut être appliqué, le TTL doit être effectué par une autre méthode. Ceci est fait en incluant le SOA enregistrement de la zone dans la section d'autorité de la réponse. Lorsque le serveur faisant autorité crée cet enregistrement, son TTL est pris à partir du minimum de SOA.MINIMUM et TTL de SOA. Ce TTL décroît de manière similaire à une réponse en cache normale et en atteignant zéro (0) indique que la réponse négative en cache NE DOIT PAS être utilisée à nouveau.

Permet d'abord d'identifier le SOA.MINIMUM et SOA TTL décrit dans le RFC. Le TTL est le nombre avant 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 zone est illustrative car elle possède des serveurs faisant autorité de deux fournisseurs différents qui sont configurés différemment.

Permet de trouver les serveurs de noms faisant autorité pour le 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 à 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

De cela, nous pouvons voir que le TTL de l'enregistrement SOA est 900 secondes tandis que la valeur négative TTL est 86400 secondes. La valeur SOA TTL 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 (mise en cache) reçoit cette réponse, il analysera l'enregistrement SOA dans le AUTHORITY SECTION et utilisez le TTL de cet enregistrement pour déterminer combien de temps il doit mettre en cache le résultat négatif (dans ce cas 900 secondes).

Permet maintenant de suivre 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 Google ont des valeurs différentes pour les valeurs SOA TTL et Negative TTL. Dans ce cas le négatif TTL de 300 est inférieur à SOA TTL of 21600. Par conséquent, le serveur Google doit utiliser la valeur inférieure dans le AUTHORITY SECTION SOA lors du renvoi d'une réponse NXDOMAIN:

$ 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 la réponse NXDOMAIN est 300 secondes.

L'exemple ci-dessus montre également à quel point il est facile d'obtenir des réponses différentes à la même requête. La réponse qu'un résolveur de mise en cache individuel finit par utiliser est à laquelle le serveur de noms faisant autorité a été interrogé.

Lors de mes tests, j'ai également observé que certains résolveurs récursifs (mise en cache) ne renvoient pas de AUTHORITY SECTION avec un enregistrement SOA avec une décrémentation TTL pour les demandes ultérieures, contrairement aux autres).

Par exemple, le résolveur cloudflare fait (notez la 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 ne répondra avec une section d'autorité qu'à la première demande:

$ 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 des réponses NXDOMAIN.

Glossaire:

2
htaccess