Wenn ein DNS-Server einen Datensatz sucht und dieser fehlt, wird die Tatsache, dass dieser Datensatz fehlt, häufig negativ zwischengespeichert, und es wird eine Weile lang nicht versucht, ihn erneut zu suchen. Ich sehe in der RFC nichts darüber, dass die TTL für negatives Caching sein sollte, also schätze ich, dass es etwas willkürlich ist. Wie lange halten sich diese negativen Aufzeichnungen in der realen Welt?

Die TTL für das negative Caching ist nicht beliebig. Es wird aus dem SOA-Datensatz am oberen Rand der Zone entnommen, zu der der angeforderte Datensatz gehört hätte, wenn er existiert hätte. Zum Beispiel:

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

Der letzte Wert im SOA-Datensatz ("86400") gibt an, wie lange Clients aufgefordert werden, negative Ergebnisse unter "" zwischenzuspeichern example.org..

Wenn ein Client dies anfordert doesnotexist.example.org., wird das Ergebnis für 86400 Sekunden zwischengespeichert.

Dies hängt von Ihrer genauen Definition einer "negativen Abfrage" ab. In beiden Fällen ist dies jedoch in rfc2308 "Negative Caching von DNS-Abfragen (DNS NCACHE)" dokumentiert :

NXDOMAIN

• Wenn die Auflösung erfolgreich ist und das Ergebnis ist NXDOMAIN, wird die Antwort mit einem SOADatensatz geliefert, der die NXDOMAINTTL (traditionell als MINIMUMFeld bezeichnet) enthält. rfc2308#section-4

SERVFAIL

• Wenn die Auflösung nicht erfolgreich ist und zu einer Zeitüberschreitung ( SERVFAIL) führt , wird sie möglicherweise überhaupt nicht zwischengespeichert und DARF unter keinen Umständen länger als 5 Minuten zwischengespeichert werden. rfc2308#section-7.1

  Beachten Sie, dass in der Praxis das Zwischenspeichern solcher Ergebnisse für die gesamten zulässigen 5 Minuten eine gute Möglichkeit darstellt, die Erfahrung eines Clients zu verringern, falls der Cache-Server gelegentlich kurze Verbindungsprobleme aufweist (und es effektiv leicht für eine Denial-of-Service-Verstärkung anfällig macht). Wobei einige Sekunden Ausfallzeit dazu führen würden, dass bestimmte Teile des DNS fünf Minuten lang nicht verfügbar sind.

  Vor BIND 9.9.6-S1 (im Jahr 2014 veröffentlicht) wurde offenbar überhaupt SERVFAILnicht zwischengespeichert. a878301(04.09.2014)

  Zum Zeitpunkt Ihrer Frage und in allen Versionen von BIND, die vor 2014 veröffentlicht wurden, hat der rekursive BIND-Resolver NICHT gecachtSERVFAIL , wenn das oben genannte Commit und die Dokumentation zur ersten Einführung in 9.9.6-S1 angenommen werden sollen .

  In der neuesten BIND, die Standardeinstellung servfail-ttlist 1s, und die Einstellung zu einer Obergrenze von fest einprogrammiert ist 30s(anstelle der RFC-mandatierten Decke 300s). 90174e6(2015-10-17)

  Darüber hinaus sind im Folgenden einige bemerkenswerte Zitate zu diesem Thema aufgeführt:

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

  Das Ergebnis der Zwischenspeicherung von SERVFAIL-Antworten umfasste einige Situationen, in denen sich dies nachteilig auf die Clienterfahrung auswirkte, insbesondere wenn die Gründe für die Präsentation von SERVFAIL beim Client vorübergehend waren und aus einem Szenario stammten, in dem ein sofortiger erneuter Versuch der Abfrage wahrscheinlich wäre angemessenere Aktion.

  • http://cr.yp.to/djbdns/third-party.html (11.01.2003)

  Die zweite Taktik ist, zu behaupten, dass weit verbreitete DNS-Clients etwas besonders Böses tun, wenn sie nicht alle DNS-Server erreichen können. Das Problem mit diesem Argument ist, dass die Behauptung falsch ist. Ein solcher Client ist eindeutig fehlerhaft und kann auf dem Markt nicht bestehen. Überlegen Sie, was passiert, wenn die Router des Clients kurzzeitig ausfallen oder das Netzwerk des Clients vorübergehend überlastet ist.

