Jeśli serwer DNS wyszukuje rekord i go brakuje, często „negatywnie buforuje” fakt braku tego rekordu i nie spróbuje go jeszcze przez jakiś czas szukać. Nie widzę nic w RFC na temat TTL na temat negatywnego buforowania, więc domyślam się, że jest to trochę arbitralne. Jak długo w rzeczywistości utrzymują się te negatywne zapisy?

TTL dla buforowania ujemnego nie jest arbitralne. Jest pobierany z rekordu SOA na górze strefy, do której należałby żądany rekord, gdyby istniał. Na przykład:

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

Ostatnia wartość w rekordzie SOA („86400”) to czas, w którym klienci proszeni są o buforowanie wyników ujemnych example.org..

Jeśli klient zażąda doesnotexist.example.org., będzie buforował wynik przez 86400 sekund.

Zależy to od dokładnej definicji „zapytania negatywnego”, ale w obu przypadkach jest to udokumentowane w rfc2308 «Negatywne buforowanie zapytań DNS (DNS NCACHE)» :

NXDOMAIN

• Jeśli rozdzielczość zakończy się powodzeniem, a wynikiem NXDOMAINbędzie odpowiedź, zostanie zapisany SOArekord, który zawiera NXDOMAINTTL (tradycyjnie zwany MINIMUMpolem). rfc2308#section-4

SERVFAIL

• Jeśli rozdzielczość nie powiedzie się i spowodujeSERVFAIL przekroczenie limitu czasu ( ) , może nie być w ogóle buforowana, aw żadnym wypadku NIE MOŻE być buforowana dłużej niż 5 minut. rfc2308#section-7.1

  Pamiętaj, że w praktyce buforowanie takich wyników przez pełne dozwolone 5 minut to świetny sposób na zmniejszenie doświadczenia klienta w przypadku, gdy jego serwer pamięci podręcznej czasami doświadcza krótkich problemów z łącznością (i skutecznie czyni go łatwo podatnym na wzmocnienie Denial-of-Service, gdzie kilka sekund przestoju spowodowałoby wyłączenie niektórych części DNS przez pięć pełnych minut).

  Przed wersją BIND 9.9.6-S1 (wydaną w 2014 r.) Najwyraźniej SERVFAILw ogóle nie był buforowany. a878301(2014-09-04)

  Na przykład w czasie Twojego pytania i we wszystkich wersjach BIND wydana przed 2014 r BIND rekurencyjnego rozpoznawania nazw nie cache SERVFAILw ogóle, jeżeli powyższe popełnić i dokumentacja o pierwszym wprowadzeniu w 9.9.6-S1 wierzyć .

  W najnowszej wersji BIND wartością domyślną servfail-ttljest 1s, a ustawienie jest ustalone na stałe do pułapu 30s(zamiast pułapu z mandatem RFC 300s). 90174e6(2015-10-17)

  Ponadto następujące godne uwagi cytaty na ten temat:

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

  Wynik buforowania odpowiedzi SERVFAIL obejmował niektóre sytuacje, w których uznano, że jest to szkodliwe dla doświadczenia klienta, szczególnie gdy przyczyny przedstawienia SERVFAIL klientowi były przejściowe i ze scenariusza, w którym natychmiastowe ponowienie zapytania byłoby bardziej odpowiednie działanie.

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

  Druga taktyka polega na twierdzeniu, że powszechni klienci DNS zrobią coś szczególnie złego, gdy nie będą mogli uzyskać dostępu do wszystkich serwerów DNS. Problem z tym argumentem polega na tym, że twierdzenie jest fałszywe. Każdy taki klient jest wyraźnie wadliwy i nie będzie w stanie przetrwać na rynku: zastanów się, co się stanie, jeśli routery klienta ulegną krótkotrwałej awarii lub sieć klienta zostanie tymczasowo zalana.

Podsumowując, NXDOMAINodpowiedź zostanie zapisana w pamięci podręcznej, jak określono w SOAodpowiedniej strefie, podczas gdy SERVFAILjest mało prawdopodobne, że zostanie buforowana, lub, jeśli buforowana, będzie to co najwyżej dwucyfrowa liczba sekund.

Istnieje RFC poświęcona temu tematowi: RFC 2308 - Negatywne buforowanie zapytań DNS (DNS NCACHE) .

Odpowiednia sekcja do przeczytania to 5 - Buforowanie negatywnych odpowiedzi, które stwierdza:

Podobnie jak normalne odpowiedzi, odpowiedzi negatywne mają czas na przeżycie (TTL). Ponieważ w sekcji odpowiedzi nie ma zapisów, do których można by zastosować ten TTL, TTL należy przeprowadzić inną metodą. Odbywa się to poprzez włączenie rekordu SOA ze strefy do sekcji autorytetu odpowiedzi. Kiedy autorytatywny serwer tworzy ten rekord, jego TTL jest pobierane z minimum pola SOA.MINIMUM i TTL SOA. To zmniejszenie TTL w podobny sposób jak normalna buforowana odpowiedź i po osiągnięciu zera (0) wskazuje, że buforowana odpowiedź negatywna NIE MOŻE być ponownie użyta.

Po pierwsze pozwala zidentyfikować SOA.MINIMUMi SOA TTL opisane w RFC. TTL to liczba przed typem rekordu IN( 900sekundy w poniższym przykładzie). Chociaż minimum to ostatnie pole w rekordzie ( 86400sekundy w poniższym przykładzie).

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

Teraz spójrzmy na kilka przykładów, serverfault.comstrefa jest ilustrująca, ponieważ ma autorytatywne serwery od dwóch różnych dostawców, którzy są inaczej skonfigurowani.

Znajdźmy autorytatywne serwery nazw dla serverfault.comstrefy:

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

Następnie sprawdź rekord SOA za pomocą serwera nazw 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

Z tego wynika, że ​​TTL rekordu SOA to 900sekundy, a ujemna wartość TTL to 86400sekundy. Wartość TTL SOA 900jest niższa, więc spodziewamy się, że ta wartość zostanie zastosowana.

Teraz, jeśli zapytamy autorytatywny serwer o nieistniejącą domenę, powinniśmy otrzymać odpowiedź bez odpowiedzi i z rekordem SOA w sekcji autorytetu:

$ 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

Kiedy rekurencyjny (buforujący) przelicznik otrzyma tę odpowiedź, parsuje rekord SOA AUTHORITY SECTIONi użyje TTL tego rekordu, aby określić, jak długo powinien buforować wynik ujemny (w tym przypadku 900sekundy).

Teraz wykonajmy tę samą procedurę z serwerem nazw 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

Możesz zobaczyć, że serwery nazw Google mają różne wartości zarówno dla TTL SOA, jak i dla ujemnych wartości TTL. W tym przypadku ujemna wartość TTL 300jest niższa niż wartość TTL SOA wynosząca 21600. Dlatego serwer Google powinien użyć niższej wartości w AUTHORITY SECTIONrekordzie SOA podczas zwracania NXDOMAINodpowiedzi:

$ 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

Zgodnie z oczekiwaniami TTL rekordu SOA w NXDOMAINodpowiedzi wynosi 300sekundy.

Powyższy przykład pokazuje również, jak łatwo uzyskać różne odpowiedzi na to samo zapytanie. Odpowiedź, której używa pojedynczy program tłumaczący buforowanie, zależy od tego, do którego serwera zapytano autorytatywnego serwera nazw.

W moich testach zauważyłem również, że niektóre rekurencyjne (buforujące) przeliczniki nie zwracają AUTHORITY SECTIONrekordu SOA z malejącym TTL dla kolejnych żądań, podczas gdy inne tak robią.

Na przykład robi to przelicznik chmury (zwróć uwagę na malejącą wartość 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

Podczas gdy domyślny program rozpoznawania nazw w AWS VPC odpowie sekcją uprawnień tylko na pierwsze żądanie:

$ 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

Uwaga: ta odpowiedź dotyczy zachowania NXDOMAINodpowiedzi.

Słownik:

• Strefa
• SOA
• TTL
• Recursive NameServer
• Autorytatywny serwer nazw