Zusammenfassend kann gesagt werden, dass eine NXDOMAINAntwort wie in der SOAentsprechenden Zone angegeben zwischengespeichert wird, wohingegen SERVFAILes unwahrscheinlich ist, dass sie zwischengespeichert wird, oder, falls zwischengespeichert, höchstens eine zweistellige Anzahl von Sekunden.

Zu diesem Thema gibt es einen RFC: RFC 2308 - Negatives Caching von DNS-Abfragen (DNS NCACHE) .

Der relevante zu lesende Abschnitt lautet 5 - Negative Antworten zwischenspeichern und lautet:

Negative Antworten haben wie normale Antworten eine Lebenszeit (TTL). Da es im Antwortabschnitt keinen Datensatz gibt, auf den diese TTL angewendet werden kann, muss die TTL nach einer anderen Methode übertragen werden. Dazu wird der SOA-Datensatz aus der Zone in den Autoritätsabschnitt der Antwort aufgenommen. Wenn der autorisierende Server diesen Datensatz erstellt, wird seine TTL aus dem Minimum des Felds SOA.MINIMUM und der TTL der SOA entnommen. Diese TTL verringert sich auf ähnliche Weise wie eine normale zwischengespeicherte Antwort und zeigt an, dass bei Erreichen von Null (0) die zwischengespeicherte negative Antwort NICHT mehr verwendet werden darf.

SOA.MINIMUMLassen Sie uns zunächst die im RFC beschriebene SOA-TTL identifizieren . Die TTL ist die Zahl vor dem Datensatztyp IN( 900Sekunden im folgenden Beispiel). Während das Minimum das letzte Feld im Datensatz ist ( 86400Sekunden im folgenden Beispiel).

$ 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)
                )

Schauen wir uns nun einige Beispiele an. Die serverfault.comZone ist veranschaulichend, da sie autorisierende Server von zwei verschiedenen Anbietern enthält, die unterschiedlich konfiguriert sind.

Hier finden Sie die maßgeblichen Nameserver für die 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.

Überprüfen Sie dann den SOA-Datensatz mit einem aws-Nameserver:

$ 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

Daraus können wir ersehen, dass die TTL des SOA-Datensatzes 900Sekunden beträgt, während der negative TTL-Wert 86400Sekunden beträgt . Der SOA-TTL-Wert von 900ist niedriger, daher wird erwartet, dass dieser Wert verwendet wird.

Wenn wir nun einen autorisierenden Server nach einer nicht vorhandenen Domäne abfragen, sollten wir eine Antwort ohne Antwort und mit einem SOA-Datensatz im Abschnitt "Authority" erhalten:

$ 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

Wenn ein rekursiver (Caching-) Resolver diese Antwort erhält, analysiert er den SOA-Datensatz in AUTHORITY SECTIONund verwendet die TTL dieses Datensatzes, um zu bestimmen, wie lange das negative Ergebnis zwischengespeichert werden soll (in diesem Fall 900Sekunden).

Gehen wir nun mit einem Google Nameserver genauso vor:

$ 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

Sie können sehen, dass die Google-Nameserver unterschiedliche Werte sowohl für die SOA-TTL- als auch für die Negative-TTL-Werte haben. In diesem Fall ist die negative TTL von 300niedriger als die SOA-TTL von 21600. Daher sollte der Google Server den niedrigeren Wert im AUTHORITY SECTIONSOA-Datensatz verwenden, wenn eine NXDOMAINAntwort zurückgegeben wird:

$ 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

Wie erwartet NXDOMAINbeträgt die TTL des SOA-Datensatzes in der Antwort 300Sekunden.

Das obige Beispiel zeigt auch, wie einfach es ist, unterschiedliche Antworten auf dieselbe Abfrage zu erhalten. Die Antwort, die ein einzelner Caching-Resolver verwendet, ist, welcher autorisierende Nameserver abgefragt wurde.

Bei meinen Tests habe ich auch festgestellt, dass einige rekursive (Caching-) Resolver AUTHORITY SECTIONfür nachfolgende Anforderungen kein mit einem SOA-Datensatz mit einer dekrementierenden TTL zurückgeben, während andere dies tun.

Zum Beispiel der Cloudflare-Resolver (beachte den dekrementierenden TTL-Wert):

$ 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

Während der Standard-Resolver in einer AWS VPC nur bei der ersten Anforderung mit einem Berechtigungsabschnitt antwortet:

$ 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

Hinweis: Diese Antwort behandelt das Verhalten von NXDOMAINAntworten.

Glossar:

• Zone
• SOA
• TTL
• Rekursiver NameServer
• Autorisierter Nameserver